La scelta per accedere a un homelab da remoto parte da chi deve usare il servizio. Per un sito pubblico servono un indirizzo raggiungibile e un percorso HTTP affidabile. Per NAS, SSH e pannelli di gestione preferisco un accesso privato con permessi espliciti.
NAT con port forwarding, Cloudflare Tunnel e Tailscale rispondono a esigenze diverse. Nel mio ambiente uso anche Headscale, il control plane autogestito compatibile con i client Tailscale. Non è necessario adottare un unico percorso per tutti i servizi.
La scelta in base all’uso
| Esigenza | Opzione da valutare | Condizione decisiva |
|---|---|---|
| Sito web pubblico con connettività entrante | Port forwarding e reverse proxy | IP raggiungibile, controllo del router e gestione TLS |
| Applicazione web pubblica dietro CGNAT | Cloudflare Tunnel | Accettare il servizio Cloudflare nel percorso |
| NAS, SSH, pannelli per dispositivi autorizzati | Rete privata Tailscale o Headscale | Client, identità e regole di accesso gestiti |
| Dispositivi LAN senza client VPN | Subnet router | Rotte e permessi limitati alle reti necessarie |
Port forwarding: quando controlli il percorso in ingresso
Con IPv4 pubblico, il dominio può puntare al router, che inoltra le porte del servizio a un reverse proxy interno. Se l’indirizzo cambia, un aggiornamento DNS dinamico mantiene il record allineato. Non rende però raggiungibile una linea che non ammette connessioni entranti.
Confrontare l’indirizzo WAN del router con quello osservato da internet è un primo indizio per riconoscere un NAT a monte. Una differenza non dimostra da sola il CGNAT: potrebbero esserci un secondo router o altri percorsi. Verifica la configurazione e le condizioni del provider. L’eventuale IPv6 pubblico richiede una valutazione separata di firewall e raggiungibilità.
Per un aggiornamento DNS automatizzato controllerei la risposta dell’API prima di registrare il nuovo IP come applicato. Un TTL basso può ridurre parte del ritardo delle cache, ma non è una promessa di propagazione entro un numero esatto di secondi.
Cloudflare Tunnel: il connettore apre la connessione in uscita
Con Cloudflare Tunnel, cloudflared crea connessioni in uscita verso Cloudflare. Il traffico destinato al servizio passa dall’edge al connettore e poi all’applicazione. Questo evita il port forwarding sul router per quel percorso, anche dietro CGNAT.
Un hostname pubblico del tunnel non aggiunge automaticamente l’autenticazione. Se serve Cloudflare Access, va configurato e provato con i client effettivi: browser, applicazioni mobili e integrazioni API possono avere requisiti diversi. Un login che funziona nel browser può interrompere una sincronizzazione automatica.
Controllerei inoltre il tratto tra connettore e applicazione. Se il servizio configurato è http://..., quel tratto usa HTTP; la cifratura della connessione esterna non lo trasforma in HTTPS. La scelta dipende da dove passa la rete e da chi può accedervi.
Tailscale e Headscale: raggiungere servizi privati
Tailscale costruisce una rete tra dispositivi autorizzati. Quando possibile, i dati viaggiano direttamente fra i nodi; in altre condizioni viene usato un relay. Il traffico applicativo non passa sempre da un punto centrale del fornitore. La documentazione sui tipi di connessione aiuta a riconoscere il percorso effettivo.
Nel mio ambiente il coordinamento principale è affidato a Headscale. Gestire il control plane in proprio aggiunge lavoro su aggiornamenti, configurazione, autenticazione e recupero. Non significa ottenere automaticamente tutte le funzioni del servizio Tailscale ospitato.
Una VPN protegge il trasporto e limita la raggiungibilità secondo le policy. Non elimina l’autenticazione dell’applicazione né il problema di verificare il certificato HTTPS. Per un pannello amministrativo mantengo entrambi i livelli.
Subnet router ed exit node fanno lavori diversi
Un subnet router rende raggiungibili reti specifiche, per esempio dispositivi LAN su cui non posso installare il client. Un exit node instrada invece il traffico internet di un client attraverso un altro nodo. Confonderli rende difficile capire dove stiano andando i pacchetti.
Per accedere a un NAS di casa non serve per forza far passare dalla connessione domestica tutta la navigazione del portatile. Serve una rotta corretta verso il NAS e una regola che autorizzi quel client.
Come verificare il setup senza inventare una classifica di latenze
Fai la prova da una rete esterna, non soltanto dal Wi-Fi del laboratorio. Controlla risoluzione DNS, connessione, certificato e una funzione reale dell’applicazione. Poi prova a togliere il permesso a un dispositivo: anche il rifiuto deve funzionare.
Per confrontare le prestazioni usa lo stesso client, servizio e carico. Distingui tempo di connessione, risposta HTTP e trasferimento di un file. Un RTT misurato verso un proxy non è necessariamente quello verso il server finale; una VPN può cambiare da connessione diretta a relay.
Per i servizi pubblici mantengo un percorso amministrativo privato che posso usare anche durante un guasto del sito. Per TLS, il seguito naturale è la guida a Caddy e challenge DNS-01. Il criterio resta scegliere e verificare il percorso di ciascun servizio, invece di esporre tutto perché il tunnel è disponibile.