Есть Debian, у него есть две сетевые карты и свисток Yota LU150 LTE. При подключении свистка создается интерфейс eth2, т.е. картина получается примерно следующая:eth0 (192.168.0.0/24)
eth1 (192.168.1.0/24)
eth2 (10.0.0.0/24)На eth2, по DHCP, свисток назначает адрес 10.0.0.10 так-же в модеме живет шлюз с адресом 10.0.0.1 т.е. свисток является роутером.
Проблема в том что у меня не получилось выйти в инет с машин подключенных к eth0 и eth1 без использования NAT.
Поставил все политики ACCEPT для всех таблиц/цепочек, ну и, понятное дело, ip_forward.
default роут 10.0.0.1 с сервера инет доступен, с других машин нет. Мелькнула-было предательская мысль что свисток принимает пакеты только с подсетки 10.0.0.0/24, но tcpdump на eth2 выявил входящий пакет:
---
17:50:45.045950 IP (tos 0x0, ttl 127, id 1553, offset 0, flags [DF], proto TCP (6), length 52)
192.168.0.11.12987 > www.yandex.ru.www: Flags [S], cksum 0x35c6 (correct), seq 366191845, win 8192, options [mss 1464,nop,wscale 2,nop,nop,sackOK], length 017:50:45.080164 IP (tos 0x60, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 52)
www.yandex.ru.www > 192.168.0.11.12987: Flags [S.], cksum 0x7baa (correct), seq 656440375, ack 366191846, win 14100, options [mss 1360,nop,nop,sackOK,nop,wscale 9], length 0
---Если я правильно понял ACK от сервера приходит, вот только он до клиента не доходит. Причем с eth0 шлюз 10.0.0.1 пингуется. Никак не могу понять где я туплю. Пойду курить буквари : )
> Проблема в том что у меня не получилось выйти в инет с
> машин подключенных к eth0 и eth1 без использования NAT.и не получится.
с какой стати йоте роутить ваши серые ести ?
>> Проблема в том что у меня не получилось выйти в инет с
>> машин подключенных к eth0 и eth1 без использования NAT.
> и не получится.
> с какой стати йоте роутить ваши серые ести ?Информация точная или это предположение?
Как я отметил в первом посте такая идея мне приходила в голову, но tcpdump регистрирует ответные пакеты на eth2. Т.е. как минимум, йота роутит пакет из внетренней сетки наружу и возвращает его назад.
> На eth2, по DHCP, свисток назначает адрес 10.0.0.10 так-же в модеме живет шлюз с адресом 10.0.0.1 т.е. свисток является роутером.Вот это очень здравая мысль, зря вы её дальше не развили.
На всех свистках используется адрес 10.0.0.1 и 10.0.0.10 - на всех клиентах. Очевидно, что если от всех абонентов Yota будет получать пакеты с src ip 10.0.0.10 это создаст немало проблем по определению принадлежности пакетов. Далее, если уж свисток - роутер, то у него как минимум два интерфейса (адреса), так что логично предположить, что он не просто роутит, но ещё и натит в адрес своего радио-интерфейса. А поскольку на радио-интерфейсе модема с большой вероятностью стоит серый (приватный) IP, то где-то далее на выходе в интернет есть ещё один НАТ.
>> На eth2, по DHCP, свисток назначает адрес 10.0.0.10 так-же в модеме живет шлюз с адресом 10.0.0.1 т.е. свисток является роутером.
> Вот это очень здравая мысль, зря вы её дальше не развили.
> На всех свистках используется адрес 10.0.0.1 и 10.0.0.10 - на всех клиентах.
> Очевидно, что если от всех абонентов Yota будет получать пакеты с
> src ip 10.0.0.10 это создаст немало проблем по определению принадлежности пакетов.
> Далее, если уж свисток - роутер, то у него как минимум
> два интерфейса (адреса), так что логично предположить, что он не просто
> роутит, но ещё и натит в адрес своего радио-интерфейса. А поскольку
> на радио-интерфейсе модема с большой вероятностью стоит серый (приватный) IP, то
> где-то далее на выходе в интернет есть ещё один НАТ.Я даже растерялся. Если это подсказка, увы, не понимаю. То что вы описали, безусловно так и есть, сомнений не вызывало и не вызывает, вопрос подразумевался сугубо про локальную часть. Единственное что мне приходит на ум - я не достаточно точно описал ситуацию. Меня интересует можно-ли избежать NAT между eth0 и eth2, равно как между eth1 и eth2. То что за eth2 существует NAT это несомненно, но находится вне моего доступа.
Если отключить nat, syn пакеты уходят в большой интернет и даже приходит ответный пакет на eth2, что зафиксировано мной с помощью tcpdump. Но вот с помощью netfilter я их увидеть не могу(я про ответные пакеты). Соответсвенно у меня появились подозрения что я гдето тупанул с настройкой. На мой взгляд не разумно использовать NAT там где можно использовать роутинг.
>Меня интересует можно-ли избежать NAT между eth0 и eth2, равно
> как между eth1 и eth2. То что за eth2 существует NAT это
> несомненно, но находится вне моего доступа.Внутри модема таблица маршрутизации скорее всего выглядит так:
0.0.0.0/0 via Radio
10.0.0.0/24 via USB-EthКроме того, НАТ может быть ограничен той же сетью 10.0.0.0/24 или даже 10.0.0.10.
В случае, если НАТ не ограничен сетью модема, пакет от сети 192.168.0.0/23 сможет выйти наружу в интернет, но ответ на него обратной дороги не найдёт.
В случае, если НАТ ограничен сетью 10.0.0.0/24 или адресом 10.0.0.10, то пакет сможет даже уйти в интернет.
Так что, думаю, в описанно
Так что, думаю, в описанной конфигурации избежать НАТа на вашей машине не удастся.Можно попробовать вариант с бриджем eth0,eth1,eth2 и раздачей на машины за eth0 и eth1 адресов из сети 10.0.0.0/24, если в модеме НАТ на всю эту сеть, то такой вариант может сработать.
В других вариантах нужно иметь возможность изменять конфигурацию (логику работы) модема.
>[оверквотинг удален]
>> как между eth1 и eth2. То что за eth2 существует NAT это
>> несомненно, но находится вне моего доступа.
> Внутри модема таблица маршрутизации скорее всего выглядит так:
> 0.0.0.0/0 via Radio
> 10.0.0.0/24 via USB-Eth
> Кроме того, НАТ может быть ограничен той же сетью 10.0.0.0/24 или даже
> 10.0.0.10.
> В случае, если НАТ не ограничен сетью модема, пакет от сети 192.168.0.0/23
> сможет выйти наружу в интернет, но ответ на него обратной дороги
> не найдёт.Так в том-то и дело что SYN пакет уходит с интерфейса eth0 и на eth2 приходит ACK. Меня смущает то, что tcpdump его ловит а в netfilter я его не вижу. Я в первом посте привел пример. В любом случае буду пробовать. Вопрос скорее принципиальный чем животрепещущий.
> Так в том-то и дело что SYN пакет уходит с интерфейса eth0
> и на eth2 приходит ACK. Меня смущает то, что tcpdump его
> ловит а в netfilter я его не вижу.tcpdump загоняет интерфейс в promiscuous mode и выгребает всё что долетело до него, а netfilter получает то, что должно быть получено и обработано этим хостом.
Думаю, это увеличивает шансы варианта с бриджингом интерфейсов. Может быть ещё Proxy-ARP может помочь.