[трава] nat в линухе

бридж в сторону аплинка? :-\

а что значит [трава]? :)

что не так?

потому-что естаблишед коннектион.

Ооо, трава, если верить conntrack -L то на каждый пакет icmp он создаёт правило udp. Приколисты.

Вот один пинг выглядит так: ipv4 2 udp 17 27 src=172.15.1.2 dst=172.15.1.1 sport=44950 dport=53 packets=1 bytes=72 src=172.15.1.1 dst=172.15.1.2 sport=53 dport=44950 packets=1 bytes=153 mark=0 secmark=0 use=1

Если послать 100 пингов на удалённый хост то conntrack -L -s 172.15.1.2 | wc -l показывает 100. Ахренеть.

Но если на каждый echo/reply создаётся отдельное новое правило то значит не должно быть указанных проблем с "залипанием" контракнутого правила, верно?

нет
на пинги udp-шный con не создается.
скорей всего это резолв идет, чтоб в консоли рисовалось имя хоста.
con создается именно на icmp поток.

вот он и залип.

>потому-что естаблишед коннектион.
што?

по сабжу тоже заметил странный глюк пинга, если не было долго связи а потом появляется связь то на stdout всеравно продолжают сыпаться сообщения что связи нет (точно не помню толь про net толи про что) пока не перезапустишь ping

то есть это реализация ping такая чтоли?
в винде например такого вроде бы нет, доступный хост сразу начинает пинговаться после восстановления связи

icmp timeout и интервал между отправленными пакетами - слвершенно разные веши.

Не понял причем тут таймаут и интервалы, в дебиане емнип я получал вроде network unreachable пока не перезапускал ping

> што?

коннтрак умеет отслеживать и состояние(установлено/неустановлено) для stateless соединений.

Да, помсотрел снифером, это резолв.

Причину нашёл. Действительно "залипает". И я понял почему не могу найти нужное соединение. Как только пакет отправляется создаётся "временное правило". Когда приходит echo reply правило тут же уничтожается(а не висит как с udp). Поэтому я ничего и не смог найти в условиях когда сеть работает нормально. Другое дело если удалённая сторона не отвечает. В таком случае появляется куча icmp-стейтов с [UNREPLIED]-состоянием.

В общем, я зря предполагал что conntrack для icmp и udp работает одинаково, из-за этого шёл не в том направлении.

То есть умеет, но не очень адекватно, оттого ping и глючит в linux?

И похоже мы немного о разных проблемах говорим, только что заметил, я пинговал именно IP

отслеживает он абсолютно адекватно, просто пока не придёт ответ будет висеть соединение в таблице состояний. А пока оно висит то ответ тем более не придёт. Это связано с некоторыми оптимизациями в ядре, многие вещи делаются только один раз на этапе установки соединения. Поэтому и нужно создать новую "сессию"(чтобы сменился icmp id). Как раз перезапуск ping заставит его генерировать пакеты с другим id, создастся новое правило и всё заработает.

Меня в коннтрак другое беспокоит. Фря умеет не создавать временные правила если они не нужны(т.е. путь пакета строго детерменирован). Линух тупо создаёт правила на всё что движется. Меня это раздражает. Есть правило NOTRACK, но это костыль и у него есть нюансы.

ping всегда ip пингует. доменное имя это не есть адрес в ip-сети, это, считай, алиас на ip.

да, я знаю что такое dns :)

не пойму только, проблема именно в рутере с nat или linux-клиент с которого пингуют (его таблица состояний) тоже частью проблемы является?

"проблема" в коннтраке. Т.е. да, со стороны роутера. Но это не баг, это фича, она документирована.

hizel, ты так и не сказал чем плох бридж в сторону аплинка :). И по-другому работать не будет, проверял. Не понял только почему если адрес повесить на интерфейс а не на бридж(бридж оставить без адреса) то сеть не пашет. Хотя, тут, возможно, заморочка с арпами, лень сидеть со снифером и смотреть.

А вот и не совсем так
только что специально проверил что меня смущало
два компа - на одном Linux + ping 4.2.2.2 на другом WinXP и ping -t 4.2.2.2
сбой wan - перезагружаю роутер - win продолжает пинговать 4.2.2.2 дальше а в Linux на консоле висит icmp_seq=247 и дальше ничего не идёт (снифер видит icmp запросы с id 59428 которые остаются без ответа) после перезапуска ping id меняется и всё снова рпингуется.
А вот на виндовом ping что интересно id всегда равен 512 сколько не перезапускай...

а чорт его знает, схема сети не известна, паранормальные способности отстрелил на третьем месяце духанки вместе с нервами и совестью, но по опыту там где фигирирует бриджна самом деле должен быть коммутатор(возможно третьего уровня с ip unnumbered) :o)

что то вы странное говорите.

не согласен, возможности линуха сильно шире любого свитча в плане контроля трафика. Какой коммутатор детектит рассылки спама с клиентов? :).

Ну а на этой тачке бридж служит для выхода виртмашин в сетью. Т.е. в бридже стоят eth0, tap0, tap1 ... Без бриджа никак.

Ууу, тупые винды :). Да, действительно странный случай. Тут надо смотреть таблицу состояний. Возможно, винды не успели "залипнуть".

>Возможно, винды не успели "залипнуть".
вот как то так они всегда не успевают залипнуть :) или же это связано именно с постоянным id=512 у вендового пинга

Возможно, в коннтрак есть воркэраунд для глючных виндов, лень в сырцы лезть.