Cos'è Cloudflare Tunnel e come usarlo

Hai un servizio che gira in casa — un pannello di gestione, un'applicazione in sviluppo, un server multimediale — e vorresti raggiungerlo da fuori. La strada classica è aprire una porta sul router, ma significa esporre la tua rete domestica a internet. E se sei dietro CGNAT, non puoi nemmeno farlo. In questo articolo trovi come Cloudflare Tunnel risolve entrambi i problemi, come si configura davvero e dove smette di essere la soluzione giusta.

Cos'è Cloudflare Tunnel

Cloudflare Tunnel è un collegamento che parte dalla tua macchina verso la rete Cloudflare e resta aperto, permettendo di raggiungere un servizio locale da un dominio pubblico senza aprire nessuna porta in entrata sul router.

La parola chiave è in uscita. Un piccolo programma sulla tua macchina, chiamato cloudflared, apre una connessione verso Cloudflare — esattamente come farebbe il browser. Cloudflare riceve le richieste per il tuo dominio e le fa scendere dentro quel collegamento già aperto.

Il router non deve permettere niente in entrata, perché nessuno bussa dalla tua parte. Sei tu che hai già chiamato.

Perché è molto più sicuro del port forwarding

Il port forwarding funziona così: apri la porta 443 sul router e la inoltri alla macchina interna. Da quel momento chiunque su internet può parlare con quel servizio, e la scansione automatica delle porte lo trova nel giro di ore.

Le conseguenze sono concrete:

Il tuo indirizzo IP di casa diventa pubblico e associato al servizio. Chi lo trova sa dove abiti, con l'approssimazione tipica della geolocalizzazione.
Ogni vulnerabilità del software esposto è raggiungibile subito. Un pannello di gestione con una falla nota e non aggiornata è un problema serio, non teorico.
Sei esposto agli attacchi volumetrici. Un attacco DDoS contro il tuo IP domestico ti mette offline tutta la casa, non solo il servizio.
Devi gestire tu i certificati e mantenere aggiornato il pezzo esposto.

Con un Tunnel la situazione si ribalta:

Nessuna porta in entrata aperta. Il firewall del router può restare chiuso completamente.
Il tuo IP di casa non è mai visibile. I visitatori vedono solo gli indirizzi Cloudflare.
Il servizio non è raggiungibile direttamente. L'unica via d'ingresso passa da Cloudflare, con protezione DDoS e filtri davanti.
HTTPS lo gestisce Cloudflare, certificato incluso e rinnovato da solo.
Funziona dietro CGNAT. È il caso in cui il tuo provider non ti dà un IP pubblico dedicato: il port forwarding è tecnicamente impossibile, mentre una connessione in uscita funziona sempre.

Il tema più ampio della superficie esposta è in cos'è la cybersecurity.

Come funziona cloudflared

Il funzionamento in cinque passaggi:

Installi cloudflared sulla macchina che ospita il servizio.
Autentichi il demone verso il tuo account e crei un tunnel, che riceve un identificativo e delle credenziali.
Configuri le regole di instradamento: quale nome pubblico corrisponde a quale indirizzo interno.
cloudflared apre più connessioni in uscita verso i punti di presenza Cloudflare e le mantiene aperte.
Cloudflare, per quel nome di dominio, instrada il traffico dentro il tunnel; cloudflared lo consegna al servizio locale e riporta indietro la risposta.

Il traffico da fuori arriva a Cloudflare in HTTPS, e da Cloudflare alla tua macchina viaggia dentro il collegamento cifrato del tunnel. Il servizio interno può tranquillamente parlare HTTP in chiaro su localhost, come farebbe dietro un reverse proxy.

Nota che le connessioni aperte sono più di una, verso punti di presenza diversi: se una cade, il traffico continua dalle altre. Il riavvio del router non richiede di rifare niente, il demone si riconnette da solo.

Configurarlo in pratica

Installazione su Debian o Ubuntu, che è il caso tipico di un Raspberry Pi o di un VPS:

curl -L https://pkg.cloudflare.com/cloudflare-main.gpg \
  | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main" \
  | sudo tee /etc/apt/sources.list.d/cloudflared.list

sudo apt update && sudo apt install cloudflared

Autenticazione e creazione del tunnel:

cloudflared tunnel login              # apre il browser, scegli il dominio
cloudflared tunnel create casa        # crea il tunnel e le credenziali
cloudflared tunnel list               # verifica: ti mostra l'ID

Il file di configurazione, in ~/.cloudflared/config.yml:

tunnel: casa
credentials-file: /home/utente/.cloudflared/<ID-DEL-TUNNEL>.json

ingress:
  - hostname: pannello.miodominio.it
    service: http://localhost:8080

  - hostname: note.miodominio.it
    service: http://localhost:3000

  - hostname: nas.miodominio.it
    service: https://192.168.1.50:5001
    originRequest:
      noTLSVerify: true      # certificato autofirmato sul dispositivo interno

  - service: http_status:404 # regola finale obbligatoria

L'ultima regola senza hostname è obbligatoria, ed è l'errore numero uno: senza, cloudflared non parte e il messaggio non è particolarmente esplicito.

Ora i record DNS. Non li crei a mano: c'è un comando che li imposta correttamente per te, con il tipo giusto (un CNAME verso il tunnel) e il proxy attivo.

cloudflared tunnel route dns casa pannello.miodominio.it
cloudflared tunnel route dns casa note.miodominio.it
cloudflared tunnel route dns casa nas.miodominio.it

Prova in primo piano, poi installalo come servizio di sistema:

cloudflared tunnel run casa          # prova, con i log a schermo

sudo cloudflared service install     # avvio automatico al boot
sudo systemctl status cloudflared

Da questo momento i tre nomi rispondono da internet, in HTTPS, con il router chiuso. Se il dominio non è ancora su Cloudflare, il passaggio è quello descritto in collegare un dominio al sito.

C'è anche la modalità rapida, senza account e senza dominio, che genera un indirizzo casuale e temporaneo:

cloudflared tunnel --url http://localhost:3000

È comodissima per far vedere a un collega quello che stai sviluppando in locale. Non usarla per niente di stabile: l'indirizzo cambia a ogni avvio e non ha nessuna protezione davanti.

Accesso protetto da autenticazione

Il tunnel rende il servizio raggiungibile, ma non lo protegge da chi lo trova. Un pannello di gestione senza autenticazione esposto su un tunnel è esposto quanto lo sarebbe con il port forwarding, semplicemente senza il tuo IP di mezzo.

Il pezzo che manca è il controllo degli accessi, che su Cloudflare si configura come una politica applicata al nome di dominio, prima che la richiesta entri nel tunnel. Le forme più usate:

Accesso solo a indirizzi email specifici, con codice inviato via posta elettronica.
Accesso tramite provider di identità — Google, GitHub, Microsoft, o quello aziendale.
Restrizioni per paese o intervallo di indirizzi IP.
Token di servizio per le chiamate automatiche, che un browser non può soddisfare.

Il risultato è che chi apre pannello.miodominio.it vede prima una schermata di accesso Cloudflare, e solo dopo il tuo servizio. La richiesta non autenticata non arriva mai alla tua macchina, ed è la differenza sostanziale rispetto a mettere una password sull'applicazione.

Nel piano gratuito questa funzionalità è disponibile per un numero limitato di utenti, che per un homelab domestico è più che sufficiente. Restano comunque valide le regole generali di rendere un sito sicuro: il controllo all'ingresso non ti esonera dall'aggiornare quello che c'è dietro.

I limiti

Onestà anche qui, perché il Tunnel non è la risposta a tutto.

Dipendi da Cloudflare. Se il servizio ha un disservizio, i tuoi nomi pubblici non rispondono. In locale continui a raggiungere tutto per IP, ma da fuori sei fermo.

Il traffico non HTTP richiede attenzione. SSH, RDP e i protocolli TCP generici passano dal tunnel, ma il client deve usare cloudflared come intermediario locale — non basta puntare il programma al nome di dominio. Il collegamento con SSH funziona bene, ma va configurato dal lato di chi si connette.

Non è pensato per i file di grandi dimensioni in streaming continuo. Il proxy Cloudflare ha limiti sulla dimensione dei corpi delle richieste sui piani base, e i termini di servizio scoraggiano l'uso della rete come distribuzione di video o archivi pesanti. Per un server multimediale usato da te va bene; come piattaforma di distribuzione pubblica, no.

Aggiunge un passaggio di rete. Il traffico va all'utente passando da Cloudflare, quindi c'è un salto in più rispetto alla connessione diretta. Nella maggior parte dei casi è impercettibile, ma non è zero.

Non sostituisce una VPN. Se ti serve accedere a tutta la rete di casa come se fossi lì, il Tunnel non è lo strumento: espone servizi specifici, non una rete. Cloudflare ha prodotti che coprono quel caso, ma sono un'altra cosa.

Cosa fa perdere ore

Dimenticare la regola finale http_status:404. Il servizio non parte e cerchi altrove.

Sbagliare protocollo verso il servizio interno. Se il servizio locale parla HTTPS con certificato autofirmato e tu scrivi http://, ottieni errori 502 che sembrano problemi di rete. Metti https:// e aggiungi noTLSVerify: true.

Creare il record DNS a mano. Un record A verso un IP non funziona con un tunnel: serve il CNAME verso l'endpoint del tunnel. Usa cloudflared tunnel route dns e lascia fare a lui.

Provarlo dalla rete di casa e concludere che non funziona. Alcuni router non gestiscono bene il ritorno sul proprio IP pubblico. Prova dalla rete mobile del telefono prima di indagare.

Usare il file di configurazione mentre esiste una configurazione remota. Se hai creato il tunnel dalla dashboard, le regole vivono lì e il config.yml locale viene ignorato. Scegline una: o tutto da file, o tutto dalla dashboard.

Lasciare un pannello di gestione senza autenticazione davanti. Il tunnel nasconde il tuo IP, non mette una porta blindata. Le politiche di accesso vanno configurate, non arrivano da sole.

Tunnel, port forwarding o VPS

	Cloudflare Tunnel	Port forwarding	Servizio su VPS
Porte aperte sul router	Nessuna	Sì	Non serve il router
IP di casa visibile	No	Sì	No
Funziona dietro CGNAT	Sì	No	Sì
HTTPS	Automatico	Lo gestisci tu	Lo gestisci tu
Protezione DDoS	Inclusa	Nessuna	Da aggiungere
Autenticazione all'ingresso	Configurabile	No	Da costruire
Costo	Gratuito nei casi tipici	Gratuito	Canone mensile
Dipendenze esterne	Cloudflare	Nessuna	Il provider

Per un homelab la scelta è quasi sempre il Tunnel, e il port forwarding è difficile da giustificare oggi. Il VPS è un'altra categoria: ha senso quando vuoi che il servizio giri fuori casa, non quando vuoi raggiungere quello che hai già in casa. Il confronto tra Docker sul Pi di casa e lo stesso stack su un server remoto è una scelta di dove far girare le cose, non di come esporle.

In sintesi

Cloudflare Tunnel espone un servizio locale su internet aprendo una connessione in uscita, quindi senza toccare il firewall del router.

È più sicuro del port forwarding per tre motivi concreti: nessuna porta in ascolto, il tuo IP di casa mai visibile, e la protezione Cloudflare davanti. In più funziona dietro CGNAT, dove il port forwarding proprio non è un'opzione.

Il tunnel rende raggiungibile, non protegge. Le politiche di accesso all'ingresso sono il pezzo che completa il quadro, e vanno configurate a mano.

I limiti sono reali: dipendenza da Cloudflare, protocolli non HTTP che richiedono il client, e nessuna sostituzione di una VPN vera.

Per partire con l'autoproduzione domestica vedi la guida all'homelab per principianti, e per il contesto della piattaforma cos'è Cloudflare.