[iptables] Тонкости реализации NAT

Первое: любое обращение хоста 192.168.1.4 куда-либо по протоколу udp, будь то dig @8.8.8.8 ya.ru или sip и т.д. будут направляться на хост 216.216.216.216 (на соот. порт, ессно). А будет это осуществляться благодаря второму правилу: немаршрутизируемые адреса меняются (source) на айпишнек eth1.

Всё это хорошо видно при поможи conntrack -L

Это понятно. Пример так и был построен. Вопрос в том, будут ли приходить ответы? Я, к сожалению, не знаю, как проверить. Ну нет у меня под рукой ни роутера на Linux, ни сервера, который бы мне ответы усердно слал. Есть только ADSL-модем с встроенным NAT'ом да локальная машина, откуда я могу что-то отправить. Вот и спрашиваю. Так бы конечно и сам проверил и в логах посмотрел. Схема прохождения пакетов через роутер у меня на бумажке нарисована. На бумаге все замечательно выглядит, а как будет на самом деле? Я не нашел в сети информации о принципах работы nat в netfilter.

Попытаюсь еще раз объяснить. Я прекрасно понимаю, что nat в netfilter отлично работает и с DNAT, и с SNAT, и с MASQUERADE. Но по отдельности! А если пакет проходит по очереди два правила в таблице NAT, то ответный пает потом сможет найти путь до клиентской машины? Можно ли делать цепочки из правил в таблице NAT??? Вот как-то так. Ведь легко может оказаться, что netfilter смотрит только первое или последнее преобразование. Или еще он может разрешать преобразования в таком же порядке, что и при отправке пакета изнутри сети (то есть опять сначала DNAT, потом MASQUERADE, а должен бы наоборот). Тогда он точно потеряет адрес назначения!

Если никто не знает ответа, придется видимо в исходниках ядра опять копаться. Хотя разбираться в дебрях кода netfilter, касающихся nat еще то удовольствие!

Не надо нигде копаться, я же давал схему, по-моему: http://upload.wikimedia.org/wikipedia/ru/a/ad/Netfilter-diagram-rus.png

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

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

Как раз, схема очень хорошая. В ней явно видно, что сначала отрабатывает при входе пакета conntrack (разначинвание, по рабоче-крестьянски). А уже потом net PREROUTING с DNAT.

Смотрите внимательнее.

s/net PREROUTING/nat PREROUTING/

> Если никто не знает ответа, придется видимо в исходниках ядра опять копаться. Хотя разбираться в дебрях кода netfilter, касающихся nat еще то удовольствие!

Рано Вам ещё в исходниках-то «копаться». Читать доки сначало научиться бы...

> Можно ли делать цепочки из правил в таблице NAT?

Не поверите, но именно для этого и был создан iptables.

Двойной НАТ обычная устоявшаяся практика, а не нечто недокументированное.

Кстати, можно такой эсперимент провести:

-A testing_dnat -s 192.168.5.2/32 -d 83.239.131.8/32 -p udp -j DNAT --to-destination 8.8.8.8:53

Дан маршрутизатор с двумя интерфейсами, один в лок. сеть eth1, другой в интернет eth0. И так, что мы делаем, а делаем мы следующее: на каком-нибудь клиенте (192.168.5.2, винда попалась под руку) запускаем

nslookup
> server 83.239.131.8
>ya.ru

tcpdump -i eth1 host 192.168.5.2 and host 83.239.131.8

и

tcpdump -i eth0 src host 8.8.8.8

клиент думает, что ответ пришёл от 83.239.131.8, но мы то знаем.

И соответственно, вывод: сначала DNAT, потом SNAT, потом уже клиенту, и не забываем про conntrack :)

Не вижу ни одной причины, чтобы ответные пакеты не дошли до 192.168.1.4. Хоть 10 правил напиши, это ничего не меняет. Соединения будут отслеживаться с помощью conntrack, и в ответных пакетах будут сделаны необходимые изменения, чтобы пакеты дошли до 192.168.1.4.

А я вот увидел возможные причины, почему пакеты могут не вернуться, и во всех руководствах по iptables сказано просто, что пакеты маршрутизируются автоматически, а каким образом нигде не сказано. Мне совсем не хочется потратить время на разработку, которая ВДРУГ окажется неработоспособной из-за некорректной работы netfilter. В итоге, я все-таки залез в исходники и посмотрел все, что мне нужно. Всем спасибо, что пытались учить меня, не вникнув в суть вопроса. Для себя я уже все выяснил. Параллельно подтвердил свое предположение, что таблица маршрутизации в netfilter хранится в хеш-таблице, которая считает хеш по адресам источника и получателя и по номеру протокола.

> Всем спасибо, что пытались учить меня, не вникнув в суть вопроса. Для себя я уже все выяснил.

Извини, бывает :-).

таблица маршрутизации в netfilter

Это 5.