Я запускаю небольшую сеть, где веб-сервер / почтовый сервер 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, включая трафик с почтового сервера. Если я отправляю ssh с хоста брандмауэра на другой внешний компьютер, соединение определяется как исходящее от 72.48.103.182.
Для меня это не имеет смысла, поскольку я специально указываю исходный IP-адрес, который должен быть преобразован через NAT. Первоначально я попробовал строку выше без «-s 172.18.90.0/24» и получил точно такой же результат.
Есть мысли о том, что происходит? Я не являюсь экспертом по iptables, но я попытался исследовать это, прежде чем отправлять на serverfault.
=======================
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
«Магическая» часть - это не правило 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
Псевдоним, который вы используете, не обязательно должен иметь специальную запись маршрута по умолчанию, поскольку, скорее всего, он маршрутизируется обратно вашим интернет-провайдером с использованием основной ссылки (адреса) вашего интерфейса.