Загадка NAT для IPtables: почему трафик с хоста брандмауэра преобразуется в NAT, даже если он не идет с одного из заданных адресов источника?
Я управляю небольшой сетью, где веб-сервер и почтовый сервер Linux также предоставляют NAT для набора оконных коробок. Одна из этих машин с Windows, по-видимому, плохо себя ведет (ботнет ZeroAccess, хотя я не могу найти никаких проблем с использованием Norton PowerEraser и смог найти только 3 исходящих порта 16465 пакетов в /var/syslog за недели регистрации). По какой-то причине установка правила брандмауэра для отбрасывания всех исходящих пакетов 16465 также не решает проблему, но это не связанная проблема.
Эта проблема приводит к тому, что почтовый сервер заносится в черный список, например, spamhaus.org. Поскольку я не могу найти зараженный хост Windows, я натолкнулся на идею использования псевдонимов IP для отправки трафика NAT через другой IP-адрес.
Внешний интерфейс:
eth0: 216.82.212.230
eth0:1 72.48.103.182
Внутренний интерфейс:
eth1: 172.18.90.1
В моих правилах брандмауэра я затем изменил
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 216.82.212.230
в
iptables -t nat -A POSTROUTING -s 172.18.90.0/24 -o eth0 -j SNAT --to 72.48.103.182
Проблема в том, что теперь все выглядит как 72.48.103.182, включая трафик с почтового сервера. Если я перейду с хоста брандмауэра на другой внешний компьютер, соединение будет определено как 72.48.103.182.
Это не имеет смысла для меня, так как я специально указываю исходные IP-адреса, которые должны быть NAT. Первоначально я попробовал строку выше без "-s 172.18.90.0/24" и получил точно такой же результат.
Есть мысли о том, что происходит? Я не эксперт по iptables, хотя приложил много усилий, чтобы попытаться исследовать это, прежде чем отправлять сообщения на сервер.
=======================
root@www:etc# ip ro
216.82.212.0/24 dev eth0 proto kernel scope link src 216.82.212.230
72.48.103.0/24 dev eth0 proto kernel scope link src 72.48.103.182
172.18.90.0/24 dev eth1 proto kernel scope link src 172.18.90.1
default via 216.82.212.254 dev eth0 src 72.48.103.182 metric 100
default via 216.82.212.254 dev eth0 metric 100
2 ответа
"Волшебная" часть - это не правило SNAT или таблица NAT в целом, это запись таблицы маршрутизации:
default via 216.82.212.254 dev eth0 src 72.48.103.182 metric 100
оно говорит вашему ядру использовать 72.48.103.182 для исходящих локально инициируемых соединений (при условии, что сокет не связан явно с конкретным адресом при создании), если пункт назначения доступен через этот маршрут - что будет иметь место для всех " внешние "направления, так как это ваш маршрут по умолчанию. Вы должны переопределить это как
default via 216.82.212.254 dev eth0 src 216.82.212.230 metric 100
чтобы получить ожидаемое поведение.
Итак, как я и думал, ваш сервер просто использует этот IP как исходящий. На самом деле вам не нужны 2 маршрута по умолчанию, и это даже вводит в заблуждение. Вы должны использовать только один:
ip ro add default via 216.82.212.254
Псевдоним, который вы используете, не требует специальной записи маршрута по умолчанию, так как более вероятно, что он перенаправляется вашим провайдером по основной ссылке (адресу) вашего интерфейса.