Как правильно обрабатывать DNAT, когда трафик покидает другой интерфейс, чем прибыл? Когда это происходит, кажется, что в ответе адрес источника не заменяется автоматически, как если бы он выходил из того же интерфейса, на котором прибыл.
Изменить - SNAT не работает для меня:
Chain PREROUTING (policy ACCEPT 386 packets, 23372 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all -- * * 0.0.0.0/0 12.12.12.5 to:10.7.0.5
Chain POSTROUTING (policy ACCEPT 288 packets, 18672 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * eth0 10.7.0.5 0.0.0.0/0 to:12.12.12.5
0 0 SNAT all -- * eth3 10.7.0.5 0.0.0.0/0 to:12.12.12.5
8 550 MASQUERADE all -- * eth0 172.16.14.0/30 0.0.0.0/0
0 0 MASQUERADE all -- * eth0 10.7.0.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 23 packets, 1572 bytes)
pkts bytes target prot opt in out source destination
Таким образом, в приведенном выше примере оба маршрутизатора имеют одинаковые таблицы и одинаковую схему интерфейса. eth0 на обоих маршрутизаторах является подключением к Интернету, а eth1 на каждом маршрутизаторе подключается к одной и той же локальной сети (10.7.0 / 24). eth3 соединяет два маршрутизатора друг с другом.
Что происходит, я проверяю адрес 12.12.12.5 из местоположения в Интернете. Ответы поступают на маршрутизатор B через eth0 и через eth1, при этом nat назначения работает нормально. Ответы поступают на eth1 на маршрутизаторе A и выходят из Интернета через eth0 на маршрутизаторе A. Однако исходный адрес не перезаписывается, и ответы возвращаются на устройство, отправляющее эхо-запросы с адресом 10.7.0.5 *.
* Да, они на самом деле делают это через 20 переходов с частным исходным IP и нигде не раздавлены - отчасти потрясающе).
Еще больше редактировать:
Хорошо, очевидно, что SNAT (по крайней мере, это видно из руководства iptables) соответствует только в том случае, если он сохраняет состояние. Значит мне нужен нац без гражданства. Это можно сделать с помощью iproute2, но согласно http://linux-ip.net/html/nat-dnat.html#ex-nat-dnat-full его также можно смоделировать, используя --to-destination с SNAT в iptables. Однако мой ubuntu 10.04 просто говорит о неизвестном варианте --to-destination...
С веб-трафиком это становится все более распространенным. Есть ли конкретный сценарий, который вас беспокоит? У меня нет SNAT, отражающих все мои DNAT.
Сценарии, которые меня волнуют ..
Насколько я понимаю, практическое правило - избегать этого, когда это разумно. Но с современными реализациями и динамической маршрутизацией я считаю, что эта перспектива становится все более устаревшей.
Насколько мне известно, описываемое вами поведение при перезаписи адресов будет происходить до тех пор, пока исходящий ответный пакет маршрутизируется тем же маршрутизатором, который маршрутизировал входящий запрос / DNAT. Однако, если какой-либо другой из маршрутизаторов N + 1 в пуле маршрутизаторов высокой доступности обрабатывает исходящий ответный пакет, они не «увидят» это соединение в базе данных состояний Netfilter.
Похоже, ты хочешь высокодоступный маршрутизатор Netfilter, который разделяет информацию о машине состояния NAT. Упомянутый в этой статье инструмент ct_sync по большей части заброшен, но Conntrackd Инструмент из conntrack-tools был разработан для выполнения некоторых из тех же функций, что и ct_sync.
Если вы планируете выполнять фильтрацию пакетов с отслеживанием состояния (или NAT, который на самом деле является просто надмножеством фильтрации пакетов с отслеживанием состояния), вам понадобится метод для распространения базы данных состояний (или, в качестве альтернативы, переходите с фильтрацией без отслеживания состояния в сеть и выполнять фильтрацию с отслеживанием состояния на каждом хосте).