Proč VPN server za CGNAT nikdy nepřijme připojení

Router hlásí WAN adresu začínající na 100.72, dynamické DNS jméno se překládá na jinou veřejnou adresu a VPN server na tomto routeru nikdy nedokončí handshake zvenčí. Přesměrování portů je nastavené, služba běží a test z LAN stále funguje. V logu routeru nic nevypadá jako chyba. Tato kombinace je NAT na úrovni operátora a žádné pravidlo firewallu nemůže otevřít port na adrese, kterou drží ISP.

Potvrzení sdílené adresy zabere dvě minuty a zabrání týdnu změn konfigurace.

Známky, které ukazují na NAT operátora

Porovnejte WAN adresu na stavové stránce routeru s adresou, kterou hlásí externí vyhledání. WAN adresa v rozsahu 100.64.0.0/10 je obvyklá známka a privátní rozsahy 10/8, 172.16/12 a 192.168/16 znamenají totéž. Pokud traceroute ukazuje stejný veřejný skok opakovaně nebo raný skok odpovídá privátní adresou, mezi routerem a internetem stojí další překladač. Někteří ISP uvádějí přidělenou adresu jen v zákaznickém portálu, proto tuto hodnotu vyexportujte spolu s traceroute.

Změna protokolů nebo portů nepomůže, protože problémem je příchozí dosažitelnost, ne zavřený port.

Proč to přesměrování a dynamický DNS nedokážou opravit

Pravidlo přesměrování portu mapuje port na WAN rozhraní routeru, ale příchozí provoz se na toto rozhraní nikdy nedostane: ISP jej nejprve přeloží a přepošle jen to, co jeho vlastní tabulka dovolí. Zveřejnění sdílené adresy v dynamickém DNS nasměruje klienty na bránu ISP, kterou používá mnoho odběratelů, a proto se jméno přeloží, ale handshake stále selhává. Testy hairpin procházejí, protože router odpovídá na své vlastní pravidlo zevnitř, a UPnP má přesně stejné slepé místo.

Ani překonfigurování klienta nepomůže, protože selhání nastane dřív, než se přečte jakékoli nastavení klienta.

Přeposílání přes VPS s explicitními trasami

Postavte dopředu veřejnou adresu: najměte nejmenší VPS, který provoz unese, a potom přimějte domácí router, aby se k němu připojil odchozím směrem. Odchozí UDP z domácí sítě projde NAT operátora, takže tunel se naváže zevnitř a VPS se stane dosažitelným koncovým bodem. Domácí strana se stane klientem s pevnou adresou tunelu, ne serverem.

Na VPS přidejte záznam adresáře pro konkrétního klienta, aby server věděl, který peer vlastní domácí podsíť, a přidejte odpovídající trasu jádra.

# /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"

Řádek iroute říká OpenVPN, který klient dostává provoz pro domácí podsíť; řádek route vkládá tuto podsíť do tabulky jádra VPS, aby pakety vůbec do tunelu vstoupily. Pro publikovanou službu přidejte pravidlo cílového NAT, které přesměruje veřejný port na 10.8.0.10, a povolte net.ipv4.ip_forward.

Otestujte cestu zvenčí

Ověřte každý skok na veřejné straně, protože úspěšný tunel nedokazuje, že je služba dosažitelná. Stav naslouchání a zachytávání paketů na VPS oddělují 'nic nepřišlo' od 'přišlo a bylo zahozeno'.

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

Pokud zachytávání ukazuje pakety z telefonu, ale žádnou odpověď, další zastávkou je konfigurace serveru nebo firewall. Pokud zachytávání neukazuje nic, klient stále překládá nebo posílá na špatnou adresu.

Alternativy, které stojí za to vyhodnotit jako první

Vyhrazená adresa IPv4 od ISP je nejkratší řešení a obvykle malý měsíční poplatek. Nativní IPv6 odstraní překlad na obou koncích, když jej podporují VPN, klientská síť i DNS záznamy. Mesh overlay s routerem podsítě uvnitř domácí sítě dosáhne stejného přeposílání bez VPS, ovšem za cenu závislosti na koordinační službě.

Zvolte přeposílání, když je požadavkem stabilní příchozí přístup a každé pravidlo má zůstat pod vaší kontrolou. Zvolte adresu od ISP, když to rozpočet dovolí a cílem je prostě přestat o tom přemýšlet.