Il 16 ottobre ho spento il Wi-Fi del telefono e ho provato ad aprire il mio server da fuori: indirizzo pubblico di casa, porta di Jellyfin. Safari è rimasto a caricare finché si è arreso: «il server ha smesso di rispondere».
In quel momento la domanda è sempre la stessa: è colpa mia o dell’operatore? Se la linea è dietro CGNAT, nessuna regola sul router ti farà mai entrare da fuori. Se non lo è, il problema è in casa e lo puoi risolvere tu.
Ho fatto il test sulla mia linea con i comandi che chiunque ha già sul PC, e la risposta è stata meno netta di quanto speravo: il CGNAT non sono riuscito a dimostrarlo, e per trovare la soluzione non serviva. Prima ancora dell’operatore, la mia connessione passa da due NAT che stanno in casa mia, e già quelli bastano a chiudere qualsiasi porta.
La linea è radio (FWA), di un operatore locale: un’antenna configurata dal provider, di cui non ho le credenziali, poi in casa un router Deco, poi il server. Da qui non ricavo regole sugli altri operatori: per quelli riporto più sotto cosa dichiarano nei loro documenti. E la WAN dell’antenna, il dato che chiuderebbe il test, non la posso leggere.
Cos’è il CGNAT, in quattro righe
In casa il router fa già un NAT: tutti i tuoi dispositivi escono su Internet con un solo indirizzo pubblico. Con il CGNAT (Carrier-Grade NAT) l’operatore fa la stessa cosa un livello più su: più clienti dietro lo stesso indirizzo pubblico, e al tuo router arriva un indirizzo che da Internet non si raggiunge.
La conseguenza pratica è una sola. Da dentro verso fuori funziona tutto, perché sono connessioni che apri tu. Da fuori verso dentro non entra niente, perché il NAT che conta non sta sul tuo router e la porta non la puoi aprire tu.
Per questo uso esiste un intervallo di indirizzi riservato: 100.64.0.0/10, cioè da 100.64.0.0 a 100.127.255.255, che l’RFC 6598 del 2012 chiama «Shared Address Space» e destina ai dispositivi CGN. Lo stesso intervallo lo usa anche Tailscale per i suoi indirizzi: il mio server, nella rete Tailscale, è 100.103.58.89, un 100.x che con il CGNAT non c’entra niente.
Il test in tre passi, con quello che ho trovato io
1. Qual è il tuo IP visto da fuori
Da un terminale:
curl.exe https://api.ipify.orgSu Windows scrivi proprio curl.exe: in PowerShell la parola curl da sola lancia un altro comando, Invoke-WebRequest. Su Linux e macOS il comando è curl, senza .exe.
Il mio: lo stesso indirizzo in quattro giorni diversi, dall’8 al 27 ottobre. Non lo scrivo, perché un IP che resta uguale per settimane porta dritto a una casa.
Cosa non prova: niente, da solo. Un IP condiviso può restare identico a lungo quanto uno tuo. Serve come termine di confronto per il passo dopo.
2. Qual è l’IP che il router ha sulla WAN
È il passo che decide. Apri la pagina o l’app del router e cerca la sezione della connessione Internet: lì c’è l’indirizzo che il router ha ricevuto da chi gli sta davanti.
- Uguale a quello del passo 1: niente CGNAT. La porta si può aprire, e se non funziona il problema è nella regola di inoltro o in un firewall.
- Fra
100.64e100.127: è lo spazio dell’RFC 6598, sei dietro il NAT dell’operatore. - Privato (
10.x,172.16.x–172.31.x,192.168.x): prima del tuo router c’è un altro NAT. Può essere quello dell’operatore, oppure un suo modem messo davanti al tuo router. Va capito quale.
Il mio Deco, nell’app, alla voce Connessione Internet:
Tipo IP dinamico, indirizzo 192.168.22.91, gateway 192.168.22.1. È un indirizzo privato, e il gateway è l’antenna: il primo NAT lo fa l’antenna, il secondo il Deco. Doppio NAT, certo.
Cosa non prova: il doppio NAT dimostra due NAT in casa, non che l’operatore ne faccia un terzo. Per saperlo dovrei leggere la WAN dell’antenna: qui il mio test si ferma.
3. Quanti salti privati prima del primo indirizzo pubblico
Quando la WAN non si legge, resta da guardare la strada che fanno i pacchetti. Su Windows tracert -d 1.1.1.1, su Linux tracepath -n 1.1.1.1. Dal mio server, il 16 ottobre:
1?: [LOCALHOST] pmtu 1500
1: 192.168.68.1 0.644ms
1: 192.168.68.1 0.552ms
2: 192.168.22.1 1.362ms
3: 192.168.22.1 1.266ms pmtu 1492
3: 10.38.1.1 190.797ms
4: 172.23.0.157 34.753ms
5: 172.23.0.81 20.372ms
6: 172.23.0.77 169.027ms
7: 172.23.0.77 51.807ms pmtu 1472
7: 172.16.0.21 105.541ms asymm 10
8: 172.16.0.77 29.389ms asymm 11
9: [primo indirizzo pubblico, tolto]
10: [tolto]Il primo salto è il Deco, il secondo l’antenna. Dopo l’antenna ci sono sei salti su indirizzi privati (10.38.1.1, tre 172.23.0.x, due 172.16.0.x), e il primo indirizzo pubblico arriva al nono. Dal PC fisso, con tracert, la strada è la stessa. Ai tempi delle singole righe non badare: c’è un campione per salto, e cambia molto da un salto all’altro.
I due indirizzi pubblici li ho tolti: il nome dell’operatore di transito, con il resto dell’articolo, direbbe in che zona abito.
Cosa non prova: è il punto debole di tutto il test. Un operatore può usare indirizzi privati dentro la sua rete e dare comunque un IP pubblico al cliente. Sei salti privati sono un indizio forte, non una prova.
Il test, riassunto
| Cosa vedi | Cosa vuol dire | Cosa non vuol dire |
|---|---|---|
| WAN del router uguale all’IP visto da fuori | niente CGNAT, la porta si apre dal router | |
| WAN del router fra 100.64 e 100.127 | CGNAT dell’operatore | |
| WAN del router privata | c’è un NAT prima del tuo router | che sia per forza dell’operatore: può essere un suo modem |
| Salti privati dopo il router | l’operatore usa indirizzi privati nella sua rete | che il tuo IP sia condiviso |
| IP visto da fuori stabile per settimane | che sia solo tuo | |
| Porta che da fuori non risponde | che qualcosa la blocca | che sia il CGNAT (vedi sotto) |
Sulla mia linea: WAN privata, sei salti privati, IP stabile. Doppio NAT provato, CGNAT probabile, non dimostrato.
Il primo ostacolo non era il CGNAT
Torno al telefono che non apriva Jellyfin. Wi-Fi spento, rete mobile, 16 ottobre:
| Ora | Tailscale | Indirizzo aperto | Esito |
|---|---|---|---|
| 18:39-18:40 | spento | IP pubblico di casa, porta 8097 | nessuna risposta, poi «Safari non può aprire la pagina perché il server ha smesso di rispondere» |
| 18:42 | acceso | IP pubblico di casa, porta 8097 | non carica nemmeno così |
| 18:42 | acceso | 100.103.58.89:8097, l’indirizzo Tailscale del server | «Healthy» |
La prima riga sembra la prova del CGNAT, e non lo è: sul Deco non c’è nessuna regola che inoltri la 8097 al server, quindi la porta era chiusa per scelta mia. L’unica regola di inoltro è per Syncthing sulla 22000, e si ferma al Deco: da Internet dovrebbe attraversare prima l’antenna, un NAT che non controllo. La seconda riga è normale: Tailscale ti dà un altro indirizzo, non cambia come si raggiunge quello pubblico.
Prima di dare la colpa all’operatore, quindi, conta i NAT di casa tua. Con il modem dell’operatore e dietro un router tuo hai un doppio NAT come me, e una porta inoltrata solo sul router non arriva. Di solito si sistema da casa, inoltrando la porta anche sul modem o mettendolo in modalità bridge; io non l’ho provato, perché l’antenna non è accessibile.
Per me il risultato è lo stesso del CGNAT: da fuori non si entra, e il terzo NAT, dimostrato o no, per la soluzione non cambia niente.
La via d’uscita più semplice: Tailscale, misurato da rete mobile
La terza riga della tabella è la soluzione che uso. Tailscale gira sul server da quando l’ho messo in piedi su un vecchio PC, e l’indirizzo 100.103.58.89 risponde «Healthy» da rete mobile, con due NAT certi di mezzo e nessuna porta aperta. Il «Non sicuro» di Safari è solo perché la pagina è in HTTP: il traffico viaggia comunque dentro il tunnel cifrato.
Funziona perché nessuno deve entrare: tutti e due i dispositivi aprono connessioni in uscita, che i NAT lasciano passare. Poi Tailscale prova a metterli in contatto diretto attraverso i NAT. Se non ci riesce, fa passare il traffico da un suo relay (DERP), che secondo la documentazione inoltra pacchetti già cifrati senza poterli leggere.
Il dettaglio che di solito non si scrive è proprio questo: dal telefono, la connessione diretta non si è mai aperta. L’ho misurato con tailscale ping dal server verso l’iPhone, la stessa SIM iliad in due sere diverse, 20 ping per sera:
| Rete del telefono | Via relay | min | mediana | max | |
|---|---|---|---|---|---|
| 16 ottobre, 18:41 | iliad 4G | 20 su 20, Londra | 150 ms | 195 ms | 391 ms |
| 27 ottobre, 01:15 | iliad 5G | 20 su 20, Francoforte | 73 ms | 110,5 ms | 158 ms |
L’output grezzo, dall’inizio e dalla fine di una serie del 27:
pong from iphone-15-pro-max (100.121.248.83) via DERP(fra) in 101ms
pong from iphone-15-pro-max (100.121.248.83) via DERP(fra) in 83ms
pong from iphone-15-pro-max (100.121.248.83) via DERP(fra) in 108ms
[...]
pong from iphone-15-pro-max (100.121.248.83) via DERP(fra) in 85ms
direct connection not establishedvia DERP(fra) vuol dire «passato dal relay di Francoforte», e l’ultima riga lo conferma. Con una connessione diretta, al posto di DERP(...) comparirebbe un indirizzo con la porta.
Quanto di quei tempi dipenda da casa mia lo stima un altro comando, tailscale netcheck, che dal server misura la distanza da ogni relay: 63,2 ms da Londra la sera del 16, 50,1 ms da Francoforte la sera del 26. Tolti dalle mediane, il tratto fra il relay e il telefono vale circa 130 ms la prima sera e circa 60 la seconda: in tutte e due è il pezzo più lungo. Il conto è approssimato, perché netcheck misura in un altro modo e non nello stesso momento dei ping (il 26, un’ora e 40 minuti prima). Per confronto, la linea di casa verso 1.1.1.1 fa 23,5 ms di media (minimo 15,0, massimo 39,3).
Due cose non le so spiegare:
- Perché una sera Londra e l’altra Francoforte. In tutte e due le sere il relay usato non era il più vicino al server, e il perché non l’ho controllato.
- Perché il diretto non si apre. Dal lato di casa,
tailscale netcheckclassifica il NAT fra quelli «facili» (MappingVariesByDestIP: false, cioè la porta vista da fuori non cambia a seconda della destinazione) in tutte e due le sere. Il sospetto cade sulla rete mobile, ma è un’ipotesi: dal telefono la stessa diagnosi non si fa, e con due NAT in fila in casa non escludo che il blocco sia qui.
La conclusione pratica: Tailscale funziona anche quando il diretto non si apre, ma con i tempi di un relay, e quei tempi cambiano da una sera all’altra. Nelle mie due la mediana è passata da 195 a 110,5 ms, ma sono cambiati insieme il relay, la rete del telefono (4G e 5G) e l’ora, e i tre effetti non li ho separati. Per sapere come va da te basta tailscale ping verso il telefono: se nelle risposte compare DERP, stai passando da un relay.
Da me Tailscale raggiunge solo il server, senza accesso al resto della rete di casa: è la scelta che avevo descritto nell’articolo sul vecchio PC.
L’altra strada: un VPS come ponte
Se un servizio deve essere raggiungibile da chi non ha Tailscale, per esempio un sito pubblico, serve un indirizzo pubblico, e dietro un CGNAT o un’antenna che non controlli non può essere quello di casa. Si affitta allora un VPS, che l’IP pubblico ce l’ha: il server di casa apre un tunnel in uscita verso il VPS, e il VPS gli gira le richieste che arrivano da Internet.
Non l’ho provato, quindi niente numeri e niente prezzi. Due costi si vedono già: una macchina in più da aggiornare e un servizio esposto a tutta Internet. Se ti basta raggiungere i tuoi servizi da fuori, Tailscale lo fa senza nessuno dei due; se il VPS ti serve, ho messo a confronto i piani nella pagina su quale VPS scegliere per l’homelab.
E se vuoi un IP pubblico? Cosa dichiarano gli operatori
Gli operatori pubblicano per le loro offerte una scheda di trasparenza tecnica, con gli indicatori previsti dalla delibera AGCOM 156/23/CONS, e una delle voci è «Tipologia di indirizzo IPv4 assegnato». È il posto dove guardare prima di firmare. Le ho lette il 27 ottobre 2026; dove la scheda non l’ho trovata cito la sintesi contrattuale (Vodafone) o il contratto (WindTre):
| Operatore e offerta | IPv4, come scritto nel documento | IPv6 |
|---|---|---|
| TIM, fibra (TIM WiFi Casa) | «Indirizzo IP pubblico, con assegnazione dinamica» | «No» |
| TIM, FWA (TIM WiFi Power FWA, TIM WiFi Casa FWA) | «Default Indirizzo IP privato, su richiesta è possibile ottenere IP pubblico con assegnazione dinamica» | «No» |
| Fastweb, fibra (Fastweb Casa Pro, Casa Ultra) | «Laddove richiesto dal consumatore, di conseguenza, verrà assegnato un IP pubblico statico. In tutti gli altri casi l’IP è privato con associazione dinamica» | «Al momento non è prevista l’assegnazione di Ipv6 per la connessione utente» |
| Fastweb, FWA (Casa FWA Light, Casa FWA Start) | la stessa frase della fibra | la stessa frase della fibra |
| Vodafone, FWA (Vodafone Casa Wireless 5G) | «viene fornito di default un IP privato dinamico. È possibile richiedere l’assegnazione di un IP pubblico dinamico contattando il Servizio Clienti» | «non è invece disponibile un indirizzo IPV6» |
| WindTre, rete fissa | «indirizzo IP pubblico dinamico ad eccezione del Servizio di accesso ad Internet fornito in FWA che invece viene fornito tramite indirizzo IP privato» | il contratto non ne parla |
| iliad, fibra (iliadbox Wi-Fi 7 2026) | «IP statico pubblico» | «IP statico pubblico» |
I documenti: per TIM la scheda di trasparenza tecnica della fibra (file del 09/09/2024) e quella dell’FWA (05/02/2025); per Fastweb le schede della fibra (27/10/2025) e dell’FWA (13/01/2026); per Vodafone la sintesi contrattuale del 14/04/2024; per WindTre le condizioni generali di contratto, versione 07/2025; per iliad la scheda del 03/02/2026.
Dalla tabella escono quattro cose. Tutte e quattro le offerte FWA che ho letto partono da un IP privato, ed FWA è anche il tipo della mia linea. In fibra, TIM, WindTre e iliad dichiarano un IP pubblico, Fastweb uno privato salvo richiesta. Nella voce sull’IP nessuno dei documenti indica un costo per averlo pubblico: chiedilo prima. E un IPv6 pubblico lo dichiara solo iliad in fibra: con IPv6 di solito il NAT non c’è, e un servizio si raggiunge da fuori aprendo il firewall del router invece di inoltrare una porta, ma solo da chi ha IPv6 a sua volta. Non l’ho provato: sul mio Deco IPv6 è spento.
Non ho trovato la scheda di Vodafone per la fibra, né un documento di ho. Mobile con questa voce: per loro niente riga.
Se il test ti dà un risultato diverso da quello che dichiara la scheda della tua offerta, la scheda è il documento da citare quando scrivi all’operatore.
Cosa non ho verificato
- La WAN dell’antenna. Senza, sulla mia linea il CGNAT resta probabile e non dimostrato.
- Perché la connessione diretta di Tailscale non si apre. Il lato di casa risulta «facile», quello del telefono non l’ho potuto misurare.
- Tailscale da altre reti. Una sola SIM, la stessa nelle due sere, e mai da un Wi-Fi diverso da quello di casa.
- IPv6. Sul server non c’è un indirizzo IPv6 globale perché sul Deco è spento, e non l’ho acceso: se con IPv6 il server si raggiunga da fuori, non lo so.
- La stabilità dell’IP oltre i 19 giorni che ho osservato.
- Il VPS, mai provato.
- Le linee degli altri operatori. Ho letto cosa dichiarano, non le ho provate.
Domande frequenti
Come faccio a sapere se sono dietro CGNAT?
Confronta l’IP che il router ha sulla WAN con quello visto da fuori (curl.exe https://api.ipify.org su Windows): fra 100.64 e 100.127 è CGNAT, uguale vuol dire niente CGNAT, privato vuol dire un altro NAT prima del router. Il test completo è nei tre passi qui sopra.
Il CGNAT blocca i bot Telegram o WhatsApp sul server di casa?
No: il bot apre connessioni in uscita, e quelle passano. Lo avevo già scritto quando ho valutato se tenere un agente AI in casa o in hosting. Il CGNAT conta solo per i servizi che devono ricevere connessioni da fuori.
Posso aprire una porta se sono dietro CGNAT?
Non dal tuo router: il NAT che conta è dell’operatore. Le strade sono chiedere all’operatore un IP pubblico, usare una VPN come Tailscale o un VPS che faccia da ponte. Se l’operatore ti dà un IPv6 pubblico c’è anche quella, ma non l’ho provata.
Come chiedo un IP pubblico al mio operatore?
Guarda prima la scheda di trasparenza tecnica della tua offerta, alla voce «Tipologia di indirizzo IPv4 assegnato»: TIM e Vodafone per l’FWA, e Fastweb, scrivono che l’IP pubblico si ottiene su richiesta (Vodafone dal Servizio Clienti). Il costo non lo indica nessuno: chiedilo prima.
Conclusione
Il mio test ha un limite che non posso togliere: la WAN dell’antenna non si legge, quindi il CGNAT resta probabile. Ma quello che ho misurato basta per decidere: due NAT certi in casa, nessuna porta che arrivi da fuori, e Tailscale che funziona lo stesso, sempre via relay, con una mediana di 195 ms una sera e 110,5 l’altra. Se il tuo router ti mostra la WAN, a te basta una schermata per avere la risposta che io non ho.
L’antenna e il Deco, i primi due salti del traceroute, restano accesi giorno e notte come il server. Quanto consumano lo sto misurando alla presa: avrà un articolo suo.
Nota: le misure di questo articolo sono state raccolte il 16 ottobre e nella notte fra il 26 e il 27 ottobre 2026, su una linea FWA di un operatore locale. I documenti degli operatori sono stati letti il 27 ottobre 2026: le offerte cambiano, e la scheda della tua è quella che conta.