iptables snat vs 2 дефолта

[s.lobanov]

Суть такова:

 

есть линукс-сервер, который делает NAT с целью выпустить хосты из сети 192.168.255.0/24 в интернет

 

Таблица маршрутизации на сервере:

 

192.168.255.0/24 dev eth3  proto kernel  scope link  src 192.168.255.1
1.1.1.128/27 dev eth0  proto kernel  scope link  src 1.1.1.155 
1.1.1.160/27 dev eth1  proto kernel  scope link  src 1.1.1.186 
default  proto zebra  src 1.1.1.100  metric 11 
    nexthop via 1.1.1.129  dev eth0 weight 1
    nexthop via 1.1.1.161  dev eth1 weight 1

 

nat делается весьма стандратно

iptables -t nat -I POSTROUTING -s 192.168.255.0/24 -j SNAT --to 1.1.1.100

 

1.1.1.100 - это лупбэк сервера, который аннонсируется по ospf.

 

На хостах 192.168.255.0/24 прописан шлюз 192.168.255.1

 

Если делаем с сервера ping -I 1.1.1.100 yandex.ru - отлично пингается и любые другие пингающиеся хосты в интернете. Трафик во внешний мир ходит и через eth0 и через eth1.

 

Однако NAT то работает, то не работает(некоторые внешние IP пингаются с хостов 192.168.255.0/24, некоторые нет) когда есть 2 дефолта, как только оставляю один дефолт, nat начинает отрабатывать как положено.

 

Не работает snat когда "запрос"(после трансляции адреса) уходит в eth0(например), а "ответ" возвращается через eth1(в данном примере).

 

Собственно вопрос в том, действительно ли iptables snat проверяет интерфейс с которого пришёл ответ и если пришёл с другого, то не делает обратную замену(dst ip)? Т.е. учитывается ли интерфейс, через который был выпущен пакет при инсталляции записи в таблицу трансляций? Если моё предположение верно, то можно ли как-то всё-таки заставить работать iptables snat с двумя дефолтами?

Edited October 14, 2010 by s.lobanov

[alex_001]

Суть такова:

 

есть линукс-сервер, который делает NAT с целью выпустить хосты из сети 192.168.255.0/24 в интернет

 

Таблица маршрутизации на сервере:

 

192.168.255.0/24 dev eth3  proto kernel  scope link  src 192.168.255.1
1.1.1.128/27 dev eth0  proto kernel  scope link  src 1.1.1.155 
1.1.1.160/27 dev eth1  proto kernel  scope link  src 1.1.1.186 
default  proto zebra  src 1.1.1.100  metric 11 
    nexthop via 1.1.1.129  dev eth0 weight 1
    nexthop via 1.1.1.161  dev eth1 weight 1

 

nat делается весьма стандратно

iptables -t nat -I POSTROUTING -s 192.168.255.0/24 -j SNAT --to 1.1.1.100

 

1.1.1.100 - это лупбэк сервера, который аннонсируется по ospf.

 

На хостах 192.168.255.0/24 прописан шлюз 192.168.255.1

 

Если делаем с сервера ping -I 1.1.1.100 yandex.ru - отлично пингается и любые другие пингающиеся хосты в интернете. Трафик во внешний мир ходит и через eth0 и через eth1.

 

Однако NAT то работает, то не работает(некоторые внешние IP пингаются с хостов 192.168.255.0/24, некоторые нет) когда есть 2 дефолта, как только оставляю один дефолт, nat начинает отрабатывать как положено.

 

Не работает snat когда "запрос"(после трансляции адреса) уходит в eth0(например), а "ответ" возвращается через eth1(в данном примере).

 

Собственно вопрос в том, действительно ли iptables snat проверяет интерфейс с которого пришёл ответ и если пришёл с другого, то не делает обратную замену(dst ip)? Т.е. учитывается ли интерфейс, через который был выпущен пакет при инсталляции записи в таблицу трансляций? Если моё предположение верно, то можно ли как-то всё-таки заставить работать iptables snat с двумя дефолтами?

rp_filter может быть? попробуйте выключить. sysctl net.ipv4.conf.eth0.rp_filter = 0 ... e.t.c/

 

[s.lobanov]

Если бы это был rp_filter, то ping -I 1.1.1.100 *any* не работало бы. Но всё же скажу, что rp_filter выключен(0)

[alex_001]

Собственно вопрос в том, действительно ли iptables snat проверяет интерфейс с которого пришёл ответ и если пришёл с другого, то не делает обратную замену(dst ip)? Т.е. учитывается ли интерфейс, через который был выпущен пакет при инсталляции записи в таблицу трансляций? Если моё предположение верно, то можно ли как-то всё-таки заставить работать iptables snat с двумя дефолтами?

А если вставить

iptables -I INPUT -m state --state INVALID -j LOG

что говорит?

[s.lobanov]

Спасибо, попробую как-нибудь, тестовой машины под эту задачу нет под рукой, чтобы это проверить. Ну вот увижу я заголовки инвалидных пакетов в логе, что мне это даст? Я и так видел пакеты tcpdump'ом, которые приходили извне и не транслировались обратно.

[alex_001]

Спасибо, попробую как-нибудь, тестовой машины под эту задачу нет под рукой, чтобы это проверить. Ну вот увижу я заголовки инвалидных пакетов в логе, что мне это даст? Я и так видел пакеты tcpdump'ом, которые приходили извне и не транслировались обратно.

Будет хоть понятно в netfilter оно попадает или раньше гдето дропается.