Домашний VPN-сервер недоступен: пройдите цепочку NAT

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

Начните со страницы WAN маршрутизатора

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

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

Поднимитесь на один переход выше

Запустите traceroute с самого маршрутизатора и прочитайте первые переходы. Повторяющиеся публичные адреса, первый переход, отвечающий частным адресом, или адрес внутри общего диапазона 100.64.0.0/10 всё это указывает на транслятор выше. RFC 6598 определяет этот диапазон именно для такого развёртывания, поэтому видеть его в поле WAN сильный сигнал, а не курьёз. Два транслятора на пути делают след менее очевидным, поэтому читайте закономерность, а не одну строку.

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

Подтвердите слушатель и проброс

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

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

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

Меняйте топологию, а не то же правило

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

Динамический DNS обновляет только имя; он не создаёт доступность, а указание на общий адрес отправляет клиентов к шлюзу провайдера, которым пользуются и другие абоненты. Этот сбой выглядит точно как мёртвый сервер, поэтому запись предыдущих шагов важна. Запишите, в какой адрес разрешилось имя, когда тест не удался, и храните ответ вместе с результатом теста.

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