CGNAT e IP pubblico: raggiungere i servizi di casa con DDNS, Tailscale o Cloudflare Tunnel

Avete aperto la porta sul router, il servizio funziona in casa, ma da fuori niente. Molto spesso la causa non è la regola ma la linea: l’operatore non vi dà un indirizzo IPv4 pubblico tutto vostro, bensì uno condiviso con altri clienti dietro un grande NAT di rete, il CGNAT. Questa guida vi aiuta a capire in due minuti se è il vostro caso e a scegliere tra le tre uscite possibili: chiedere un IP pubblico, usare IPv6, oppure far uscire voi la connessione verso un servizio esterno con Tailscale o Cloudflare Tunnel.

La guida segue la documentazione ufficiale di IETF, AVM (FRITZ!), DuckDNS, Tailscale, Cloudflare e Starlink, verificata il 4 novembre 2026.

Passo 1: siete dietro CGNAT?

L’RFC 6598 riserva il blocco 100.64.0.0/10 (da 100.64.0.0 a 100.127.255.255) come «Shared Address Space» per il NAT degli operatori. Se il vostro router ha un indirizzo WAN in quell’intervallo, siete dietro CGNAT. AVM indica come non raggiungibili via IPv4 anche gli indirizzi privati 10.x, 172.16–31.x e 192.168.x (c’è un altro NAT a monte) e l’intervallo 192.0.0.0–192.0.0.7, che indica un tunnel DS-Lite.

1. leggete l’indirizzo WAN nel pannello del router (sul FRITZ!Box: Internet > Online Monitor, scheda Connection Details, riga «Internet, IPv4»);
2. aprite da un PC di casa un sito che mostra il vostro IP pubblico;
3. confrontate: se i due indirizzi sono diversi, tra voi e Internet c’è almeno un altro NAT.

Una conferma da riga di comando su Windows:

tracert /d 1.1.1.1

L’opzione /d evita la risoluzione dei nomi e velocizza il risultato. Se subito dopo il vostro router (primo salto, ad esempio 192.168.1.1) compare un indirizzo 100.64–100.127, il traffico passa per il CGNAT dell’operatore. La stessa traccia si ottiene in PowerShell con Test-NetConnection -ComputerName 1.1.1.1 -TraceRoute.

Esiste anche un caso intermedio: alcuni operatori condividono un IPv4 tra più clienti assegnando a ciascuno un intervallo di porte. AVM lo documenta così: il FRITZ!Box mostra l’elenco delle porte che il provider rende disponibili, e solo quelle sono raggiungibili via IPv4.

Passo 2: le tre uscite, a confronto

Uscita 1: chiedere l’IP pubblico

È la soluzione più pulita, e in molti casi basta chiederla all’assistenza dell’operatore. Le condizioni cambiano spesso e variano tra fibra, FTTC e FWA, quindi non le riportiamo per operatore: verificate sul contratto o con l’assistenza se l’IP pubblico è incluso, a pagamento o non disponibile. AVM ricorda che gli operatori offrono spesso contratti business con accesso su tutte le porte, in IPv4 e IPv6. Un caso noto è Starlink, che per impostazione predefinita usa il CGNAT: le opzioni di IPv4 pubblico e IPv6 dipendono dal piano, e conviene verificarle sulla pagina di supporto di Starlink prima di contare sull’apertura delle porte.

Ottenuto l’IP pubblico, se è dinamico vi serve un DDNS. Sul FRITZ!Box c’è MyFRITZ!; in alternativa DuckDNS, che si aggiorna con una semplice richiesta HTTPS. Lo script ufficiale per Linux, da salvare in ~/duckdns/duck.sh (create prima la cartella con mkdir ~/duckdns):

echo url="https://www.duckdns.org/update?domains=TUO_SOTTODOMINIO&token=TUO_TOKEN&ip=" | curl -k -o ~/duckdns/duck.log -K -

Rendetelo eseguibile e programmatelo ogni 5 minuti con crontab -e:

chmod 700 ~/duckdns/duck.sh
*/5 * * * * ~/duckdns/duck.sh >/dev/null 2>&1

La seconda riga va nel crontab, non nel terminale. Con ip= vuoto DuckDNS rileva da solo l’indirizzo.

Uscita 2: IPv6

Se la linea ha IPv6, i dispositivi di casa hanno indirizzi globali e AVM conferma che un FRITZ!Box con un IPv6 nei dettagli di connessione è raggiungibile da Internet via IPv6, anche con DS-Lite. Il limite è dall’altra parte: dovete collegarvi da una rete che a sua volta ha IPv6. AVM suggerisce di controllarlo aprendo test-ipv6.com dal luogo da cui vi collegherete, e ricorda che le reti mobili di solito bloccano le connessioni in ingresso. Ricordate anche che con IPv6 l’«apertura» si fa nel firewall del router, dispositivo per dispositivo.

Uscita 3: Tailscale, la rete privata che non apre porte

Tailscale crea una rete privata tra i vostri dispositivi basata su WireGuard; le connessioni partono dai dispositivi verso l’esterno, quindi funziona anche dietro CGNAT. Su un server Linux di casa:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip

tailscale up collega il dispositivo e, se serve, vi chiede di autenticarvi con il vostro account; tailscale ip stampa l’indirizzo assegnato al server. Installate poi l’app sullo smartphone con lo stesso account.

Per raggiungere tutta la rete di casa, non solo il server, configuratelo come «subnet router». Abilitate l’inoltro:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

e annunciate la rete di casa (sostituite con la vostra):

sudo tailscale set --advertise-routes=192.168.1.0/24

Poi approvate la rotta nella console di amministrazione di Tailscale: pagina Machines, dispositivo con l’etichetta «subnet», sezione Subnets. I client Android, iOS, macOS e Windows ricevono la rotta in automatico; gli altri client Linux devono accettarla con sudo tailscale set --accept-routes.

Uscita 4: Cloudflare Tunnel, per pubblicare un sito

Se volete che un servizio web di casa sia raggiungibile da chiunque con un nome di dominio, Cloudflare Tunnel è la soluzione: il demone cloudflared apre solo connessioni in uscita verso Cloudflare, e la documentazione specifica che non serve alcuna porta in ingresso. Requisiti: un dominio aggiunto a Cloudflare e la possibilità per il server di raggiungere Cloudflare sulla porta 7844, come raccomanda la guida. Dalla dashboard:

1. Networking > Tunnels, Create a tunnel, nome, Create Tunnel;
2. scegliete il sistema operativo e copiate sul server il comando di installazione mostrato dalla dashboard (contiene un token personale: non condividetelo);
3. quando il connettore risulta collegato, Continue;
4. nella scheda Routes: Add route, Published application, sottodominio e dominio, e in Service URL l’indirizzo locale del servizio, ad esempio http://localhost:8080; confermate con Add route.

Non pubblicate così il pannello del router, il NAS o servizi senza login robusto: tutto ciò che è dietro il tunnel è raggiungibile da Internet. Per uso privato Tailscale o una VPN restano preferibili; per un sito pubblico conviene metterci davanti un reverse proxy, come spieghiamo in https://hardwarfare.it/ai-software/linux/reverse-proxy-nginx-proxy-manager-caddy/.

Privacy: cosa cambia con ciascuna soluzione

Con IP pubblico, IPv6 o VPN di casa, il traffico va direttamente da voi a casa vostra. Con Tailscale il traffico tra dispositivi è cifrato con WireGuard, ma il coordinamento (chi è collegato, con quale chiave) passa dal servizio. Con Cloudflare Tunnel il traffico web arriva a Cloudflare, che lo inoltra al vostro server: è il prezzo della comodità e della protezione dagli attacchi, e va considerato prima di pubblicarci servizi con dati personali.

Se qualcosa va storto

• Avete ottenuto l’IP pubblico ma la porta resta chiusa. Controllate che il router si sia ricollegato (un riavvio aiuta) e che l’IP WAN ora coincida con quello visto dall’esterno; poi tornate alla guida sull’apertura delle porte.
• tailscale up funziona, ma la rete di casa non si raggiunge. La rotta non è stata approvata nella console oppure manca l’inoltro IP: rileggete i file in /etc/sysctl.d/. Su un client Linux, manca --accept-routes.
• Il tunnel Cloudflare non diventa «Healthy». Il server non raggiunge Cloudflare in uscita sulla porta 7844 o il comando di installazione non è stato eseguito con privilegi sufficienti.
• Sul FRITZ!Box non compare alcun IPv4. È il caso DS-Lite: via IPv4 non siete raggiungibili; restano IPv6, Tailscale e Cloudflare Tunnel.

Come tornare indietro

Per Tailscale: sudo tailscale down scollega il dispositivo, e dalla console potete rimuoverlo del tutto; cancellate /etc/sysctl.d/99-tailscale.conf se non vi serve più l’inoltro. Per Cloudflare Tunnel eliminate la route e il tunnel dalla dashboard e disinstallate cloudflared dal server. Per DuckDNS basta togliere la riga dal crontab.

La nostra lettura

Il CGNAT non è un difetto della vostra rete ma una scelta dell’operatore, e la prima mossa è sempre chiedere un IP pubblico. Quando non è possibile, per l’accesso privato Tailscale è la soluzione con meno attrito che conosciamo; Cloudflare Tunnel ha senso solo per ciò che volete davvero pubblico. Se invece avete un IP raggiungibile, una VPN vostra resta la scelta più indipendente: https://hardwarfare.it/guide/tutorial/vpn-casa-wireguard-fritzbox-server-linux/.

Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo