TLDR
- Cloudflare Tunnel e ZeroTier rendono semplice raggiungere servizi locali senza aprire porte sul router.
- La comodità non elimina il rischio: un dev server locale può contenere debug, cookie, pannelli admin, API key, endpoint non pensati per Internet.
- Quick Tunnel è perfetto per demo e test brevi, ma non sostituisce autenticazione, policy, log e gestione della durata.
- Prima di esporre qualcosa, chiediti cosa pubblichi, chi può entrare, per quanto tempo resta online e cosa succede se l'URL gira.
La magia del link pubblico
C'è un momento molto bello nello sviluppo web: hai qualcosa su localhost, vuoi mostrarlo a qualcuno, lanci un tunnel, copi un URL e all'improvviso il tuo portatile è raggiungibile da Internet.
Niente port forwarding.
Niente IP pubblico.
Niente router da convincere.
Hacker Journal dedica un how-to proprio a questa idea: progetto locale, Next.js, Cloudflare Tunnel, Quick Tunnel temporaneo e poi, se serve, dominio associato. È un flusso comodissimo per demo, test, collaborazione e homelab.
Ma la domanda interessante non è "funziona?".
La domanda interessante è: cosa hai appena pubblicato?
Localhost non è una zona santa
Molti servizi locali sono scritti pensando a un contesto protetto.
Un dev server può avere:
- debug attivo;
- stack trace dettagliati;
- endpoint non autenticati;
- cookie di sessione;
- pannelli admin;
- dati demo troppo realistici;
- API key in variabili d'ambiente;
- file statici dimenticati;
- CORS aperto;
- hot reload;
- log verbosi;
- dipendenze non aggiornate.
Finché è davvero locale, il rischio è contenuto. Appena diventa raggiungibile da Internet, cambia categoria.
Non è più "sto provando una cosa".
È "sto esponendo un servizio".
Cloudflare Tunnel in una frase
Cloudflare Tunnel usa cloudflared per creare una connessione in uscita dal tuo sistema verso Cloudflare. Il traffico pubblico passa dalla rete Cloudflare e viene inoltrato al servizio locale.
Questa architettura evita di aprire porte sul router e rende più gestibile la pubblicazione. Puoi aggiungere controlli, applicazioni self-hosted, policy Access, log e dominio.
È molto meglio di "apri la porta 3000 e spera".
Ma non significa che il servizio dietro sia magicamente sicuro.
Il tunnel protegge il percorso.
Tu devi proteggere l'applicazione.
Quick Tunnel: demo sì, abitudine no
Il Quick Tunnel è perfetto quando devi mostrare una pagina a qualcuno per pochi minuti.
È il tipo di strumento che ti salva una call: "guarda qui", "prova questo form", "ti faccio vedere il bug".
Il rischio nasce quando diventa abitudine:
- link lasciato attivo per ore;
- terminale dimenticato;
- URL incollato in chat affollate;
- servizio con dati veri;
- endpoint non pensati per utenti esterni;
- nessun controllo su chi ha aperto cosa.
La regola pratica:
un Quick Tunnel deve avere una fine.
Se non sai quando lo spegnerai, non è più quick.
ZeroTier: rete privata, non invisibilità
ZeroTier risolve un problema diverso: creare reti virtuali tra dispositivi autorizzati, spesso dietro NAT, senza configurazioni pesanti.
È fantastico per homelab, NAS, macchine remote, piccoli team, test multi-dispositivo, server casalinghi e reti temporanee.
Ma anche qui c'è una trappola mentale: "è nella rete privata, quindi è sicuro".
No.
È più controllato di un servizio pubblico, ma resta una rete. Se autorizzi un dispositivo sbagliato, se riusi credenziali, se non segmenti, se colleghi tutto a tutto, hai solo spostato il problema.
Zero Trust, nel senso NIST, non è fidarsi della rete virtuale. È verificare identità, dispositivo, policy e accesso per ogni risorsa.
La rete privata è un mezzo.
Non una benedizione.
Il threat model prima del comando
Prima di pubblicare qualcosa, rispondi a cinque domande.
Cosa sto pubblicando?
Una pagina statica? Un'app con login? Un'API? Un pannello admin? Un servizio con file locali?
Chi deve entrare?
Una persona? Un team? Chiunque abbia il link? Solo un'email autorizzata? Solo un device nella rete privata?
Quanto deve durare?
Cinque minuti? Una giornata? Una demo? Un servizio stabile?
Cosa vedo nei log?
So chi ha aperto il link? Vedo IP, path, errori, tentativi strani? Posso esportare o controllare eventi?
Cosa succede se l'URL gira?
Se qualcuno lo inoltra, il servizio resta aperto? C'è autenticazione? Ci sono rate limit? Ci sono dati sensibili?
Se non sai rispondere, non pubblicare ancora.
Checklist sana per demo e test
Per una demo temporanea:
- usa dati finti;
- disattiva debug troppo verbosi;
- rimuovi endpoint admin;
- limita durata;
- non incollare segreti nei log;
- controlla che il servizio ascolti solo dove serve;
- chiudi tunnel e dev server appena finito.
Per un servizio stabile:
- usa dominio e tunnel gestito;
- aggiungi autenticazione;
- definisci policy Access;
- usa log e alert;
- aggiorna
cloudflared; - separa ambiente dev e produzione;
- non esporre direttamente database, admin panel o storage;
- documenta come spegnere tutto.
Per homelab:
- segmenta servizi;
- usa account dedicati;
- niente password di default;
- backup separati;
- monitoraggio base;
- accesso minimo per device;
- revoca rapida.
Qui si collega bene l'articolo su UniFi e dashboard di rete: ogni pannello admin, anche se "solo di casa", diventa produzione quando è raggiungibile da altri.
Tunnel e AI locali: una combinazione delicata
Questo tema diventa ancora più interessante se lo colleghi agli LLM locali.
Nell'articolo su LLM locali e log sul disco abbiamo visto che strumenti come LM Studio o Ollama possono esporre API locali. Se poi qualcuno pubblica quella porta con un tunnel, la domanda cambia:
- chi può inviare prompt?
- il modello può chiamare tool?
- ci sono documenti caricati?
- ci sono cronologie?
- ci sono endpoint compatibili OpenAI senza auth?
- il tunnel è temporaneo o stabile?
Un dev server AI non è solo una pagina.
È una bocca collegata a memoria, file, modello e talvolta strumenti.
Meglio non lasciarla aperta sul marciapiede.
La frase da ricordare
Cloudflare Tunnel, ZeroTier e strumenti simili sono fantastici perché riducono l'attrito.
Ma la sicurezza spesso vive proprio nell'attrito giusto: login, durata, log, revoca, policy, separazione.
Pubblicare localhost non è un peccato.
Far finta che sia ancora locale, sì.
FAQ
Cloudflare Tunnel è sicuro?
È uno strumento utile e progettato per evitare port forwarding diretto, ma la sicurezza dipende da cosa pubblichi, come controlli l'accesso, quali log hai e quali segreti contiene il servizio locale.
Un Quick Tunnel va bene per produzione?
No. È comodo per test rapidi e demo temporanee. Per uso stabile servono dominio, tunnel gestito, policy di accesso, monitoraggio e configurazione ripetibile.
ZeroTier è uguale a Cloudflare Tunnel?
No. ZeroTier crea reti virtuali tra dispositivi autorizzati; Cloudflare Tunnel pubblica o collega servizi tramite l'infrastruttura Cloudflare. Entrambi riducono il bisogno di aprire porte, ma hanno threat model diversi.
Qual è l'errore più comune?
Pubblicare un servizio di sviluppo come se fosse una pagina statica: debug attivo, endpoint admin, CORS largo, dati demo realistici e nessuna autenticazione.
Cosa devo controllare prima di condividere un link?
Che il servizio non contenga segreti, che l'accesso sia limitato, che i log siano visibili, che la durata sia breve e che tu sappia spegnerlo subito.