Tailscale Serve ou Funnel : qui peut réellement ouvrir le lien ?

Les deux commandes publient un service local via un nom HTTPS Tailscale, et depuis la machine qui les exécute, elles semblent presque identiques. La différence tient à qui peut ensuite atteindre l’URL, et cette différence détermine les contrôles dont votre application a encore besoin. Serve garde le public à l’intérieur du tailnet ; Funnel le déplace vers l’internet ouvert. Choisissez d’abord le public, puis la commande qui lui correspond.

Serve répond à une question à l’intérieur de votre tailnet

Serve proxifie un port local ou sert du contenu local aux appareils de votre tailnet, et les règles d’accès du tailnet s’appliquent toujours à chaque requête. Un tableau de bord sur le port 3000 devient joignable à un nom HTTPS que seuls vos appareils peuvent résoudre et auquel ils peuvent se connecter. C’est le bon réglage par défaut pour les outils internes, car le public est déjà authentifié par le tailnet et vous n’ajoutez pas de surface publique. L’URL ressemble à un site web ordinaire, et c’est précisément pour cela que les gens la prennent pour tel.

Serve peut aussi joindre des en-têtes d’identité décrivant l’utilisateur du tailnet aux requêtes qu’il transmet. Si votre application fait confiance à ces en-têtes comme authentification, liez le backend à localhost pour que rien d’autre ne puisse l’atteindre directement ; un backend qui écoute sur une adresse routable peut recevoir des requêtes qui ne sont jamais passées par le proxy.

Funnel change le public pour l’internet ouvert

Funnel publie un service choisi pour quiconque possède l’URL, et les visiteurs n’ont besoin ni du client, ni d’un compte, ni d’une appartenance à votre tailnet. La ressource a donc besoin de l’authentification, de la limitation de débit et des correctifs que vous appliqueriez à tout service public. Les requêtes publiques ne portent pas les en-têtes d’identité tailnet de Serve, donc une application qui s’y fiait n’a aucune identité d’utilisateur sous Funnel. Choisir une autre commande de publication ne répond pas à la question de l’authentification à votre place.

Funnel a aussi des contraintes qu’un tutoriel d’une version plus ancienne peut ne pas mentionner. Il termine TLS avec un certificat que Tailscale obtient pour le nom, et il ne prend en charge que certains ports d’écoute, comme le décrit la documentation de Funnel. Si votre service attend un protocole autre que HTTPS sur l’un de ces ports, Funnel est le mauvais outil et non une énigme de configuration.

Lisez le mode depuis le client, pas depuis le port

Vérifiez l’état actuel avant de partager quoi que ce soit, car les deux modes peuvent être configurés pour le même port local à des moments différents. Les commandes d’état indiquent ce qui est réellement publié et pour qui. Ne déduisez pas le public du fait qu’une URL répond.

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

La syntaxe des commandes a changé selon les versions du client, si bien qu’une invocation copiée peut sélectionner un mode différent de celui que vous vouliez. Préférez la forme documentée pour la version que vous exécutez et lisez la confirmation imprimée par le client au lieu de la supposer. Si une configuration Serve et une configuration Funnel existent toutes deux, c’est la publique qui compte pour l’exposition. Réinitialisez la configuration que vous ne vouliez pas au lieu d’en empiler une autre par-dessus.

Arrêtez-vous et relisez l’état si la sortie ne nomme pas le public. Une URL publiée sans public déclaré est une supposition, et les suppositions sont la façon dont les tableaux de bord internes finissent sur l’internet ouvert.

Testez avec le public que vous vouliez réellement

Testez depuis l’extérieur du tailnet, pas depuis la machine qui a publié le service. Une requête depuis un appareil du tailnet prouve que le proxy fonctionne ; elle ne prouve pas qu’un inconnu est exclu. Utilisez un réseau sans client Tailscale et sans route vers le 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

Pour un tableau de bord interne, la requête externe devrait échouer à se connecter ou échouer à s’autoriser, et la requête interne devrait réussir avec l’identité attendue. Pour un service public, la requête externe devrait réussir et l’application devrait demander ses propres identifiants. Notez lequel de ces deux résultats vous avez observé, car l’URL seule ne vous le dit pas. Si le résultat est l’inverse de l’intention, retirez d’abord la configuration publique et enquêtez ensuite.

Publier un service n’est pas non plus la même décision que choisir un nœud de sortie, qui contrôle par où sort votre trafic sortant. Serve et Funnel répondent à qui peut atteindre quelque chose que vous exploitez ; un nœud de sortie répond d’où semblent venir vos propres connexions. Gardez les deux questions séparées et la comparaison reste simple.