Per què un servidor VPN darrere de CGNAT no accepta mai connexions

El router informa d'una adreça WAN que comença per 100.72, el nom DNS dinàmic es resol a una altra adreça pública i el servidor VPN d'aquest router mai completa una encaixada de mans des de fora. El reenviament de ports està configurat, el servei s'executa i una prova des de la LAN encara funciona. Al registre del router no hi ha res que sembli un error. Aquesta combinació és NAT de nivell d'operadora, i cap regla de tallafoc pot obrir un port en una adreça que l'ISP té.

Confirmar l'adreça compartida triga dos minuts i evita una setmana de canvis de configuració.

Els senyals que apunten a NAT de l'operadora

Compareu l'adreça WAN de la pàgina d'estat del router amb l'adreça que informa una consulta externa. Una adreça WAN dins de 100.64.0.0/10 és el senyal habitual, i els rangs privats 10/8, 172.16/12 i 192.168/16 volen dir el mateix. Si traceroute mostra el mateix salt públic repetit, o un salt primerenc respon amb una adreça privada, hi ha un altre traductor entre el router i internet. Alguns ISP només llisten l'adreça assignada al portal de clients, així que exporteu aquest valor juntament amb el traceroute.

Canviar de protocol o de port no ajuda, perquè el problema és l'abastabilitat entrant i no un port tancat.

Per què el reenviament i el DNS dinàmic no ho poden arreglar

Una regla de reenviament de port mapatja un port de la interfície WAN del router, però el trànsit entrant mai arriba a aquesta interfície: l'ISP el tradueix primer i només reenvia el que la seva pròpia taula permet. Publicar l'adreça compartida al DNS dinàmic adreça els clients a una porta d'enllaç de l'ISP que fan servir molts abonats, i per això el nom es resol i l'encaixada de mans continua fallant. Les proves de hairpin funcionen perquè el router respon la seva pròpia regla des de dins, i UPnP té exactament el mateix punt cec.

Reconfigurar el client tampoc ajudarà, ja que la fallada es produeix abans que es llegeixi cap paràmetre del client.

Retransmetre a través d'un VPS amb rutes explícites

Poseu una adreça pública al davant llogant el VPS més petit que pugui portar el trànsit, i després feu que el router de casa es connecti cap a ell. L'UDP de sortida des de la xarxa domèstica travessa el NAT de l'operadora, així que el túnel s'estableix des de dins i el VPS es converteix en el punt final abastable. El costat domèstic passa a ser un client amb una adreça de túnel fixa, no un servidor.

Al VPS, afegiu una entrada de directori específica del client perquè el servidor sàpiga quin pare posseeix la subxarxa domèstica, i afegiu una ruta de nucli corresponent.

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

La línia iroute diu a OpenVPN quin client rep el trànsit de la subxarxa domèstica; la línia route posa aquesta subxarxa a la taula del nucli del VPS perquè els paquets entrin al túnel. Per a un servei publicat, afegiu una regla de NAT de destinació que reenviï el port públic a 10.8.0.10 i activeu net.ipv4.ip_forward.

Proveu el camí des de fora

Verifiqueu cada salt al costat públic, perquè un túnel correcte no demostra que el servei sigui abastable. L'estat d'escolta i la captura de paquets al VPS separen 'no ha arribat res' de 'ha arribat i s'ha descartat'.

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

Si la captura mostra paquets del telèfon però cap resposta, la configuració del servidor o el tallafoc són la següent parada. Si la captura no mostra res, el client encara resol o envia a l'adreça equivocada.

Alternatives que val la pena valorar primer

Una adreça IPv4 dedicada de l'ISP és la solució més curta i normalment és una petita quota mensual. L'IPv6 natiu elimina la traducció als dos extrems quan la VPN, la xarxa del client i els registres DNS la porten tots. Una superposició de malla amb un encaminador de subxarxa dins de la xarxa domèstica aconsegueix la mateixa retransmissió sense VPS, a canvi de dependre d'un servei de coordinació.

Trieu la retransmissió quan el requisit sigui accés entrant estable i cada regla hagi de quedar sota el vostre control. Trieu l'adreça de l'ISP quan el pressupost ho permeti i l'objectiu sigui simplement deixar de pensar-hi.