LINUX.ORG.RU
решено ФорумAdmin

непонятки с SNAT

 ,


2

3

Дано: сервер на Linux (Centos 6.3 - да, уже старый, но «работает-не трогай»), работающий Интернет-шлюзом для нескольких частных сетей. Адреса в частных сетях «серые», На интерфейсе eth0, которым сервер подключен к Интернет-сегменту, делается SNAT по принципу «много в один» (подсеть «серых» адресов в один «белый» IP). Например (реальные адреса, естественно, заменены):

 -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j SNAT --to-source 1.1.1.1

По идее пакетов с источником из сети 10.10.10.0 на выходе с eth0 после этого быть не должно, вместо этого у всех исходящих с eth0 пакетов источником должен быть 1.1.1.1. В большинстве случаев это так, однако регулярно появляются и пакеты с сурсом из 10.10.10.0. И tcpdump'ом на eth0 их видно и на внешние адреса приходят.

Например, фрагмент дампа, где появляются такие пакеты:

22:16:20.458067 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], seq 2865:4297, ack 312, win 288, length 1432
22:16:22.915330 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], seq 4297:5729, ack 312, win 288, length 1432
22:16:26.611440 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], seq 1433:2865, ack 312, win 288, length 1432
22:16:28.601530 IP 1.1.1.1.58349 > 93.184.221.240.http: Flags [.], ack 2865, win 160, length 0
22:16:28.604610 IP 1.1.1.1.58349 > 93.184.221.240.http: Flags [F.], seq 312, ack 2865, win 160, length 0
22:16:28.625207 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], seq 5729:7161, ack 312, win 288, length 1432
22:16:28.625236 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [P.], seq 7161:8593, ack 312, win 288, length 1432
22:16:28.628016 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], ack 313, win 288, length 0
22:16:28.656497 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:29.011868 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:35.505264 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:35.756197 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:35.883696 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:35.968263 IP 1.1.1.1.58349 > 93.184.221.240.http: Flags [R], seq 3280738782, win 0, length 0

В интернетах копался долго, но ничего похожего не нашел.Насколько я понимаю, в цепочку POSTROUTING таблицы nat должны попадать все выходящие через интерфейс (в данном случае eth0) пакеты, и source IP у них должен подменяться. После этого теоретически с ними мог бы что-до делать mangle POSTROUTING, но его у меня нету. Но по факту - иногда source IP не подменяется.

Вопрос: а почему? И как от этого избавиться.

Примечание: если сделать трансляцию «один в один», типа

 -A POSTROUTING -s 10.10.10.124/32 -o eth0 -j SNAT --to-source 1.1.1.1
то такой ерунды, вроде, не происходит. Но это же не выход. Сильно жирно - на каждый «серый IP» выделять по белому. И даже по отдельному правилу писать - тоже не выход, особенно если этих «серых» IP во внутренней сети (да еще не одной) сильно много.


Ну да, всякие левые FIN,RST проползают.

В FORWARD должно быть что-то типа

iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state NEW -p tcp ! --syn -j DROP

Второе правило можно не писать если net.netfilter.nf_conntrack_tcp_loose=0

vel ★★★★★
()
Ответ на: комментарий от vel

спасибо. попробую. проблема выплыла на одной хитрой задаче, где время от время происходит внезапный разрыв tcp-сессии,и это каждый раз сопровождается выбросом вот таких «левых» пакетов с неоттранслированным источником. «после этого» не значит «вследствие этого», но назойливо совпадает. для дальнейшей диагностики хотелось бы непонятки исключить.

mik73
() автор топика
Ответ на: комментарий от mik73

Обрати внимание на строку

22:16:28.604610 IP 1.1.1.1.58349 > 93.184.221.240.http: Flags [F.], seq 312, ack 2865, win 160, length 0
Очень похоже, что клиент закончил передавать, места в буфере на прием нет (win 160), а сервер что-то пытается туда послать.

Странный клиент.

vel ★★★★★
()
Ответ на: комментарий от vel

спасибо, сработало. хотя я не смог найти внятного описания того, что делает

net.netfilter.nf_conntrack_tcp_loose=0

что интересно, клиент в приведенном примере самый обычный пользователь, один из просто выхватил один пример из дампа. Очень вряд ли у его что-то экзотичный. Какой-нибудь броузер на какой-нибудь винде скорее всего. Разве что канал до него «длинный» (в смысле задержки).

mik73
() автор топика
Ответ на: комментарий от mik73

прошу извинить за ачепятки. пальцы стучат сами мимо головы.

mik73
() автор топика
Ответ на: комментарий от mik73

If it is set to zero, we disable picking up already established connections.

Если соединение не началось с SYN, то оно будет INVALID, а не ESTABLISHED

Если на роутере с nf_conntrack_tcp_loose=0 сказать «conntrack -F» то всем открытым tcp-шным коннектам будет пушистый зверек.

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.