Traceroute + ng_nat

Kristian

Доброе всем утро.
Столкнулся со следующей странностью. (может даже баг

).

Я использую ng_nat на фаерволе.

/usr/sbin/ngctl mkpeer ipfw&#58; nat 100 out
$cmd netgraph 100 ipv4 from table\&#40;6\&#41; to not table\&#40;100\&#41; out via $oif
$cmd netgraph 101 ipv4 from not table\&#40;100\&#41; to $NatIP in via $oif

Так вот, когла я пробую трассировать с этого фаервола в мир -
получается странная ситуация.

Код: Выделить всё

&#91;root@gw /etc/ipfw&#93;# traceroute -P icmp -z 500 -w 2 -q 1 ukr.net
traceroute to ukr.net &#40;195.214.195.105&#41;, 64 hops max, 60 byte packets
 1  *
 2  *
 3  *
 4  195.214.195.105 &#40;195.214.195.105&#41;  1.357 ms

Подскажите пожалуйста, кто использует нетграф - у вас та же беда ?
Причем те люди которые за фаерволом - прекрасно все трасируют.

Kristian

Неужели никто на это не обращает внимания ?
Фаер ничего не режет. пробовал разрешать все.

Ata-man

То же самое при использовании ng_nat. В мэйллистах в прошлом году писали что-то про это. Но не знаю, пофиксили или нет.

JAO · Сообщение **JAO** » Чт апр 16, 2009 16:35

Адрес, в который натятся, совпадает с внешним адресом машинки? Если да, то я на эти грабли в свое время тоже наступал. Фиксить там ничего не надо, поскольку не ошибка.

Происходит по сути вот что.

Все пакеты изнутри проходят NAT, при этом там создается запись на этот пакет, и все пакеты, приходящие на внешний адрес, попадают туда же. Так вот, входящий извне пакет уже имеет запись в таблице адресов, адрес успешно подменяется на оригинальный серый и пакет летит во внутреннюю сетку. У человека все работает.

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

Итак, если адрес NAT и адрес самой машинки совпадают, то всё, что выходит из внешнего интерфейса, должно завертываться в NAT, не только проходящие пакеты, но и пакеты от самого роутера. Добавьте в фаервол соответствующее правило.

Это действительно при работе с любым NAT. Просто в зависимости от реализации он может пропустить пакет, по которому нет данных в таблице, а может и не пропустить.

Kristian

Большое вам спасибо за ответ. Наконец то я понял

Slad · Сообщение **Slad** » Сб апр 18, 2009 07:31

Повесить нат на другой ип, проблем не будет

JAO · Сообщение **JAO** » Сб апр 18, 2009 16:26

В последнее время так и делаю. Но кое-где все еще натятся во внешник роутера, поэтому расписал решение именно в этой ситуации.

Arti · Сообщение **Arti** » Сб апр 18, 2009 21:39

Не знаю мне такая ситуация наоборот нравится. У меня IP адреса NAT не принадлежат ни одному интерфейсу. Т.е. они как-бы висят в воздухе.

JAO · Сообщение **JAO** » Вс апр 19, 2009 14:56

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

Arti · Сообщение **Arti** » Вс апр 19, 2009 18:29

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

Кстати говор я не уверен что публиковать что-то через arp здесь вообще уместно. Обычно роутер весит на /30. Куда чего будет анонсироваться мне не особо понятно.

JAO · Сообщение **JAO** » Пн апр 20, 2009 06:23

А это смотря как сеть построена. Если подняты протоколы маршрутизации, то лучше их использовать, а если все гораздо проще, то почему бы и в arp не засветить?

nevzorofff

JAO писал(а):Адрес, в который натятся, совпадает с внешним адресом машинки? Если да, то я на эти грабли в свое время тоже наступал. Фиксить там ничего не надо, поскольку не ошибка.

Происходит по сути вот что.

....

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

Вот только поведение sshd, запущенного на маршрутизаторе и сквида не укладывается в вашу теорию: пакеты, предназначенные для sshd проходят нат и попадают нему на порт, а никаких записей в таблице нат нету, ибо подключение устанавливается снаружи, да и сквид, запущеный на маршрутизаторе никаких записей в нат не создают, а ответные пакеты ему снаружи прилетают.
И третье - в первом после трасерт весь в звёздах кроме последнего узла, к которому шёл трасерт - пакет таки долетел до утилиты даже через нат.

JAO · Сообщение **JAO** » Вт окт 20, 2009 09:18

Адреса ICMP ответов от промежуточных роутеров не соответствуют адресу последнего узла. Я не говорил, что пакет не улетает. А будет ли он обратно пропущен, если идет вот такое несоответствие? звезды показывают как раз, что нет. В случае со сквидом и sshd такого несоответствия нету. Потому все и работает. Тем более если от них пакеты через NAT не идут.

nevzorofff

JAO писал(а):Адреса ICMP ответов от промежуточных роутеров не соответствуют адресу последнего узла.

А кем это соотвествие проверяется, если запросы от traceroute не проходят через nat?
А как быть с пакетами на установление соединения на порт sshd, если там в принципе никакого соответствия ещё быть не может, т.к. прилетел первый пакет.

да и ещё - за нат-то такие пакеты вполне успешно пролетают, не смотря на соответствие отвечающего и того, кому послан запрос

трасерт за натом исправно работает.

JAO · Сообщение **JAO** » Вт окт 20, 2009 10:41

Чтобы до конца ответить на все вопросы, требуется порыться в исходниках по теме трансляции адреса. Была проблема. Нашел решение. Изложил свое понимание произошедшего. Правильное оно, неправильное - не суть важно уже, решение есть, где надо - поправят. Не вдавался в это сильно и не хочу вдаваться.