VPN на роутере или проброс порта: что победит?

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

Один порт, два заявленных владельца

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

Запишите претензию перед редактированием: семейство, внешний адрес, транспорт, порт и транслируемую цель.

Трансляция выполняется до локальной проверки

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

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

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

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

Оставьте одно сопоставление и удалите другое

Перечислите записи NAT для этого порта и семейства и выберите выжившего:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Запись TCP с тем же номером не относится к отказу UDP, а обращение с ними как с одним объектом ведёт к удалению не того правила. Когда локальный сокет должен победить, владелец конфликтующего сопоставления удаляет или переписывает именно эту запись, а входящее разрешение для собственного порта роутера остаётся на месте. Несвязанные пробросы, путь управления и копия набора правил должны пережить изменение.

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

Подтвердите владельца снаружи

Проверяйте каждое семейство отдельно, потому что соединение IPv6, завершающееся на роутере, ничего не говорит о соединении IPv4, которое перенаправляет устаревшее правило. Читайте журнал принимающей службы, чтобы увидеть, какая конечная точка ответила, и считайте сообщение об успехе клиента слабым доказательством. Для осмысленной проверки нужен новый поток. Отправьте зонд с внешнего хоста с помощью nc -zvu 203.0.113.7 1194 и прочитайте журнал победителя с помощью journalctl -u openvpn@server -n 20. Слушатель роутера фиксирует соединение сам, а хост локальной сети — в своей службе.

Отслеживание соединений удерживает существующие потоки на их исходном сопоставлении, поэтому установленный сеанс может пережить правило, которое вы только что исправили.

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