Waarom een VPN-server achter CGNAT nooit verbindingen accepteert

De router meldt een WAN-adres dat met 100.72 begint, de dynamische DNS-naam lost op naar een ander openbaar adres, en de VPN-server op die router voltooit nooit een handshake van buitenaf. Port forwarding is ingesteld, de dienst draait, en een test vanaf de LAN werkt nog steeds. Niets in het routerlog ziet eruit als een fout. Die combinatie is carrier-grade NAT, en geen enkele firewallregel kan een poort openen op een adres dat de ISP bezit.

Het bevestigen van het gedeelde adres kost twee minuten en voorkomt een week aan configuratiewijzigingen.

De signalen die op carrier-NAT wijzen

Vergelijk het WAN-adres op de statuspagina van de router met het adres dat een externe opzoeking meldt. Een WAN-adres binnen 100.64.0.0/10 is het gebruikelijke signaal, en de privébereiken 10/8, 172.16/12 en 192.168/16 betekenen hetzelfde. Als traceroute dezelfde openbare hop herhaald toont, of een vroege hop antwoordt met een privéadres, zit er nog een vertaler tussen de router en het internet. Sommige ISP's vermelden het toegewezen adres alleen in het klantenportaal, dus exporteer die waarde samen met de traceroute.

Protocollen of poorten wijzigen helpt niet, want het probleem is inkomende bereikbaarheid en niet een gesloten poort.

Waarom forwarding en dynamische DNS het niet kunnen oplossen

Een port-forwardingregel koppelt een poort op de WAN-interface van de router, maar inkomend verkeer bereikt die interface nooit: de ISP vertaalt het eerst en stuurt alleen door wat zijn eigen tabel toestaat. Het gedeelde adres in dynamische DNS publiceren wijst clients naar een ISP-gateway die veel abonnees gebruiken, daarom lost de naam op en mislukt de handshake alsnog. Hairpin-tests slagen omdat de router zijn eigen regel van binnenuit beantwoordt, en UPnP heeft precies dezelfde blinde vlek.

De client opnieuw configureren helpt ook niet, omdat de fout optreedt voordat een clientinstelling wordt gelezen.

Doorgeven via een VPS met expliciete routes

Zet een openbaar adres vooraan door de kleinste VPS te huren die het verkeer kan dragen, en laat de thuisrouter dan daarnaartoe uitbellen. Uitgaande UDP vanaf het thuisnetwerk passeert carrier-NAT, dus de tunnel komt van binnenuit tot stand en de VPS wordt het bereikbare eindpunt. De thuiszijde wordt een client met een vast tunneladres, geen server.

Voeg op de VPS een cliëntspecifieke mapvermelding toe zodat de server weet welke peer het thuissubnet bezit, en voeg een bijpassende kernelroute toe.

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

De regel iroute vertelt OpenVPN welke client verkeer voor het thuissubnet ontvangt; de regel route zet dat subnet in de kerneltabel van de VPS zodat pakketten daadwerkelijk de tunnel in gaan. Voeg voor een gepubliceerde dienst een destination-NAT-regel toe die de openbare poort naar 10.8.0.10 doorstuurt en schakel net.ipv4.ip_forward in.

Test het pad van buitenaf

Verifieer elke hop aan de openbare kant, want een geslaagde tunnel bewijst niet dat de dienst bereikbaar is. Luisterstatus en pakketopname op de VPS scheiden 'niets aangekomen' van 'aangekomen en weggegooid'.

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

Als de opname pakketten van de telefoon toont maar geen antwoord, zijn de serverconfiguratie of de firewall de volgende stop. Als de opname niets toont, lost de client nog op of stuurt naar het verkeerde adres.

Alternatieven die eerst een prijsvergelijking waard zijn

Een toegewezen IPv4-adres van de ISP is de kortste oplossing en kost meestal een kleine maandelijkse vergoeding. Native IPv6 haalt de vertaling aan beide kanten weg wanneer de VPN, het klantnetwerk en de DNS-records het allemaal ondersteunen. Een mesh-overlay met een subnetrouter in het thuisnetwerk bereikt dezelfde doorgeving zonder VPS, tegen de prijs van afhankelijkheid van een coördinatiedienst.

Kies de doorgeving wanneer de eis stabiele inkomende toegang is en elke regel onder jouw controle moet blijven. Kies het ISP-adres wanneer het budget het toelaat en het doel simpelweg is om er niet meer aan te denken.