Configuration Tailscale

Chute intègre nativement le réseau Tailscale. Une fois configuré, vous pouvez référencer la politique intégrée TAILSCALE depuis des règles ou des groupes de politiques pour faire passer le trafic par votre tailnet — joindre d'autres appareils du tailnet, sortir par un nœud de sortie ou accéder aux sous-réseaux annoncés par des pairs.

Contrairement aux protocoles de proxy ordinaires, Tailscale n'est pas une politique par ligne définie dans [Proxy] ; il se configure au moyen d'une seule section [Tailscale], globalement unique. Elle enregistre le nœud auprès du serveur de contrôle à l'aide d'une clé d'authentification, sans connexion interactive par navigateur.

Section Tailscale

Une section [Tailscale] définit tout ce dont un appareil a besoin pour rejoindre un tailnet :

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
control-server = https://controlplane.tailscale.com
hostname = my-device
exit-node = 100.101.102.103
accept-routes = true
force-derp = false

Remarque : une seule section [Tailscale] est autorisée dans l'ensemble du fichier de configuration. Une section [Tailscale] en double est traitée comme une erreur de configuration. En effet, le moteur Tailscale est lourd et les plages d'adresses de tailnet sont mutuellement exclusives — un seul tailnet peut être rejoint à la fois. La forme nommée de Surge [Tailscale <name>] est lue comme cette section ; la limite d'une seule section s'applique toujours.

Paramètres

Les graphies de Surge sont acceptées comme alias : control-url pour control-server et derp-only pour force-derp.

Les valeurs booléennes acceptent les écritures suivantes (sans distinction de casse) : true/false, 1/0, yes/no, on/off.

Remarque : les clés inconnues sont ignorées avec un avertissement (elles ne bloquent pas le chargement de la configuration). Une clé mal orthographiée (par ex. force-derp écrit force_derp) désactivera silencieusement l'option concernée — vérifiez-la par rapport au tableau ci-dessus.

La politique intégrée TAILSCALE

Une fois la section [Tailscale] configurée, l'identifiant de politique intégré TAILSCALE devient disponible — il se place aux côtés de DIRECT et REJECT et peut être référencé directement dans les règles et les groupes de politiques. Lorsque la section [Tailscale] n'est pas configurée, ou lorsque Tailscale est désactivé, les règles référençant TAILSCALE se replient sur REJECT (fail-closed).

[Proxy Group]
Mesh = select, TAILSCALE, DIRECT

[Rule]
IP-CIDR,100.64.0.0/10,TAILSCALE,no-resolve
FINAL,DIRECT

Routage automatique

Lorsque Tailscale est activé, Chute injecte automatiquement les trois règles suivantes en amont de toutes vos règles, de sorte que vous n'avez généralement pas besoin d'écrire à la main des règles pour joindre le tailnet :

DOMAIN-SUFFIX,ts.net,TAILSCALE
IP-CIDR,100.64.0.0/10,TAILSCALE,no-resolve
IP-CIDR6,fd7a:115c:a1e0::/48,TAILSCALE,no-resolve

Lorsque le domaine de base MagicDNS du tailnet n'est pas ts.net — un déploiement Headscale —, une règle DOMAIN-SUFFIX,<domaine de base>,TAILSCALE est injectée pour lui également, avant les règles d'acceptation de routes.

Ces règles injectées n'existent qu'à l'exécution et ne modifient jamais votre fichier de configuration. Lorsque accept-routes = true est défini, les sous-réseaux annoncés par les pairs sont eux aussi auto-injectés sous forme de règles IP-CIDR / IP-CIDR6 correspondantes, et mis à jour automatiquement à mesure que les pairs ajoutent ou retirent des sous-réseaux.

Utilisation

Joindre des appareils du tailnet

Une fois la section [Tailscale] configurée, joindre d'autres appareils du tailnet ne nécessite aucune règle supplémentaire — les règles injectées couvrent déjà les plages du tailnet et le suffixe MagicDNS. Vous pouvez adresser les pairs directement par nom MagicDNS ou par IP de tailnet :

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
hostname = my-iphone

[Rule]
FINAL,DIRECT

Des cibles telles que my-pc.<tailnet>.ts.net ou 100.101.102.103 passeront désormais automatiquement par Tailscale.

Sortir par un nœud de sortie

Définissez TAILSCALE comme cible de FINAL pour envoyer par le nœud de sortie tout le trafic qui ne correspond à aucune règle plus précise :

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
exit-node = 100.101.102.103

[Rule]
FINAL,TAILSCALE

Remarque : définir exit-node seul n'achemine aucun trafic par ce nœud — vous devez également ajouter une règle qui envoie le trafic vers TAILSCALE (par exemple FINAL,TAILSCALE). Sans une telle règle, le nœud de sortie est configuré mais inutilisé ; les éditeurs de configuration de Chute Mac, Chute iOS et Chute Android le signalent, celui de Chute tvOS non.

Accepter les routes de sous-réseau

Lorsqu'un appareil du tailnet joue le rôle de routeur de sous-réseau et annonce des sous-réseaux locaux, activez accept-routes = true pour joindre ces sous-réseaux ; les règles de routage correspondantes sont injectées automatiquement :

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
accept-routes = true

Servir de nœud de sortie (macOS)

macOS uniquement. iOS, tvOS et Android peuvent utiliser un nœud de sortie mais ne peuvent pas en être un. Les clés ci-dessous y sont analysées, mais ignorées avec un avertissement.

Un Mac exécutant Chute peut être lui-même un nœud de sortie, afin que vos autres appareils fassent transiter leur trafic Internet par lui. Activez-le dans l'onglet Config de la fenêtre principale → Proxy → Tailscale → Servir de nœud de sortie pour les autres appareils, dans le sous-menu Tailscale de la barre des menus → Servir de nœud de sortie, ou dans la configuration :

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
advertise-exit-node = true

Pour partager un réseau local au lieu (ou en plus) d'un accès Internet complet, listez les sous-réseaux :

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
advertise-routes = 192.168.1.0/24, 10.0.0.0/8

Annoncer n'est qu'une proposition. Un administrateur doit approuver les routes dans la console d'administration Tailscale (ou avec headscale nodes approve-routes) avant qu'un appareil puisse sélectionner ce Mac. D'ici là, la barre des menus affiche En attente d'approbation dans la console d'administration, et aucun trafic ne circule.

Une fois approuvé, les autres appareils le sélectionnent comme n'importe quel nœud de sortie, et la barre des menus indique combien de flux ce Mac transporte.

Quelques points à connaître avant de l'activer :

• Le trafic des autres appareils utilise la connexion Internet de ce Mac et sort sous son adresse IP ; il est donc décompté de cette connexion et attribué à ce réseau.
• Le service s'interrompt lorsque le Mac se met en veille. Activez Maintenir le Mac éveillé pendant le service dans le menu Tailscale pour le garder éveillé exactement le temps où il est approuvé et en service. Rabattre l'écran le met tout de même en veille — aucun réglage ne prime là-dessus, et le client macOS officiel de Tailscale connaît la même limitation.
• L'ICMP n'est pas transmis : un ping émis par un autre appareil à travers ce nœud de sortie reste donc sans réponse. tailscale ping n'est pas concerné : il n'utilise pas l'ICMP.

Les clients iOS et tvOS officiels de Tailscale connaissent la même limitation, pour la même raison : une extension réseau ne peut pas héberger un chemin de transfert de longue durée.

Serveur de contrôle personnalisé (Headscale)

Outre le plan de contrôle officiel, Chute prend également en charge les serveurs de contrôle auto-hébergés Headscale / Ionscale. Il suffit d'indiquer l'URL correspondante :

[Tailscale]
auth-key = your-headscale-preauth-key
control-server = https://headscale.example.com
hostname = my-device

Les serveurs de contrôle tiers n'imposent pas le préfixe tskey- et acceptent leurs propres clés d'authentification. L'utilisation d'une adresse http:// en clair n'est recommandée que sur un réseau de confiance (par ex. un Headscale auto-hébergé localement).

Limitations connues et bonnes pratiques

L'implémentation de Tailscale se concentre sur les capacités les plus utilisées dans un contexte de proxy ; certaines fonctionnalités du client officiel ne sont pas encore prises en charge. Notez les différences de comportement suivantes :

1. N'utilisez force-derp = true que comme option de dépannage. Chute privilégie normalement les connexions UDP directes (traversée de NAT « disco »), qui offrent en général une latence plus faible et un meilleur débit qu'un relais DERP. Si les connexions directes sont systématiquement instables ou plus lentes que DERP sur un réseau donné, comparez les deux modes et n'activez force-derp que pour cet environnement.

2. Seule la connexion par clé d'authentification est prise en charge. La connexion SSO / interactive par navigateur, Tailscale SSH, Taildrop et Funnel / serve ne sont pas pris en charge. Sur iOS, tvOS et Android, Chute ne peut pas annoncer de routes de sous-réseau locales ni proposer l'appareil comme nœud de sortie — ces plateformes rejoignent le tailnet uniquement en consommatrices ; sur macOS, les deux sont pris en charge, voir « Servir de nœud de sortie (macOS) » ci-dessus.

3. Le DNS système reste local lors de l'utilisation d'un nœud de sortie, mais les noms d'hôte joints via TAILSCALE sont résolus par le nœud de sortie. Les noms MagicDNS sont résolus localement à partir de la carte du tailnet. Pour les connexions acheminées par le nœud de sortie, les noms d'hôte sont résolus par le DNS du nœud de sortie (peerapi ExitDNS, ou le résolveur défini via exit-dns) ; définissez exit-dns = off pour conserver une résolution locale. Les résolveurs globaux et les résolveurs split-DNS distants ne sont pas pris en charge.

4. MagicDNS ne prend en charge que les enregistrements A / AAAA. Les résolveurs globaux, les routes split-DNS (entrées dotées de résolveurs dédiés) et les ExtraRecords qui ne sont pas des adresses (TXT / CNAME / SRV) sont ignorés ; un avertissement est consigné en cas de détection.

5. Le MTU interne du chemin direct est fixé à 1280. Il n'y a pas de découverte du MTU de chemin ; cette valeur prudente évite les trous noirs sur les liaisons PPPoE / à tunnels empilés. Le chemin par relais DERP n'est pas concerné.

6. Tailnet Lock (verrouillage réseau) n'est pas pris en charge. Dans un tailnet où le verrouillage réseau est activé, la clé de ce nœud ne sera pas signée, et les pairs verrouillés rejetteront silencieusement le trafic de cet appareil.

7. La réécriture de l'adresse source est implémentée ; les nœuds de sortie Mullvad restent non testés. Les adresses de masquage capVer-104 qu'un pair peut attribuer (SelfNodeV4MasqAddrForThisPeer et son équivalent v6) sont respectées : le trafic vers un tel pair porte donc l'adresse demandée. Le dispositif Mullvad bâti par-dessus n'a pas été éprouvé face au service réel.

8. La reprise après un changement de réseau dépend d'une notification système. Lors d'un basculement Wi-Fi / cellulaire, Chute reconstruit rapidement les connexions ; dans le cas rare où la notification de changement de réseau n'est pas reçue, la reprise s'appuie sur la reconnexion déclenchée par le chien de garde au bout d'environ 3 minutes.

9. Le nombre de pairs est plafonné sur mobile. Sous iOS, tvOS et Android, une netmap est réduite à 256 pairs — les pairs aux node ID les plus bas sont conservés, les autres sont abandonnés avec un seul avertissement ; macOS les garde tous.