SNAT, DNAT и Masquerade: что делает каждое правило NAT в VPN

Поставьте перехват по обе стороны VPN-шлюза, и один поток может показать четыре разных адреса. NAT источника переписывает, откуда пакет, по его словам, приходит; NAT назначения переписывает, куда он идёт. Masquerade — не третье направление, а правило NAT источника, которое берёт адрес у исходящего интерфейса вместо фиксированного значения. Назовите, какое из трёх вам действительно нужно, и большинство заявок «VPN сломан» сводятся к вопросу об обратном пути.

Что переписывает каждое правило

NAT источника, обычно записываемый как SNAT, меняет адрес источника потока, когда тот покидает маршрутизатор или шлюз. Принимающий сервис отвечает на переведённый адрес, а транслирующий узел отменяет изменение, используя состояние, которое он хранил для этого соединения. В Linux это состояние живёт в conntrack, поэтому conntrack -L печатает исходные и ответные кортежи рядом.

NAT назначения, DNAT, меняет вместо этого назначение. Пакет, адресованный публичному адресу на UDP 51820, можно переписать на внутренний сервер WireGuard по адресу 10.8.0.2:51820. Так домашний маршрутизатор или облачный балансировщик публикует слушателя VPN, и это ничего не говорит о том, что туннель может нести потом.

Masquerade относится к семейству SNAT. Правило не называет адрес; оно использует тот, который есть у исходящего интерфейса в момент ухода пакета. Linux даёт ему собственную цель, и это обычный выбор на интерфейсе WAN, получающем адрес по DHCP или PPPoE.

Где живёт отображение, там и определяется сбой

Записывайте кортеж на каждой границе: до туннеля, внутри него и на публичном интерфейсе. Перехват внутри туннеля законно отличается от перехвата снаружи, и тот, кто сравнивает их, не зная, где происходит трансляция, будет гоняться за не тем хостом.

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

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

Masquerade или явный SNAT

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

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

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

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

Чтение правил на шлюзе Linux

Шлюзу удалённого доступа с клиентами в 10.8.0.0/24 и интерфейсом WAN по имени eth0 нужны включённая пересылка и политика фильтрации, разрешающая поток, прежде чем любое правило NAT поможет. Версия с iptables держит оба направления в таблице nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Форма nftables использует те же два хука с именованным интерфейсом и явной цепочкой:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Оба фрагмента предполагают, что цепочка фильтрации уже принимает пересылаемый поток. NAT не является правилом разрешения, и корректно переведённый пакет всё равно может быть отброшен одной таблицей позже. Подтвердите живое отображение с помощью conntrack -L, подтвердите, что загружено, с помощью nft list ruleset или iptables-save -t nat, а затем снимите перехват на обоих интерфейсах, чтобы увидеть, что адрес действительно меняется.

Режимы сбоя, похожие на плохое правило

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

Двойная трансляция — тихая. Клиент, уже находящийся за NAT операторского уровня, приходит на ваш шлюз с адресом, который вы не можете маршрутизировать обратно, поэтому вы транслируете снова. Это работает, но журналы теперь несут два перехода частной адресации, и любому расследованию нужны оба отображения. IPsec на основе политик добавляет третий поворот: транслируйте до совпадения политики, и вы получите поднятый SA, по которому не идёт трафик, что читается как ошибка межсетевого экрана, а не NAT.

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

Контрольный список перед сохранением правила

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

Проверяйте с клиента, а не со шлюза. Браузер на самом шлюзе может полностью обойти правило трансляции для клиентов, поэтому работающая там страница ничего не доказывает о туннеле. Отправьте один запрос, инициированный клиентом, наблюдайте за счётчиками и таблицей conntrack и повторите после переподключения туннеля и смены адреса WAN, если хоть одно из этого возможно там, где вы работаете.