Tailscale Funnel: la parola che mette la tua app su internet pubblico

Due comandi di Tailscale differiscono per una parola. tailscale serve condivide un servizio locale con i dispositivi della tua tailnet. tailscale funnel instrada il traffico da internet in senso ampio verso lo stesso servizio, raggiungibile da chiunque abbia l'URL.

Stessa sintassi, esposizione opposta. È tutto l'articolo in due frasi — ma sbagliare verso lascia su internet aperto un servizio che credevi privato, quindi vale la pena essere precisi su ciò che Funnel fa e non fa.

Che cos'è davvero Funnel

La descrizione di Tailscale è diretta: Funnel «consente di instradare traffico da internet in senso ampio verso un servizio locale in esecuzione su un dispositivo della tua rete Tailscale». Lo scopo è condividere con persone che non sono nella tua tailnet e non hanno un account Tailscale.

Serve è il caso inverso, e la documentazione lo dice senza giri di parole: se vuoi condividere servizi locali solo con gli altri dispositivi della tailnet, usa Serve.

La decisione non è quindi una preferenza tecnica, è una domanda sul tuo pubblico:

• Solo le tue macchine e le persone invitate nella tailnet → Serve.
• Chiunque abbia il link, sconosciuti compresi → Funnel.

Se non sai rispondere a questa domanda per un dato servizio, non lanciare ancora nessuno dei due comandi.

I tre vincoli che decidono se Funnel è adatto

Funnel è volutamente stretto, e i suoi limiti sono documentati invece che scoperti sul campo. Tre di essi risolvono la maggior parte dei casi prima ancora di scrivere una riga di configurazione.

Le porte: 443, 8443, 10000. È tutta la lista. Funnel può ascoltare solo su queste tre. Non è un valore predefinito da sovrascrivere: se il tuo servizio deve essere raggiungibile pubblicamente su un'altra porta, Funnel non è lo strumento.

Il nome host appartiene a Tailscale. Funnel può usare solo nomi DNS del dominio della tua tailnet, nella forma tailnet-name.ts.net. Se pensavi di mettere un prodotto, una demo per un cliente o qualcosa con il tuo marchio su un dominio tuo, non è ciò che fa.

La banda è limitata, e il limite non è tuo. Tailscale afferma che il traffico inviato tramite Funnel è soggetto a limiti di banda non configurabili. Per una pagina di configurazione o un piccolo strumento interno è irrilevante. Per trasmettere una mediateca ai familiari, quel tetto sarà probabilmente il vincolo, prima della tua banda in upload.

La parte che si salta: davanti non c'è nessun login

È la ragione per cui la confusione fra Serve e Funnel pesa più di un normale refuso.

La documentazione di Tailscale non descrive alcuno strato di autenticazione davanti a un endpoint Funnel, ed è una scelta progettuale: tutta la sua finalità è servire persone che non sono nella tailnet e che quindi non possono essere autenticate da essa. Funnel ti dà un ingresso HTTPS pubblico; non ti dà una porta.

Conseguenza pratica: l'autenticazione della tua applicazione è l'unica cosa fra internet e i tuoi dati. Una dashboard senza password, un file browser che si fida della rete locale, un pannello di amministrazione raggiungibile solo dalla LAN: tutti diventano aperti nel momento in cui vengono «funnelati» invece che serviti.

Prima di attivarlo su qualsiasi cosa, il test onesto sta in una domanda: pubblicherei questo URL apertamente senza problemi? Se la risposta è no, il servizio ha bisogno di una propria autenticazione, oppure di Serve invece di Funnel.

Attivarlo: prima il file di policy

Funnel non è attivo per impostazione predefinita su un nodo. Richiede un attributo di nodo funnel nel file di policy della tailnet, che dice a Tailscale quali utenti possono usarlo. Per impostazione predefinita il diritto va a autogroup:member.

Questa mediazione va capita più che saltata: significa che Funnel è una decisione amministrativa a livello di tailnet, non solo un comando che qualcuno lancia sul portatile. In una tailnet condivisa, chi controlla il file di policy controlla la possibilità stessa di esporre servizi pubblicamente.

Quando Funnel è la risposta giusta e quando no

Funnel va bene quando vuoi dare a qualcuno esterno alla tailnet un URL HTTPS funzionante con il minimo di cerimonie: un endpoint webhook che un servizio terzo deve raggiungere, un'anteprima di ciò che stai costruendo, una condivisione temporanea. Certificati e ingresso pubblico sono gestiti per te, e funziona su tutti i piani.

Funnel non va bene quando ti serve un dominio tuo, una porta fuori dalle tre consentite, un throughput sostenuto o uno strato di autenticazione che controlli. Questi requisiti puntano altrove: un reverse proxy su una macchina con IP pubblico proprio, o un prodotto di tunneling costruito attorno ai domini personalizzati.

E per il caso a cui si pensa più spesso ricorrendo a Funnel — voglio che i miei dispositivi raggiungano questo servizio da ovunque — né Funnel né un tunnel pubblico sono la risposta. È già quello che fa la tailnet, ed è ciò che fanno un nodo di uscita o un server WireGuard autogestito senza esporre nulla pubblicamente.

In sintesi

serve e funnel distano una parola nel terminale e sono opposti in ciò che pubblicano. Serve tiene un servizio dentro la tailnet; Funnel lo mette su internet, su una di tre porte, sotto un nome host ts.net, con un tetto di banda e senza nulla che autentichi i visitatori.

Decidi prima di digitare quale pubblico intendi davvero. Se la risposta è «le mie macchine», non ti è mai servito un ingresso pubblico — e l'esposizione più sicura resta quella che non si è mai aperta.