Perché un server VPN dietro CGNAT non accetta mai connessioni

Il router riporta un indirizzo WAN che inizia con 100.72, il nome DNS dinamico risolve su un altro indirizzo pubblico e il server VPN su quel router non completa mai una stretta di mano dall’esterno. L’inoltro delle porte è configurato, il servizio è in esecuzione e un test dalla LAN funziona ancora. Nulla nel registro del router sembra un errore. Quella combinazione è NAT di livello operatore, e nessuna regola del firewall può aprire una porta su un indirizzo che l’ISP possiede.

Confermare l’indirizzo condiviso richiede due minuti ed evita una settimana di modifiche alla configurazione.

I segnali che indicano il NAT dell’operatore

Confrontate l’indirizzo WAN nella pagina di stato del router con l’indirizzo riportato da una ricerca esterna. Un indirizzo WAN dentro 100.64.0.0/10 è il segno abituale, e gli intervalli privati 10/8, 172.16/12 e 192.168/16 significano la stessa cosa. Se traceroute mostra lo stesso salto pubblico ripetuto, o un salto iniziale risponde con un indirizzo privato, c’è un altro traduttore tra il router e internet. Alcuni ISP elencano l’indirizzo assegnato solo nel portale clienti, quindi esportate quel valore insieme al traceroute.

Cambiare protocollo o porta non aiuta, perché il problema è la raggiungibilità in ingresso e non una porta chiusa.

Perché inoltro e DNS dinamico non possono risolverlo

Una regola di inoltro delle porte mappa una porta sull’interfaccia WAN del router, ma il traffico in ingresso non raggiunge mai quell’interfaccia: l’ISP lo traduce prima e inoltra solo ciò che la sua tabella consente. Pubblicare l’indirizzo condiviso nel DNS dinamico indirizza i client verso un gateway dell’ISP usato da molti abbonati, ed è per questo che il nome risolve e la stretta di mano fallisce comunque. I test hairpin riescono perché il router risponde alla propria regola dall’interno, e UPnP ha esattamente lo stesso punto cieco.

Anche riconfigurare il client non aiuterà, perché il guasto avviene prima che venga letta qualsiasi impostazione del client.

Inoltrare tramite un VPS con rotte esplicite

Mettete un indirizzo pubblico davanti noleggiando il VPS più piccolo in grado di trasportare il traffico, poi fate in modo che il router di casa si colleghi in uscita verso di esso. L’UDP in uscita dalla rete domestica attraversa il NAT dell’operatore, quindi il tunnel si stabilisce dall’interno e il VPS diventa l’endpoint raggiungibile. Il lato domestico diventa un client con un indirizzo di tunnel fisso, non un server.

Sul VPS aggiungete una voce di directory specifica del client perché il server sappia quale peer possiede la sottorete domestica, e aggiungete una rotta del kernel corrispondente.

# /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 riga iroute dice a OpenVPN quale client riceve il traffico per la sottorete domestica; la riga route mette quella sottorete nella tabella del kernel del VPS perché i pacchetti entrino nel tunnel. Per un servizio pubblicato, aggiungete una regola NAT di destinazione che inoltri la porta pubblica a 10.8.0.10 e abilitate net.ipv4.ip_forward.

Provate il percorso dall’esterno

Verificate ogni salto sul lato pubblico, perché un tunnel riuscito non dimostra che il servizio sia raggiungibile. Lo stato di ascolto e la cattura dei pacchetti sul VPS distinguono «non è arrivato nulla» da «è arrivato ed è stato scartato».

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

Se la cattura mostra pacchetti dal telefono ma nessuna risposta, la configurazione del server o il firewall sono la prossima tappa. Se la cattura non mostra nulla, il client sta ancora risolvendo o inviando all’indirizzo sbagliato.

Alternative da valutare per prime

Un indirizzo IPv4 dedicato fornito dall’ISP è la soluzione più breve e di solito costa un piccolo canone mensile. L’IPv6 nativo elimina la traduzione a entrambe le estremità quando VPN, rete del client e record DNS lo supportano tutti. Un overlay mesh con un router di sottorete dentro la rete domestica ottiene lo stesso inoltro senza VPS, al prezzo di dipendere da un servizio di coordinamento.

Scegliete l’inoltro quando il requisito è un accesso in ingresso stabile e ogni regola deve restare sotto il vostro controllo. Scegliete l’indirizzo dell’ISP quando il budget lo consente e l’obiettivo è semplicemente smettere di pensarci.