In questo articolo Indice dei contenuti 3 sezioni
Chi si ritrova la connessione di casa dietro CGNAT conosce bene la frustrazione: si apre il pannello del router, si cerca la sezione del port forwarding, si configura tutto a regola d’arte e poi dall’esterno non risponde nessuno. La soluzione più pulita per aggirare l’ostacolo passa da un VPS con indirizzo IPv4 pubblico e da un tunnel WireGuard che collega quel server al computer di casa. In pratica si ribalta la direzione della connessione, e il gioco è fatto.
Fino a qualche anno fa pubblicare un server domestico era una procedura quasi noiosa. Indirizzo locale fisso alla macchina, porte aperte sul router, un servizio DDNS per tenere aggiornata l’associazione tra IP pubblico e nome di dominio. Poi gli indirizzi IPv4 hanno iniziato a scarseggiare sul serio e molti operatori hanno adottato il Carrier Grade NAT, condividendo un solo indirizzo pubblico tra più clienti.
Perché con CGNAT le porte aperte non servono a niente
Con una connessione IPv4 pubblica tradizionale, il router ha sulla WAN un indirizzo che chiunque può raggiungere. Una regola NAT può dire che i pacchetti diretti alla porta TCP 443 vadano consegnati, poniamo, a 192.168.1.20. Semplice, perché quei pacchetti arrivano davvero al router.
Con CGNAT invece si aggiunge un secondo livello di traduzione dentro la rete dell’operatore. Il router dell’abbonato riceve un indirizzo non instradabile su Internet, spesso preso dallo spazio 100.64.0.0/10 riservato dalla RFC 6598 proprio a questo scopo. L’IPv4 pubblico appartiene al dispositivo CGN del provider e serve contemporaneamente decine di clienti. Ci sono quindi due NAT in fila, e aprire una porta sul primo non cambia nulla per il secondo. La RFC 6888 prevede meccanismi come PCP, il Port Control Protocol, con cui il cliente potrebbe controllare alcune mappature, ma dare per scontato che l’operatore lo offra è ottimismo mal riposto. Per chi gestisce un laboratorio personale, un’istanza Nextcloud, un server Matrix o un semplice accesso SSH, serve un’altra strada.
Il trucco sta nel far partire la connessione da casa
CGNAT blocca le connessioni in ingresso, non quelle in uscita. Il server domestico può contattare un VPS pubblico senza alcun problema, esattamente come raggiunge qualsiasi altro sito. WireGuard costruisce su questo un’interfaccia virtuale, tipicamente wg0, dentro cui viaggiano pacchetti IP cifrati incapsulati in datagrammi UDP. Ogni estremo ha la sua coppia di chiavi e il parametro AllowedIPs stabilisce quali indirizzi possono transitare per il tunnel.
Nell’esempio classico il VPS prende 10.0.0.1/24 e ascolta sulla porta UDP 51820, la macchina di casa prende 10.0.0.2/24 e conosce l’indirizzo pubblico del VPS, che nella configurazione finisce nel campo Endpoint. Siccome WireGuard tende a stare zitto quando non c’è traffico, dietro NAT una pausa troppo lunga rischia di far scadere la mappatura UDP: il parametro PersistentKeepalive impostato a 25 secondi tiene viva l’associazione. Da notare una differenza importante rispetto a soluzioni come nginx Proxy Manager o Traefik: qui il VPS lavora a livello IP e non deve capire nulla di HTTP, TLS o SSH.
Configurazione pratica su entrambe le macchine
Servono due sistemi Linux, Ubuntu o Debian vanno benissimo. Installazione con sudo apt update && sudo apt install wireguard, poi generazione delle chiavi con umask 077 seguito da wg genkey. La chiave privata resta dov’è, quella pubblica si copia sulla macchina opposta. Attenzione a non scegliere per il tunnel una sottorete già usata dalla LAN di casa: se 10.0.0.0/24 è occupata, meglio spostarsi su 10.200.200.0/24.
Sul VPS va abilitato l’inoltro IPv4 nel kernel, con sysctl, rendendolo poi permanente tramite un file dentro /etc/sysctl.d. Sul server domestico la parte meno ovvia riguarda la tabella di routing 200 e la regola che dirotta lì soltanto i pacchetti originati da 10.0.0.2, così il normale traffico Internet della macchina continua a uscire dal router di casa.
Attivati i servizi con systemctl, il comando sudo wg show deve mostrare un handshake recente. Se manca, i sospettati sono tre: firewall del VPS sulla porta UDP 51820, indirizzo sbagliato in Endpoint, chiavi scambiate male. Un ping tra 10.0.0.1 e 10.0.0.2 conferma che il collegamento privato regge.
Resta l’ultimo passaggio, sul VPS: con iptables si lascia sul posto il traffico UDP della porta 51820 e quello TCP della 2222 usata per amministrare il VPS via SSH, mentre tutto il resto viene inoltrato in DNAT verso 10.0.0.2, con le corrispondenti regole di FORWARD tra l’interfaccia pubblica e wg0.
Fonte: TecnoAndroid
