Стоит ли применять SNAT при переадресации порта в подсеть VPN?

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

Почему ответ уходит другой дорогой

Переадресация порта переписывает, куда идёт пакет, но никогда — откуда он пришёл. Адрес интернет-клиента остаётся в поле источника на всём пути через туннель, поэтому удалённая служба видит незнакомца и отвечает единственным известным ей способом: через свой шлюз по умолчанию. Этот шлюз — концентратор VPN на дальней стороне, у которого нет маршрута обратно к произвольному публичному адресу.

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

Правило источника, достаточно узкое, чтобы ему доверять

Сделайте роутер источником, которому отвечает удалённый хост. В этой схеме адрес WAN — 203.0.113.24, LAN — 192.168.88.0/24, адрес туннеля роутера — 172.20.5.1, а служба отвечает на 172.20.5.40:8443. Правило ниже совпадает с пакетом после трансляции назначения, поэтому в нём указан транслированный адрес, а не публичный. Ничто в нём не зависит от адреса клиента, и именно в этом суть.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

Когда сплошная маскировка — честный выбор

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

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

Проверьте счётчики перед публикацией

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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