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. Слухач роутера фіксує з'єднання сам, а хост локальної мережі — у своїй службі.

Відстеження з'єднань утримує наявні потоки на їхньому початковому зіставленні, тому встановлений сеанс може пережити правило, яке ви щойно виправили.

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