Странная проблема с NAT (itables)

sirmax · April 4, 2007

Возникла странная проблема с NAT - перестали натиться UDP пакеты.

Произошло после разворачивания маршрутизации в туннель (вынужденная мера)

-A POSTROUTING -s 10.0.0.0/8 --out-interface tun_uplink -j  SNAT --to-source <IP>

При этом при трассировке, например, на яндекс, имеем

tcpdump -n -i tun_uplink 

12:43:11.524792 IP 10.1.4.253.38528 > 213.180.204.8.33445: UDP, length 10
12:43:16.522759 IP 10.1.4.253.38528 > 213.180.204.8.33446: UDP, length 10

До последнего момента все работало.

Никакой логики найти не могу...

Ядро 2.6.16

iptables v1.3.5

В инете не нашел, куда смотреть не знаю. =(

Подкажите хоть в какую сторону копать =(

EvilShadow · April 4, 2007

Будьте добры, приведите всю таблицу POSTROUTING

sirmax · April 4, 2007

-A POSTROUTING -s 10.0.0.0/8 --out-interface tun_uplink2 -j  SNAT --to-source <IP 2-го аплинка>
-A POSTROUTING -s 10.0.0.0/8 --out-interface eth3.20 -j  SNAT --to-source <старый IP 1-го аплинка >
-A POSTROUTING -s 10.0.0.0/8 --out-interface tun_uplink -j  SNAT --to-source <IP 1-го аплинка>

дафолт смотрит в IP 1-го аплинка, весь траффик соответственно уходит через тунель.

tcp и icmp натит нормально.

Edited April 4, 2007 by sirmax

sirmax · April 4, 2007

Вот список загруженных модулей

module                  Size  Used by
iptable_mangle          3072  0
xt_state                2304  3
iptable_filter          3200  1
ipt_REDIRECT            2176  1
iptable_nat             8324  1
ip_nat                 17428  2 ipt_REDIRECT,iptable_nat
ip_conntrack           49764  3 xt_state,iptable_nat,ip_nat
nfnetlink               6680  2 ip_nat,ip_conntrack
ip_tables              13276  3 iptable_mangle,iptable_filter,iptable_nat
xt_connbytes            2560  9
ipt_layer7             12200  2
ipt_REJECT              5888  16
xt_limit                2816  1
ipt_multiport           2688  2
xt_tcpudp               3456  44
x_tables               13188  10 xt_state,ipt_REDIRECT,iptable_nat,ip_tables,xt_connbytes,ipt_layer7,ipt_REJECT,x
t_limit,ipt_multiport,xt_tcpudp
ipip                   11108  0
8021q                  20616  0

В гугле встречал упомнинания о такой проблеме, но решений не нашел =(

EvilShadow · April 4, 2007

ip rule list?

sirmax · April 4, 2007

0:      from all lookup local
32763:  from 193.*.*.*/23 lookup main
32766:  from all lookup main
32767:  from all lookup default

Заметил вообще огромную странность

часть клиентов натится нормально (udp).

Выражается это в том что часть машин из одного сегмента могуд делать trfceroute а часть - нет

(все машины с которых проверял - linux, traceroute использует UDP)

Как проверить, не слишком ли много клиентов я начу в один IP?

Возможно, дело в этом?

Edited April 4, 2007 by sirmax

EvilShadow · April 4, 2007

Маршруты самим iptables нигде не меняется? При помощи цели ROUTE, например?

Что говорит LOG/ULOG, если его воткнуть до и после правил трансляции?

Nallien · April 5, 2007

имхо - заткунто файрволом, или не не туда завернуто роутом.

user_anonymous · April 6, 2007

-A POSTROUTING -s 10.0.0.0/8 --out-interface tun_uplink2 -j  SNAT --to-source <IP 2-го аплинка>
-A POSTROUTING -s 10.0.0.0/8 --out-interface eth3.20 -j  SNAT --to-source <старый IP 1-го аплинка >
-A POSTROUTING -s 10.0.0.0/8 --out-interface tun_uplink -j  SNAT --to-source <IP 1-го аплинка>
дафолт смотрит в IP 1-го аплинка, весь траффик соответственно уходит через тунель.

tcp и icmp натит нормально.

Попробуйте поменять местами правила:

-A POSTROUTING -s 10.0.0.0/8 --out-interface tun_uplink -j SNAT --to-source <IP 1-го аплинка>

-A POSTROUTING -s 10.0.0.0/8 --out-interface eth3.20 -j SNAT --to-source <старый IP 1-го аплинка >

sirmax · April 6, 2007

Выяснил -

команда tarceroute -n ya.ru

(не работает)

15:50:11.931372 IP (tos 0x0, ttl   1, id 50647, offset 0, flags [none], proto: UDP (17), length: 38) 10.1.0.253.50645 > 87.250.251.8.33436: [bad udp cksum 5a30!] UDP, length 10

команда tarceroute -n ya.ru -s 10.1.0.253

(работает нормально)

15:51:57.656418 IP (tos 0x0, ttl   1, id 51379, offset 0, flags [none], proto: UDP (17), length: 38) 10.1.0.253.51378 > 213.180.204.8.33435: [udp sum ok] UDP, length 10

Т.е. - дело в чексумме.

Почему себя так ведет трэйсроут я не знаю.

(((

user_anonymous · April 6, 2007

А вы уверены, что это только traceroute глючит? Может дело в сетевом коде ядра? Тем более, что со времен 2.6.16 в нем нашли немало багов.

sirmax · April 6, 2007

Я уже не в чем не уверен, но дамп я смотрел не на той машине которая натит а на той с которой уходи трейс, а там - 2.6.20

ram_scan · April 6, 2007

Напутано с рутингом. Скорее всего пакет прилетает не с того интерфейса с которого его ожидают. Чексум бьется скорее всего в момент обратного проброса из-за неоднозначности рутинга.

Решение проблемы - или полиси бэйзд рутинг, или дефолт повернуть в тоннель плюс вписать один персональный маршрут на обратную сторону тоннеля.

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

PommeFritz · April 7, 2007

Напутано с рутингом. Скорее всего пакет прилетает не с того интерфейса с которого его ожидают. Чексум бьется скорее всего в момент обратного проброса из-за неоднозначности рутинга.

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

desperado · April 9, 2007

а с каких пор UDP натится?

EvilShadow · April 9, 2007

а с каких пор UDP натится?

А с каких пор для ната важны протоколы выше IP?

ram_scan · April 9, 2007

Ну, с GRE одно время были некоторые сложности...

desperado · April 9, 2007

А с каких пор для ната важны протоколы выше IP?

с тех пор как одному внешнему адресу стали ставить в соответствие более одного внутреннего. (или как вариант, пару удаленный-внутренний)

поменять адрес в исходящем пакете дело не хитрое. как вы собираетесь идентифицировать обратный трафик не залезая глубже IP?

EvilShadow · April 9, 2007

А с каких пор для ната важны протоколы выше IP?
с тех пор как одному внешнему адресу стали ставить в соответствие более одного внутреннего. (или как вариант, пару удаленный-внутренний)

поменять адрес в исходящем пакете дело не хитрое. как вы собираетесь идентифицировать обратный трафик не залезая глубже IP?

Никак. Я изначально не совсем корректно выразился. Подразумевалось, что протокол уровня выше IP имеет вторичное значение, поскольку всякий пакет помимо IP заголовка несет заголовок соотв. протокола, согласно которого пакет можно идентифицировать как принадлежащий к конкретному потоку. Причем сделать это можно для любого протокола, независимо от того, предусматривает ли он идентификаторы потоков или нет. Примером такого подхода может служить icmp echo-reply, несущий в теле ответного пакета часть запросного для однозначной идентификации процесса-отправителя.

Аналогично и нат для udp теоретически не составляет особой сложности, поскольку nat-box всегда может однозначно идентифицировать поток, к которому принадлежит конкретный пакет.

desperado · April 9, 2007

Аналогично и нат для udp теоретически не составляет особой сложности, поскольку nat-box всегда может однозначно идентифицировать поток, к которому принадлежит конкретный пакет.

сам по себе заголовок UDP не несет достаточной информации для идентификации потока, кроме не дающей никаких гарантий комбинации адресов и портов, т.к., например, разные направления могут быть с разными портами. А остальное это будет нат отдельных _приложений_ а не udp в целом.

Edited April 9, 2007 by desperado

EvilShadow · April 9, 2007

Если уж на то пошло, заголовок UDP вообще не несет никакой информации, кроме комбинаций адресов и портов (контрольные суммы не в счет). Что касается гарантий, то их и не стоит ожидать от безпотокового протокола. Но если следовать Вашей логике, то нужно признать, что нат удп вовсе невозможен, а на практике мы видим совсем другое.

А почему Вы считаете, что комбинации адресов/портов не позволяют с достаточно высокой вероятностью успеха определить поток? Адрес в этом случае позволяет ориентироваться в источниках удп-пакетов, а порт - в отдельных потоках конкретного источника. Конечно, определение состояния потока по таймауту не всегда дает достоверные результаты, тем не менее, если вопрос о возможности ната для удп ставится ребром, то вполне можно пренебречь вероятностью ошибки ради получения самой возможности ната.

Допустим, у нас есть 2 машины: М1 с адресом x.x.x.x и М2 с адресом y.y.y.y, которые натятся в z.z.z.z.

М1 создает три удп-потока с исходящими портами x1, x2, x3. М2 - два потока y1, y2. Натим их так:

x.x.x.x:x1 -> z.z.z.z:z1

x.x.x.x:x2 -> z.z.z.z:z2

x.x.x.x:x3 -> z.z.z.z:z3

y.y.y.y:y1 -> z.z.z.z:z4

y.y.y.y:y2 -> z.z.z.z:z5

При этом множества {x1, x2, x3} и {y1, y2} вполне могут пересекаться, а вот значения портов z всегда будут уникальными.

Зная заранее или каким-то образом вычислив время жизни удп-потока (t), можно утверждать, что пакет, пришедший на порт z.z.z.z:z1 в промежуток времени t, должен быть отослан на x.x.x.x:x1.

Разумеется, при таком подходе возможны ошибки. Тем не менее, он обеспечивает возможность удп-ната, что и требовалось доказать.

Прошу обратить внимание, что речь шла _только_ об удп. Контроль потоков самим приложением диктуется самой сутью удп. Приложения могут его осуществлять, а могут мириться с потерей пакетов, но нат-машины это уже не касается.

desperado · April 10, 2007

А почему Вы считаете, что комбинации адресов/портов не позволяют с достаточно высокой вероятностью успеха определить поток?

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

EvilShadow · April 10, 2007

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

Еще раз - сам по себе УДП позволяет достаточно успешно определять, кому принадлежит полученный пакет. Разумеется, можно для каждого пакета менять порты, можно и в TCP для каждого пакета создавать новый поток с другими портами, да только это уже не проблема протокола, а вопрос адекватности разработчика. Знаете, можно ведь и отверткой гвозди забивать, только нормальные люди используют для этого молоток. Зачем выходить за пределы возможностей протокола, чтоб потом жаловаться, что его невозможно пронатить, если можно в этих пределах оставаться и не городить огород?

sirmax · April 11, 2007

Вобщем, детальный анализ выявил только то что не натятся пакеты с плохой чексуммой.

99.9% приложений использующих UDP работают.

Думаю дело в этом, но почему трейсроут создает такие пакеты - я не понимаю =(

calculator · April 19, 2007

Аналогичная проблема. Win(tracert icmp) через Linux(2.6.20) работает.

Сам же Linux traceroute получает только с первого хоста. И с ядром 2.6.20 и с 2.6.18 В моем случае видимо просто провайдер(корвет) балуется, потому как на работе все ок(ядро то же и tracerout той же версии).

Sign In

Странная проблема с NAT (itables)

Recommended Posts

sirmax

EvilShadow

sirmax

sirmax

EvilShadow

sirmax

EvilShadow

Nallien

user_anonymous

sirmax

user_anonymous

sirmax

ram_scan

PommeFritz

desperado

EvilShadow

ram_scan

desperado

EvilShadow

desperado

EvilShadow

desperado

EvilShadow

sirmax

calculator

Join the conversation