Маршрутизируйте трафик между частными LAN, прежде чем добавлять ещё один NAT

Два внутренних межсетевых экрана, один частный транзитный сегмент и просьба разрешить нескольким хостам в каждой LAN общаться с хостами другой. Обычная реакция — поднять VPN или добавить второй слой NAT, и обе реакции стоят дороже, чем заслуживает проблема. Обычной маршрутизации достаточно, когда выполняются три условия: диапазоны адресов не пересекаются, обе стороны могут возвращать трафик в другую LAN, а транзитный сегмент уже достаточно доверенный для этих данных. Проверьте эти три вещи, прежде чем что-либо проектировать, потому что каждое из них меняет ответ.

Три условия, которые определяют проект

Первое условие — адресное пространство. Если обе LAN используют один и тот же блок RFC 1918, маршрутизация не может их различить, и трансляция становится неизбежной, а не опциональной. Второе — обратный путь: маршрут из A в B бесполезен, если B тоже не знает, как добраться до LAN узла A, а асимметричное знание — самая частая причина, по которой маршрутизируемый проект молча отбрасывает ответы.

Третье — доверие. Маршрутизация перемещает пакеты; она их не защищает. Частный транзитный сегмент внутри одного здания — это не то же самое, что передача провайдеру или линия, пересекающая общий кампусный магистральный канал. Если сегменту не доверяют, ответ — туннель между двумя межсетевыми экранами, и план маршрутизации ниже всё ещё действует внутри него.

Простой проект побеждает только тогда, когда все три указывают в одну сторону. Когда одно из условий нарушено, исправляйте именно его, а не маскируйте трансляцией, потому что NAT скрывает сбой, а не устраняет его.

Постройте план маршрутов на транзитной сети

Дайте каждому межсетевому экрану адрес в общем сегменте и добавьте по одному конкретному маршруту для каждой удалённой LAN. Больше ничего в существующей конфигурации двигать не нужно, и в особенности маршрут по умолчанию в интернет должен остаться точно там, где он есть. Замена маршрута по умолчанию на партнёрский экран отправила бы каждый посторонний адрес через транзит, что является куда большим изменением, чем запрошенное. Документация pfSense по статической маршрутизации описывает ту же модель маршрут плюс шлюз для этой платформы, а эквивалентная настройка есть на любом экране, который вы действительно используете.

Экран A обслуживает 10.30.0.0/24, а экран B обслуживает 10.40.0.0/24, причём два транзитных адреса находятся в 192.0.2.0/24. Каждый хост LAN сохраняет свой локальный экран в качестве шлюза, поэтому единственное новое состояние — по одному маршруту с каждой стороны. На экране под управлением Linux тот же план выглядит так, и пересылка должна быть включена, иначе маршрут разрешится, а пакет будет отброшен.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Держите фильтрацию отдельно от трансляции

Маршрутизация и политика — разные средства управления, и именно на втором большинство маршрутизируемых проектов действительно терпят неудачу. Разрешайте конкретные источники, назначения и сервисы на той входной границе, которую пакеты действительно пересекают, и помните, что метка интерфейса вроде WAN — это имя, а не заявление о доверии. На транзитном порту, несущем частный трафик, блокировка частных адресов может по-прежнему быть включена по умолчанию.

Затем посмотрите на исходящую трансляцию, прежде чем заключить, что NAT не происходит. Автоматические исходящие правила могут переписывать трафик, который никогда не предназначался для трансляции, и это уничтожает адреса источника, нужные другой стороне для её собственной политики и журналов. Убедитесь, что выбранные потоки сохраняют исходные адреса, и не трогайте правила интернет-трансляции для трафика, которому они всё ещё нужны.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Когда NAT — честный ответ

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

Последствие, которое нужно произнести вслух, состоит в том, что другая сторона больше не может видеть или фильтровать отдельные источники. Журналы схлопываются в транслирующий адрес, политика по хостам перестаёт работать, а поиск неисправностей превращается в охоту за тем, какой внутренний хост владел потоком в данный момент. Если ничего из этого не важно для рассматриваемого трафика, NAT вполне подходит.

Когда сам транзит — неверное допущение

Если общий сегмент проходит через провайдера, общую коммутационную фабрику или любой путь, где другая сторона могла бы читать трафик, одной маршрутизации недостаточно для полного ответа. Туннель между двумя экранами даёт конфиденциальность и аутентификацию партнёра, а таблица маршрутов внутри него — та же таблица, которую вы написали бы на транзите.

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