Tailscale Funnel : le mot qui met votre application sur l'internet public

Deux commandes Tailscale ne diffèrent que d'un mot. tailscale serve partage un service local avec les appareils de votre propre tailnet. tailscale funnel achemine le trafic depuis l'internet au sens large vers ce même service, accessible à quiconque possède l'URL.

Même syntaxe, exposition inverse. C'est tout l'article en deux phrases — mais se tromper de sens laisse sur l'internet ouvert un service que vous croyiez privé, alors il vaut la peine d'être précis sur ce que Funnel fait, et ne fait pas.

Ce qu'est réellement Funnel

La description de Tailscale est directe : Funnel « permet d'acheminer le trafic depuis l'internet au sens large vers un service local tournant sur un appareil de votre réseau Tailscale ». L'objectif est de partager avec des personnes qui ne sont pas sur votre tailnet et n'ont pas de compte Tailscale.

Serve est le cas inverse, et la documentation le dit sans détour : si vous voulez partager des services locaux uniquement avec les autres appareils de votre tailnet, utilisez Serve.

La décision n'est donc pas une préférence technique, c'est une question sur votre public :

• Uniquement vos machines et les personnes invitées dans le tailnet → Serve.
• N'importe qui avec le lien, y compris des inconnus → Funnel.

Si vous ne savez pas répondre à cette question pour un service donné, ne lancez encore aucune des deux commandes.

Les trois contraintes qui décident si Funnel convient

Funnel est volontairement étroit, et ses limites sont documentées plutôt que subies. Trois d'entre elles tranchent la plupart des cas avant même d'écrire une ligne de configuration.

Les ports : 443, 8443, 10000. C'est toute la liste. Funnel ne peut écouter que sur ces trois-là. Ce n'est pas une valeur par défaut à surcharger — si votre service doit être joignable publiquement sur un autre port, Funnel n'est pas le bon outil.

Le nom d'hôte appartient à Tailscale. Funnel ne peut utiliser que des noms DNS du domaine de votre tailnet, de la forme tailnet-name.ts.net. Si vous comptiez poser un produit, une démo client ou quoi que ce soit portant votre marque sur un domaine à vous, ce n'est pas ce que fait cet outil.

La bande passante est plafonnée, et le plafond n'est pas le vôtre. Tailscale indique que le trafic envoyé via Funnel est soumis à des limites non configurables. Pour une page de configuration ou un petit outil interne, sans importance. Pour diffuser une médiathèque à des proches, ce plafond sera probablement la contrainte, avant votre débit montant.

Ce que l'on saute : il n'y a aucune authentification devant

C'est la raison pour laquelle la confusion Serve/Funnel compte davantage qu'une faute de frappe ordinaire.

La documentation de Tailscale ne décrit aucune couche d'authentification devant un point d'entrée Funnel — et c'est délibéré, puisque toute la finalité est de servir des gens qui ne sont pas sur votre tailnet et ne peuvent donc pas être authentifiés par lui. Funnel vous donne un point d'entrée HTTPS public ; il ne vous donne pas de porte.

Conséquence pratique : l'authentification de votre application est la seule chose entre l'internet et vos données. Un tableau de bord sans mot de passe, un explorateur de fichiers qui fait confiance au réseau local, un panneau d'administration qui n'était joignable que depuis votre LAN — tous deviennent ouverts dès l'instant où ils sont « funnelés » plutôt que « servis ».

Avant d'activer cela sur quoi que ce soit, le test honnête tient en une question : serais-je à l'aise de publier cette URL publiquement ? Si la réponse est non, le service a besoin de sa propre authentification, ou bien de Serve plutôt que de Funnel.

L'activer : le fichier de politique d'abord

Funnel n'est pas actif par défaut sur un nœud. Il exige un attribut de nœud funnel dans le fichier de politique de votre tailnet, qui indique à Tailscale quels utilisateurs ont le droit de s'en servir. Par défaut, ce droit va à autogroup:member.

Cette indirection mérite d'être comprise plutôt que cliquée : elle signifie que Funnel est une décision administrative au niveau du tailnet, pas seulement une commande qu'un utilisateur lance sur son portable. Dans un tailnet partagé, celui qui contrôle le fichier de politique contrôle la possibilité même d'exposer des services publiquement.

Quand Funnel est la bonne réponse, et quand il ne l'est pas

Funnel convient quand vous voulez donner à quelqu'un d'extérieur à votre tailnet une URL HTTPS qui marche, avec un minimum de cérémonie : un point d'entrée webhook qu'un service tiers doit atteindre, un aperçu de ce que vous construisez, un partage temporaire. Les certificats et le point d'entrée public sont pris en charge, et cela fonctionne sur tous les plans.

Funnel ne convient pas quand il vous faut un domaine à vous, un port hors des trois autorisés, un débit soutenu, ou une couche d'authentification que vous maîtrisez. Ces besoins pointent ailleurs : un reverse proxy sur une machine avec sa propre IP publique, ou un produit de tunnel bâti autour des domaines personnalisés.

Et pour le cas auquel les gens pensent le plus souvent en se tournant vers Funnel — je veux que mes propres appareils atteignent ce service depuis n'importe où — ni Funnel ni un tunnel public n'est la réponse. C'est ce que le tailnet fait déjà, et ce qu'un nœud de sortie ou un serveur WireGuard auto-hébergé fait sans rien exposer publiquement.

L'essentiel

serve et funnel sont à un mot d'écart dans le terminal et opposés dans ce qu'ils publient. Serve garde un service à l'intérieur du tailnet ; Funnel le met sur l'internet, sur l'un de trois ports, sous un nom d'hôte ts.net, avec un plafond de bande passante et rien qui authentifie les visiteurs.

Décidez du public que vous visez réellement avant de taper l'une ou l'autre. Si la réponse est « mes propres machines », vous n'aviez jamais besoin d'un point d'entrée public — et l'exposition la plus sûre reste celle que l'on n'a jamais ouverte.