Путаница после обновления FedoraCore: проблемы с NAT / переадресацией портов и POSTROUTING MASQUERADE неожиданно влияет на пересылку портов

После аппаратного сбоя системы шлюза / брандмауэра на новом оборудовании была установлена ​​младшая версия Fedora Core (17), и использовались старые файлы iptables и system-config-firewall из / etc / sysconfig (и ничего больше). Старая версия FC неизвестна, но, вероятно, это была 14 или 15 версия, старый диск больше не читается. (Я поместил содержимое бывшего файла iptables ниже.)

Работа этой системы ИСКЛЮЧИТЕЛЬНО:

1. Принимать порт 22 (ssh) из любого сетевого источника для локальной доставки (sshd).
2. Перенаправить порт 222 на порт 22 (ssh) внутренней системы, сохранив исходный IP-адрес.
3. Перенаправить порт 25 (электронная почта) во внутреннюю систему, сохранив исходный IP-адрес.
4. Перенаправить весь входящий трафик (не через порт 22) из ​​внутренней сети во внешнюю, применяя NAT / маскарадинг по пути и разрешая прохождение связанных, сгенерированных извне возвратных пакетов, при необходимости.

Описанные выше действия являются ЕДИНСТВЕННОЙ работой этого окна, и раньше он работал нормально.

С чего я начал:

При возврате в работу все подключения к порту 22 (sshd) работают нормально, а внешние подключения ко всем другим портам пересылаются или отбрасываются в зависимости от обстоятельств, но IP-адрес, видимый внутренними системами, был IP-адресом шлюза, а не сохранял исходный IP-адрес. адрес.

Когда я подключаю систему к сети, вся черта с электронной почтой ломается; система почтового сервера за шлюзом отклоняет почту на основании несоответствия IP-адреса / имени системы, а устранение проверки сводит с ума систему фильтрации спама.

МАСКИРОВАЛ неправильный интерфейс, НО ...

Внимательный участник сбоя сервера Дэвид Шварц отметил, что маскарадинг был включен для ВНУТРЕННЕГО интерфейса (через -A POSTROUTING -o eth0 -j MASQUERADE), объясняя, что внутренние системы видят IP-адрес шлюза, НО при изменении для отражения внешнего интерфейса (например: - A POSTROUTING -o eth1 -j MASQUERADE), затем ВСЕ ПЕРЕАДРЕСАЦИЯ ОСТАНАВЛИВАЕТСЯ! Да, я имею в виду переадресацию портов с внешнего на внутренний (порт 222 - порт 22 во внутренней системе).

Я действительно этого не понимаю.

Для наглядности это появляется что маскировка включена для ВНУТРЕННЕГО интерфейса, хотя это и не было запланировано, но ДЕЙСТВИТЕЛЬНО имеет положительный атрибут разрешения перенаправления портов на самом деле извне внутрь. Переключение на маскировку (правильного) ВНЕШНЕГО интерфейса каким-то образом отключает переадресацию портов, так как других изменений НЕТ.

SNAT против маскарадинга

Поскольку есть две внешние «серверные системы», у которых также есть внутренние интерфейсы, которые были настроены как альтернативные исходящие пути, я посмотрел на них и обнаружил, что у них совершенно другая техника маскировки; не было такой строки, процитированной двумя абзацами выше, а вместо этого:

-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to-source <external.v4.ip.addr>  

Отлично - я понимаю, это имеет смысл, я пробую это! Я закомментировал строку MASQUERADE и включил (в той же позиции) строку SNAT, как указано здесь, и УРА! Он сделал две вещи:

1. Я получаю желаемую трансляцию исходящих сетевых адресов и;
2. Теперь он перенаправляет входящие запросы на соединение на порт 222 извне на порт 22 внутренней системы, сохраняя исходный IP-адрес по желанию.

Оставшаяся проблема

Что значит не work - это идентично перенаправляемый порт 25 (который должен оставаться портом 25 во внутренней системе).

В настоящее время я должен решить ЭТУ проблему! (И чем раньше, тем лучше!) Почему один порт переходит вперед, а другой нет? Разве это не порт типа tcp, и если нет, то чем его следует заменить? (Я не думал, что это UDP ...)

Менее важно; было бы неплохо узнать, почему старая конфигурация работала, но теперь не работает! Различия в Fedora Core? Обновления таблиц IP? Я полагался на ошибки? -улыбка-

Вот две строки переадресации портов в iptables:

-A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to-destination 192.168.0.64:25
-A PREROUTING -i eth0 -p tcp --dport 222 -j DNAT --to-destination 192.168.0.64:22

Пробовал с завершающим ": 25" на верхнем и без него. Опять же, внешний порт 222 пересылает на внутренний системный порт 22 нормально, порт 25 не пересылает вообще.

Обратите внимание, что доступ telnet к порту 25 из системы, которая может видеть систему почтового сервера напрямую (не через шлюз / брандмауэр), работает отлично. Кроме того, я попробовал перенаправить порт 24 на порт 25 в качестве теста и получил тот же результат (без ответа).

Вот файл iptables:

# eth0 is internal
# eth1 is external

*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

# NO packets get through without this next line:
-A POSTROUTING -o eth0 -j MASQUERADE
# the above line was commented out and replaced with:
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to-source <external.v4.ip.addr>

-A PREROUTING -i eth1 -p tcp --dport 25 -j DNAT --to-destination 192.168.0.64:25

-A PREROUTING -i eth1 -p tcp --dport 222 -j DNAT --to-destination 192.168.0.64:2
2

COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 222 -j ACCEPT

-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
-A FORWARD -i eth1 -m state --state NEW -m tcp -p tcp -d 192.168.0.64 --dport 25
 -j ACCEPT
-A FORWARD -i eth1 -m state --state NEW -m tcp -p tcp -d 192.168.0.64 --dport 22
 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT