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 unique 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.

Paramètres

Clé Requis Description
auth-key Oui Clé d'authentification Tailscale. Doit commencer par tskey- avec le plan de contrôle officiel ; les serveurs de contrôle tiers (par ex. Headscale) acceptent leurs propres formats de clé
control-server Non Adresse du serveur de contrôle, doit être une URL http(s)://. Laissez vide pour utiliser le plan de contrôle officiel controlplane.tailscale.com
hostname Non Nom d'appareil signalé au tailnet (nom d'hôte MagicDNS)
exit-node Non Nœud de sortie ; accepte une IP de tailnet (100.x) ou un nom MagicDNS. Laissez vide pour aucun nœud de sortie
accept-routes Non Accepter ou non les routes de sous-réseau annoncées par les pairs (booléen, par défaut false)
force-derp Non Forcer ou non le relais DERP uniquement et désactiver les connexions directes (booléen, par défaut false)
direct-quality-guard Non Surveiller la qualité du chemin direct et basculer proactivement vers DERP lorsqu'elle se dégrade (booléen, par défaut false). Lorsque cette option est désactivée, la qualité du chemin est seulement enregistrée
peer-relay Non Activer la découverte de candidats relais entre pairs et utiliser ces relais comme chemin supplémentaire (booléen, par défaut false, expérimental)
exit-dns Non DNS utilisé pour les noms d'hôte joints via le nœud de sortie : auto (valeur par défaut lorsqu'un nœud de sortie est défini — résolution par le DNS du nœud de sortie), off, ou une IP de serveur DNS littérale joignable via le nœud de sortie
advertise-exit-node Non Proposer cet appareil au tailnet comme nœud de sortie (booléen, par défaut false). macOS uniquement — ignoré avec un avertissement sur iOS/tvOS
advertise-routes Non Sous-réseaux locaux que cet appareil propose de router pour le tailnet, sous forme de liste CIDR séparée par des virgules (par exemple 192.168.1.0/24, 10.0.0.0/8). macOS uniquement

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 (échec fermé).

[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

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é ; l'éditeur de configuration de l'app le signale.

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 et tvOS 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 Réglages → Tailscale → Servir de nœud de sortie pour les autres appareils, 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 (perçage de trous « 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 et tvOS, 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 non adressables (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 conservatrice é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 sortie Mullvad et les autres scénarios de réécriture de source sont indisponibles. Les fonctionnalités de nœud de sortie qui exigent de réécrire l'adresse source locale ne sont pas encore implémentées.

  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 une reconnexion de surveillance au bout d'environ 3 minutes.

S. Smart Rabbit LLC © All Rights Reserved            updated 2026-08-19 16:30:52

results matching ""

    No results matching ""