sirmax Опубликовано 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 В инете не нашел, куда смотреть не знаю. =( Подкажите хоть в какую сторону копать =( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 4 апреля, 2007 · Жалоба Будьте добры, приведите всю таблицу POSTROUTING Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 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 натит нормально. Изменено 4 апреля, 2007 пользователем sirmax Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 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 В гугле встречал упомнинания о такой проблеме, но решений не нашел =( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 4 апреля, 2007 · Жалоба ip rule list? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 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? Возможно, дело в этом? Изменено 4 апреля, 2007 пользователем sirmax Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 4 апреля, 2007 · Жалоба Маршруты самим iptables нигде не меняется? При помощи цели ROUTE, например? Что говорит LOG/ULOG, если его воткнуть до и после правил трансляции? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nallien Опубликовано 5 апреля, 2007 · Жалоба имхо - заткунто файрволом, или не не туда завернуто роутом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user_anonymous Опубликовано 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-го аплинка > Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 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 Т.е. - дело в чексумме. Почему себя так ведет трэйсроут я не знаю. ((( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user_anonymous Опубликовано 6 апреля, 2007 · Жалоба А вы уверены, что это только traceroute глючит? Может дело в сетевом коде ядра? Тем более, что со времен 2.6.16 в нем нашли немало багов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 6 апреля, 2007 · Жалоба Я уже не в чем не уверен, но дамп я смотрел не на той машине которая натит а на той с которой уходи трейс, а там - 2.6.20 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ram_scan Опубликовано 6 апреля, 2007 · Жалоба Напутано с рутингом. Скорее всего пакет прилетает не с того интерфейса с которого его ожидают. Чексум бьется скорее всего в момент обратного проброса из-за неоднозначности рутинга. Решение проблемы - или полиси бэйзд рутинг, или дефолт повернуть в тоннель плюс вписать один персональный маршрут на обратную сторону тоннеля. Первое помороченее но технологически красивше, второе делается нараз и как времянка сойдет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
PommeFritz Опубликовано 7 апреля, 2007 · Жалоба Напутано с рутингом. Скорее всего пакет прилетает не с того интерфейса с которого его ожидают. Чексум бьется скорее всего в момент обратного проброса из-за неоднозначности рутинга. Не знаю почему бьется контрольная сумма, скорее не бьется она, это гон traceroute, наблюдал такое при пингах больше интервала ожидания ответов. А вот проверить насчет того, что пакет приходит с правильного интерфейса - думаю мысль хорошая. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 9 апреля, 2007 · Жалоба а с каких пор UDP натится? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 9 апреля, 2007 · Жалоба а с каких пор UDP натится? А с каких пор для ната важны протоколы выше IP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ram_scan Опубликовано 9 апреля, 2007 · Жалоба Ну, с GRE одно время были некоторые сложности... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 9 апреля, 2007 · Жалоба А с каких пор для ната важны протоколы выше IP?с тех пор как одному внешнему адресу стали ставить в соответствие более одного внутреннего. (или как вариант, пару удаленный-внутренний) поменять адрес в исходящем пакете дело не хитрое. как вы собираетесь идентифицировать обратный трафик не залезая глубже IP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 9 апреля, 2007 · Жалоба А с каких пор для ната важны протоколы выше IP?с тех пор как одному внешнему адресу стали ставить в соответствие более одного внутреннего. (или как вариант, пару удаленный-внутренний) поменять адрес в исходящем пакете дело не хитрое. как вы собираетесь идентифицировать обратный трафик не залезая глубже IP? Никак. Я изначально не совсем корректно выразился. Подразумевалось, что протокол уровня выше IP имеет вторичное значение, поскольку всякий пакет помимо IP заголовка несет заголовок соотв. протокола, согласно которого пакет можно идентифицировать как принадлежащий к конкретному потоку. Причем сделать это можно для любого протокола, независимо от того, предусматривает ли он идентификаторы потоков или нет. Примером такого подхода может служить icmp echo-reply, несущий в теле ответного пакета часть запросного для однозначной идентификации процесса-отправителя.Аналогично и нат для udp теоретически не составляет особой сложности, поскольку nat-box всегда может однозначно идентифицировать поток, к которому принадлежит конкретный пакет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 9 апреля, 2007 (изменено) · Жалоба Аналогично и нат для udp теоретически не составляет особой сложности, поскольку nat-box всегда может однозначно идентифицировать поток, к которому принадлежит конкретный пакет. сам по себе заголовок UDP не несет достаточной информации для идентификации потока, кроме не дающей никаких гарантий комбинации адресов и портов, т.к., например, разные направления могут быть с разными портами. А остальное это будет нат отдельных _приложений_ а не udp в целом. Изменено 9 апреля, 2007 пользователем desperado Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 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. Разумеется, при таком подходе возможны ошибки. Тем не менее, он обеспечивает возможность удп-ната, что и требовалось доказать. Прошу обратить внимание, что речь шла _только_ об удп. Контроль потоков самим приложением диктуется самой сутью удп. Приложения могут его осуществлять, а могут мириться с потерей пакетов, но нат-машины это уже не касается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
desperado Опубликовано 10 апреля, 2007 · Жалоба А почему Вы считаете, что комбинации адресов/портов не позволяют с достаточно высокой вероятностью успеха определить поток? потому что все зависит от приложения. я могу написать приложение которое будет отправлять с одного порта а принимать на другой, да еще и постоянно менять номер порта. еще раз - все что натится по юдп, натится не по заголовку юдп а по внутренним данным. т.е. это не нат юдп а нат приложений! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 10 апреля, 2007 · Жалоба потому что все зависит от приложения. я могу написать приложение которое будет отправлять с одного порта а принимать на другой, да еще и постоянно менять номер порта. еще раз - все что натится по юдп, натится не по заголовку юдп а по внутренним данным. т.е. это не нат юдп а нат приложений! Еще раз - сам по себе УДП позволяет достаточно успешно определять, кому принадлежит полученный пакет. Разумеется, можно для каждого пакета менять порты, можно и в TCP для каждого пакета создавать новый поток с другими портами, да только это уже не проблема протокола, а вопрос адекватности разработчика. Знаете, можно ведь и отверткой гвозди забивать, только нормальные люди используют для этого молоток. Зачем выходить за пределы возможностей протокола, чтоб потом жаловаться, что его невозможно пронатить, если можно в этих пределах оставаться и не городить огород? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 11 апреля, 2007 · Жалоба Вобщем, детальный анализ выявил только то что не натятся пакеты с плохой чексуммой. 99.9% приложений использующих UDP работают. Думаю дело в этом, но почему трейсроут создает такие пакеты - я не понимаю =( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
calculator Опубликовано 19 апреля, 2007 · Жалоба Аналогичная проблема. Win(tracert icmp) через Linux(2.6.20) работает. Сам же Linux traceroute получает только с первого хоста. И с ядром 2.6.20 и с 2.6.18 В моем случае видимо просто провайдер(корвет) балуется, потому как на работе все ок(ядро то же и tracerout той же версии). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...