Чаму 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, але з залежнасцю ад службы каардынацыі.
Выбірайце рэлей, калі патрабуецца стабільны ўваходны доступ і кожнае правіла павінна заставацца пад вашым кантролем. Выбірайце адрас правайдэра, калі бюджэт дазваляе і мэта проста перастаць пра гэта думаць.