Tailscale Serve o Funnel: chi può davvero aprire il link?

Entrambi i comandi pubblicano un servizio locale tramite un nome HTTPS Tailscale, e dalla macchina che li esegue sembrano quasi identici. La differenza è chi può raggiungere l’URL in seguito, e quella differenza decide quali controlli servono ancora alla tua applicazione. Serve mantiene il pubblico dentro la tailnet; Funnel lo sposta su internet aperto. Scegli prima il pubblico, poi il comando che gli corrisponde.

Serve risponde a una domanda dentro la tua tailnet

Serve fa da proxy a una porta locale o serve contenuti locali ai dispositivi della tua tailnet, e le regole di accesso della tailnet valgono ancora per ogni richiesta. Una dashboard sulla porta 3000 diventa raggiungibile a un nome HTTPS che solo i tuoi dispositivi possono risolvere e a cui possono connettersi. È l’impostazione predefinita giusta per gli strumenti interni, perché il pubblico è già autenticato dalla tailnet e non stai aggiungendo una superficie pubblica. L’URL sembra un normale sito web, ed è proprio per questo che le persone lo prendono per tale.

Serve può anche allegare intestazioni di identità che descrivono l’utente della tailnet alle richieste che inoltra. Se la tua applicazione si fida di quelle intestazioni come autenticazione, lega il backend a localhost in modo che nient’altro possa raggiungerlo direttamente; un backend in ascolto su un indirizzo instradabile può ricevere richieste che non sono mai passate dal proxy.

Funnel cambia il pubblico su internet aperto

Funnel pubblica un servizio scelto per chiunque abbia l’URL, e i visitatori non hanno bisogno del client, di un account o dell’appartenenza alla tua tailnet. La risorsa necessita quindi dell’autenticazione, della limitazione di frequenza e delle patch che applicheresti a qualsiasi servizio pubblico. Le richieste pubbliche non portano le intestazioni di identità tailnet di Serve, quindi un’applicazione che vi si affidava non ha alcuna identità utente sotto Funnel. Scegliere un comando di pubblicazione diverso non risponde alla domanda sull’autenticazione al posto tuo.

Funnel ha anche vincoli che un tutorial di una versione precedente potrebbe non menzionare. Termina TLS con un certificato che Tailscale ottiene per il nome, e supporta solo porte di ascolto specifiche, come descrive la documentazione di Funnel. Se il tuo servizio si aspetta un protocollo diverso da HTTPS su una di quelle porte, Funnel è lo strumento sbagliato e non un enigma di configurazione.

Leggi la modalità dal client, non dalla porta

Controlla lo stato attuale prima di condividere qualcosa, perché le due modalità possono essere configurate per la stessa porta locale in momenti diversi. I comandi di stato riportano ciò che è realmente pubblicato e per chi. Non dedurre il pubblico dal fatto che un URL risponda.

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

La sintassi dei comandi è cambiata tra le versioni del client, quindi un’invocazione copiata può selezionare una modalità diversa da quella che intendevi. Preferisci la forma documentata per la versione che esegui e leggi la conferma stampata dal client invece di darla per scontata. Se esistono sia una configurazione Serve sia una Funnel, quella pubblica è quella che conta per l’esposizione. Reimposta la configurazione che non volevi invece di sovrapporne un’altra.

Fermati e rileggi lo stato se l’output non nomina il pubblico. Un URL pubblicato senza un pubblico dichiarato è una congettura, e le congetture sono il modo in cui le dashboard interne finiscono su internet aperto.

Prova con il pubblico che intendevi davvero

Prova dall’esterno della tailnet, non dalla macchina che ha pubblicato il servizio. Una richiesta da un dispositivo della tailnet dimostra che il proxy funziona; non dimostra che un estraneo sia escluso. Usa una rete senza client Tailscale e senza route verso la tailnet.

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

Per una dashboard interna, la richiesta esterna dovrebbe fallire la connessione o fallire l’autorizzazione, e la richiesta interna dovrebbe riuscire con l’identità che ti aspetti. Per un servizio pubblico, la richiesta esterna dovrebbe riuscire e l’applicazione dovrebbe chiedere le proprie credenziali. Annota quale dei due esiti hai osservato, perché il solo URL non te lo dice. Se il risultato è opposto all’intenzione, rimuovi prima la configurazione pubblica e indaga dopo.

Pubblicare un servizio non è nemmeno la stessa decisione che scegliere un nodo di uscita, che controlla da dove esce il tuo traffico in uscita. Serve e Funnel rispondono a chi può raggiungere qualcosa che esegui; un nodo di uscita risponde da dove sembrano arrivare le tue connessioni. Tieni separate le due domande e il confronto resta semplice.