Почему VPN-сервер за CGNAT никогда не принимает подключения

Маршрутизатор сообщает WAN-адрес, начинающийся с 100.72, динамическое DNS-имя разрешается в другой публичный адрес, а VPN-сервер на этом маршрутизаторе никогда не завершает рукопожатие снаружи. Проброс портов настроен, служба работает, и тест из локальной сети по-прежнему проходит. В журнале маршрутизатора ничего не выглядит ошибкой. Это сочетание — NAT операторского уровня, и ни одно правило брандмауэра не может открыть порт на адресе, которым владеет провайдер.

Подтверждение общего адреса занимает две минуты и предотвращает неделю изменений конфигурации.

Признаки, указывающие на NAT оператора

Сравните WAN-адрес на странице состояния маршрутизатора с адресом, который сообщает внешний запрос. WAN-адрес в пределах 100.64.0.0/10 — обычный признак, а частные диапазоны 10/8, 172.16/12 и 192.168/16 означают то же самое. Если traceroute показывает один и тот же публичный переход повторно или ранний переход отвечает частным адресом, между маршрутизатором и интернетом стоит ещё один транслятор. Некоторые провайдеры указывают выданный адрес только в клиентском портале, поэтому экспортируйте это значение вместе с traceroute.

Смена протоколов или портов не помогает, потому что проблема во входящей доступности, а не в закрытом порте.

Почему проброс и динамический DNS не могут это исправить

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

Перенастройка клиента тоже не поможет, так как сбой происходит раньше, чем читается любой параметр клиента.

Ретрансляция через VPS с явными маршрутами

Поставьте впереди публичный адрес: арендуйте самый маленький VPS, способный нести трафик, затем заставьте домашний маршрутизатор подключиться к нему исходящим соединением. Исходящий UDP из домашней сети проходит через NAT оператора, поэтому туннель устанавливается изнутри, и VPS становится доступной конечной точкой. Домашняя сторона становится клиентом с фиксированным адресом туннеля, а не сервером.

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

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

Строка iroute сообщает OpenVPN, какой клиент получает трафик для домашней подсети; строка route помещает эту подсеть в таблицу ядра VPS, чтобы пакеты вообще попадали в туннель. Для опубликованной службы добавьте правило NAT назначения, которое перенаправляет публичный порт на 10.8.0.10, и включите net.ipv4.ip_forward.

Проверьте путь снаружи

Проверьте каждый переход на публичной стороне, потому что успешный туннель не доказывает доступность службы. Состояние прослушивания и перехват пакетов на VPS отличают «ничего не пришло» от «пришло и было отброшено».

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

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

Альтернативы, которые стоит оценить в первую очередь

Выделенный адрес IPv4 от провайдера — самое короткое решение, обычно за небольшую ежемесячную плату. Нативный IPv6 устраняет трансляцию на обоих концах, когда его поддерживают VPN, клиентская сеть и записи DNS. Mesh-оверлей с маршрутизатором подсети внутри домашней сети даёт ту же ретрансляцию без VPS, но ценой зависимости от координационной службы.

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