Чому VPN-сервер за CGNAT ніколи не приймає підключення

Адреса 100.64, динамічне DNS-ім'я, що розв'язується в іншому місці, і відсутність вхідного рукостискання — одна проблема: NAT оператора. Підтвердьте її, потім передавайте вихідний трафік через ретранслятор.

Маршрутизатор повідомляє 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, але ціною залежності від служби координації.

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

Схожі статті