Tailscale Serve o Funnel: qui pot obrir realment l’enllaç?

Totes dues ordres publiquen un servei local mitjançant un nom HTTPS de Tailscale, i des de la màquina que les executa semblen gairebé idèntiques. La diferència és qui pot arribar a l’URL després, i aquesta diferència decideix quins controls encara necessita la teva aplicació. Serve manté el públic dins de la tailnet; Funnel el trasllada a internet obert. Tria primer el públic i després tria l’ordre que hi encaixi.

Serve respon una pregunta dins de la teva tailnet

Serve fa de proxy d’un port local o serveix contingut local als dispositius de la teva tailnet, i les regles d’accés de la tailnet continuen valent per a cada sol·licitud. Un tauler al port 3000 es fa accessible en un nom HTTPS que només els teus dispositius poden resoldre i al qual es poden connectar. És el valor per defecte correcte per a eines internes, perquè el públic ja està autenticat per la tailnet i no afegeixes una superfície pública. L’URL sembla un lloc web normal, i és exactament per això que la gent el pren per un.

Serve també pot adjuntar capçaleres d’identitat que descriuen l’usuari de la tailnet a les sol·licituds que reenvia. Si la teva aplicació confia en aquestes capçaleres com a autenticació, lliga el backend a localhost perquè res més no hi pugui arribar directament; un backend que escolta en una adreça enrutable pot rebre sol·licituds que mai no han passat pel proxy.

Funnel canvia el públic a internet obert

Funnel publica un servei seleccionat per a qualsevol que tingui l’URL, i els visitants no necessiten el client, un compte ni pertinença a la teva tailnet. El recurs, doncs, necessita l’autenticació, la limitació de taxa i els pedaços que aplicaries a qualsevol servei públic. Les sol·licituds públiques no porten les capçaleres d’identitat de la tailnet de Serve, així que una aplicació que hi confiava no té cap identitat d’usuari sota Funnel. Triar una ordre de publicació diferent no respon la pregunta de l’autenticació per tu.

Funnel també té restriccions que un tutorial d’una versió més antiga potser no esmenta. Acaba TLS amb un certificat que Tailscale obté per al nom, i només admet ports d’escolta concrets, tal com descriu la documentació de Funnel. Si el teu servei espera un protocol diferent d’HTTPS en un d’aquests ports, Funnel és l’eina equivocada i no un trencaclosques de configuració.

Llegeix el mode des del client, no des del port

Comprova l’estat actual abans de compartir res, perquè els dos modes es poden configurar per al mateix port local en moments diferents. Les ordres d’estat informen què s’ha publicat realment i per a qui. No dedueixis el públic del fet que un URL respongui.

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

La sintaxi de les ordres ha canviat entre versions del client, així que una invocació copiada pot seleccionar un mode diferent del que volies. Prefereix la forma documentada per a la versió que executes i llegeix la confirmació que imprimeix el client en lloc de suposar-la. Si existeixen tant una configuració de Serve com una de Funnel, la pública és la que importa per a l’exposició. Restableix la configuració que no volies en lloc d’afegir-ne una altra a sobre.

Atura’t i torna a llegir l’estat si la sortida no nomena el públic. Un URL publicat sense un públic declarat és una conjectura, i les conjectures són com els taulers interns acaben a internet obert.

Prova amb el públic que realment volies

Prova des de fora de la tailnet, no des de la màquina que ha publicat el servei. Una sol·licitud des d’un dispositiu de la tailnet demostra que el proxy funciona; no demostra que un desconegut quedi exclòs. Fes servir una xarxa que no tingui cap client de Tailscale ni cap ruta cap a 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 a un tauler intern, la sol·licitud externa hauria de fallar en connectar o fallar en autoritzar, i la sol·licitud interna hauria de reeixir amb la identitat que esperes. Per a un servei públic, la sol·licitud externa hauria de reeixir i l’aplicació hauria de demanar les seves pròpies credencials. Anota quin d’aquests dos resultats has observat, perquè l’URL sol no t’ho diu. Si el resultat és el contrari del que volies, elimina primer la configuració pública i investiga després.

Publicar un servei tampoc no és la mateixa decisió que triar un node de sortida, que controla per on surt el teu trànsit de sortida. Serve i Funnel responen qui pot arribar a una cosa que executes; un node de sortida respon d’on sembla que vénen les teves pròpies connexions. Mantén les dues preguntes separades i la comparació continua sent simple.