Tailscale Peer Relays : utiliser ses propres appareils comme relais haut débit

• Tailscale Peer Relays est désormais disponible en version générale, permettant aux utilisateurs d’exploiter leurs propres appareils comme nœuds de relais haute performance
• Prend en charge un relais de trafic stable et rapide même dans des environnements où une connexion directe est difficile à établir en raison des pare-feu, du NAT ou des contraintes des réseaux cloud
• Les améliorations de débit, la réduction de la contention sur les verrous et la répartition de charge sur les sockets UDP améliorent fortement les performances lors de connexions de nombreux clients
• Grâce à l’intégration des endpoints statiques, il est possible d’exploiter un relais derrière un AWS NLB ou équivalent même dans des environnements cloud où la découverte automatique est impossible
• L’intégration de la visibilité et du monitoring permet de comprendre clairement les chemins de trafic, la latence et l’état des relais, un point essentiel pour l’exploitation de grands réseaux

---

Présentation de Tailscale Peer Relays

• Peer Relays est une fonctionnalité qui permet d’exécuter une fonction de relais haute performance sur ses propres appareils
  • En plus des relais DERP existants, il est possible d’utiliser comme relais des nœuds déployés directement par l’utilisateur
  • Depuis la bêta, les performances, la stabilité et la visibilité ont fortement progressé, jusqu’à atteindre un niveau prêt pour la production
• À l’origine conçu pour contourner des environnements NAT complexes, le système s’est étendu pour devenir une option de connectivité pour les réseaux à grande échelle
  • Il offre aux équipes une architecture apportant performances, contrôle et flexibilité

Améliorations des performances et de la fiabilité

• Quand de nombreux clients se connectent via un relais, le débit augmente nettement
  • Les clients sélectionnent automatiquement l’interface et la famille d’adresses les plus adaptées au sein du relais
  • Le relais améliore l’efficacité du traitement des paquets grâce à une réduction de la contention sur les verrous et à une répartition sur plusieurs sockets UDP
• Grâce à ces améliorations, les performances et la stabilité progressent aussi sur le trafic quotidien, et même lorsque la connexion directe est impossible, le système offre des performances proches d’un réseau mesh

Prise en charge des endpoints statiques

• Dans les environnements de cloud public, la découverte automatique des endpoints est souvent difficile
  • Les règles de pare-feu, le port forwarding ou les load balancers peuvent empêcher l’ouverture de ports arbitraires
• Peer Relays peut annoncer des paires IP:port fixes via le flag --relay-server-static-endpoints
  • Même derrière une infrastructure comme AWS Network Load Balancer, des clients externes peuvent transmettre du trafic via le relais
• Cette fonctionnalité permet d’assurer des connexions rapides même dans des environnements cloud contraints et rend possible une topologie full mesh en remplaçant les subnet routers

Intégration de la visibilité et du monitoring

• Peer Relays est directement intégré aux outils d’observabilité de Tailscale, ce qui permet de comprendre clairement le fonctionnement des relais
  • La commande tailscale ping permet de vérifier si un relais est utilisé, sa joignabilité, ainsi que son impact sur la latence et la fiabilité
  • En cas de problème, on peut déterminer immédiatement si le trafic passe par un relais et si ce relais fonctionne normalement
• Les métriques de monitoring fournies incluent tailscaled_peer_relay_forwarded_packets_total et tailscaled_peer_relay_forwarded_bytes_total
  • Elles peuvent être intégrées à Prometheus, Grafana et d’autres outils pour analyser les patterns de trafic, détecter les anomalies et surveiller l’état du réseau

Disponibilité générale et mode de déploiement

• Désormais disponible en version générale, Peer Relays s’impose comme un élément clé de la scalabilité de Tailscale
  • Fournit des connexions rapides et à faible latence lorsqu’un chemin direct est impossible
  • Fonctionne même dans des environnements cloud restreints grâce à des déploiements basés sur des endpoints statiques
  • Prend en charge une topologie full mesh dans des sous-réseaux privés ainsi que la configuration de chemins de contrôle d’entrée et de sortie
• Les principes de sécurité de base de Tailscale sont conservés, notamment le chiffrement de bout en bout, l’accès au moindre privilège et un comportement prévisible
• L’activation est possible via la CLI sur tous les nœuds pris en charge, avec prise en charge du contrôle basé sur les ACL et d’un déploiement progressif
• Peer Relays est disponible sur toutes les offres, y compris l’offre gratuite Personal

[GN⁺]

Réactions sur Hacker News

• Si Tailscale inspire confiance parce qu’il est « open », il faut aussi savoir que certains clients sont propriétaires
  Ils ne sont distribués que via des canaux officiels (par ex. l’Apple App Store) et restent entièrement sous leur contrôle
  La logique avancée pour justifier cela est absurde : en gros, « si l’utilisateur accepte un OS propriétaire, alors Tailscale peut aussi être propriétaire »
  Une telle structure est difficile à considérer comme fiable dans des environnements à connectivité restreinte
  Même si c’est techniquement meilleur que la concurrence, ça reste avant tout un business. Il faudrait soutenir des alternatives libres quand c’est possible
  Issue GitHub liée

  • Je veux préciser que, sur certaines plateformes, seule l’interface graphique est propriétaire (Tailscalar)
  • J’accorde plus d’importance au contrôle qu’aux performances
    Si l’utilisateur peut compiler depuis les sources, il peut aussi améliorer les performances, mais sans contrôle, il n’y a aucun moyen de corriger ce qui ne convient pas
    Les logiciels commerciaux sont souvent de qualité médiocre, dépendent trop des mises à jour et privilégient la vitesse de sortie à la finition
  • Le client CLI pour macOS peut être compilé directement depuis les sources
    Il s’installe avec la commande go install tailscale.com/cmd/tailscale{,d}@latest, décrite dans le wiki officiel
    L’interface graphique est propriétaire, mais le CLI est entièrement ouvert, donc utilisable même dans des environnements réseau restreints
  • La plupart des applis Mac sont propriétaires, donc une simple icône Tailscale dans la barre de menus ne me dérange pas
    Si ça gêne vraiment, on peut passer par brew ou le CLI
  • Je pense que le modèle hybride entre open source et commercial est un compromis réaliste
    Je développe moi-même une appli sur une structure similaire : le CLI sera entièrement open source et l’interface graphique sera vendue
    C’est ce qui permet de continuer le développement et d’en vivre
    Je développe l’interface graphique et le CLI à partir de la bibliothèque validate

• J’ai configuré Tailscale récemment, et le ping est passé de 16 ms à 10 ms tandis que la bande passante a triplé
  Avec Moonlight/Sunshine, je peux streamer des jeux Windows depuis un desktop Linux vers un MacBook à 50 Mbps / 10 ms
  Je n’ai fait que configurer le routeur comme nœud pair, sans port forwarding

  • Pour Sunshine, ça vaut le coup d’essayer Apollo
  • Cas d’usage intéressant, mais en pratique cela revient à déléguer le NAT traversal et le port forwarding à un protocole automatisé
  • Si on veut exposer le streaming de jeux à des utilisateurs lambda, est-ce qu’ils doivent eux aussi installer Tailscale ?
    J’aimerais savoir si Tailscale est avant tout pensé pour le partage entre utilisateurs de confiance
  • J’avais tenté une config similaire avec un routeur OpenWRT, mais je croyais qu’il fallait quand même ouvrir des ports
    Du coup, je suis un peu perdu : est-ce que ça reste malgré tout exposé à Internet ?

• Je me demande quel est le modèle économique de Tailscale. J’aime bien le service, mais je m’interroge sur sa viabilité à long terme
  J’ai aussi parfois l’impression qu’il y a du rate limiting

  • Dans notre entreprise, nous utilisons le forfait Business à 18 $/utilisateur/mois
    Quand l’équipe grandit, un forfait payant devient indispensable, et des fonctions comme serve/funnel ou SSH sont utiles
    Avant, on utilisait Zerotier : on l’a eu gratuitement pendant des années, puis on a fini par payer environ 5 $ par mois quand le nombre d’utilisateurs a augmenté
  • En principe, Tailscale établit une connexion P2P WireGuard après la connexion initiale, donc il ne devrait pas y avoir de limitation de débit
    Cela dit, selon l’environnement réseau, un relais peut être nécessaire
    Comme alternatives open source, il y a Headscale et Netbird
  • On peut consulter l’explication du forfait gratuit sur le blog officiel
  • C’est un cas typique de modèle freemium : gagner en popularité avec un forfait gratuit pour développeurs, puis faire basculer les entreprises vers des offres payantes
  • Les connexions P2P coûtent très peu cher, donc la stratégie qui consiste à renforcer la fidélité des développeurs via la tier gratuite est efficace

• Le passage au Peer Relay est une grande victoire pour les auto-hébergeurs en environnement NAT
  Cela améliore l’UX puisqu’il n’est plus nécessaire de configurer soi-même un serveur DERP

  • (Alex, employé de Tailscale) Nous avons rencontré le même problème nous aussi
    Peer Relay a pu être mis en œuvre sans trop de charge en réutilisant l’infrastructure existante des subnet routers et exit nodes
    C’est indispensable pour assurer une connectivité stable dans des environnements NAT restrictifs comme AWS
    Au final, cela améliore à la fois la latence et l’expérience utilisateur
  • Il y avait un problème où le DERP central absorbait le trafic comme un trou noir, mais récemment c’est devenu stable
    Avec l’arrivée de Peer Relay, ce type de problème devrait encore diminuer

• Le point essentiel, c’est que Peer Relay prend en charge l’UDP
  DERP repose sur TCP, ce qui posait des problèmes de latence pour le game streaming ou la voix
  Peer Relay utilise l’UDP, donc c’est bien plus adapté au trafic temps réel
  Il peut être activé directement sur un subnet router existant, sans déployer une instance DERP séparée

  • En revanche, voir une série de commentaires positifs publiés par de nouveaux comptes, avec parfois des réponses d’employés de Tailscale, donne une impression de RP pilotée par l’IA
    Ce genre de commentaires générés par IA nuit à la confiance de la communauté, donc il faudrait éviter ça

• Lorsqu’il y a plusieurs relais, je me demande si Tailscale choisit automatiquement le nœud avec la plus faible latence

• En environnement CGNAT réel, Tailscale m’a beaucoup aidé
  Je fais tourner un système de vision par IA sur Google Cloud Run, et mon FAI bloquait le port forwarding
  Grâce à Tailscale, le conteneur Cloud Run et les caméras peuvent communiquer comme s’ils étaient sur le même LAN
  J’espère que Peer Relay réduira aussi les problèmes de latence qui apparaissaient quand le conteneur redémarrait souvent
  En revanche, je me demande comment fonctionne le choix du relais dans un environnement de nœuds éphémères

• J’utilise déjà un réseau WireGuard configuré à la main, et je me demande ce que Tailscale fait exactement en interne
  Toutes ces fonctions « magiques » qui ajustent automatiquement le DNS, le routage, le pare-feu, etc., me rendent méfiant
  J’ai lu la documentation officielle, mais elle manque de détails
  J’aimerais savoir si ça fonctionne bien même avec des configurations réseau complexes

  • (Employé de Tailscale) Il est difficile de maintenir une documentation parfaite, mais nous essayons de documenter autant que possible les heuristiques d’adaptation à l’environnement
    Sous Linux, il existe de nombreux schémas de configuration, ce qui complique les choses
    C’est aussi expliqué dans ce billet de blog lié
    Le comportement principal est le suivant
    • Routage basé sur des règles pour éviter les conflits
    • Intégration prioritaire avec systemd-resolved, sinon modification de /etc/resolv.conf
    • Prise en charge d’iptables et de nftables, avec une configuration compatible avec ufw/firewalld
    • Implémentation de la connexion SSH la plus compatible possible, en tenant compte des différences entre distributions
    • Besoin d’un chemin MTU de 1360 octets pour une communication stable
      Dans des environnements très personnalisés, des problèmes peuvent survenir, mais le support peut aider à les résoudre
  • Le client est open source, et certains employés contribuent aussi à des serveurs issus de rétro-ingénierie comme Headscale
  • Headscale est une alternative open source à considérer

• J’ai ouvert la page sur mobile, mais je ne voyais pas le bouton de fermeture, donc impossible de fermer la modale
  Voir cette capture d’écran
  Je l’ai finalement trouvé plus tard, mais son emplacement était étrange

  • Le bouton de fermeture est le X blanc dans le carré bleu en bas à droite de la modale