- Tailscale Peer Relays est une nouvelle fonctionnalité de relais de trafic qui remplace les serveurs DERP existants, avec une architecture que les utilisateurs peuvent déployer et administrer eux-mêmes
- Chaque nœud peut jouer le rôle de relais en n’ouvrant qu’un seul port UDP, et la fonctionnalité peut être activée simplement car elle est intégrée au client Tailscale
- Elle prend en charge des connexions à haute vitesse et à haut débit, offrant des performances proches d’une connexion directe même derrière un NAT cloud ou un pare-feu
- Tout le trafic conserve un chiffrement de bout en bout basé sur WireGuard®, avec prise en charge du fallback automatique vers DERP et les DERP personnalisés
- Le service est actuellement disponible en bêta publique, avec jusqu’à 2 Peer Relays gratuits sur toutes les offres
Présentation de Tailscale Peer Relays
- Tailscale Peer Relays est un mécanisme de relais de trafic administré par l’utilisateur pouvant remplacer les serveurs DERP managés de Tailscale
- N’importe quel nœud Tailscale peut être configuré comme relais et acheminer le trafic entre les nœuds d’un même tailnet
- Un relais ne peut acheminer que les nœuds du tailnet auquel il appartient
- Comme il est administré directement par le client, il offre moins de contraintes de débit que DERP et de hautes performances même dans des infrastructures cloud fermées ou derrière des pare-feu
- Lors des premiers tests avec des partenaires, il a atteint un débit proche d’une connexion directe, avec des performances des dizaines de fois supérieures au DERP existant
Surmonter les environnements Hard NAT
- Tailscale applique des techniques avancées de traversée de NAT afin de maintenir autant que possible des connexions directes (plus de 90 %) même dans des environnements NAT
- Toutefois, dans certains environnements cloud, une connexion directe peut être impossible ou inefficace
- Le DERP existant fournit une connectivité stable, mais ses contraintes de QoS et ses limites de performance posent des difficultés dans certains contextes de déploiement
- Peer Relays a été conçu comme un outil de connectivité axé sur la performance, avec une communication UDP à faible latence et une architecture intégrée au client facilitant le déploiement
- Les clients peuvent déployer eux-mêmes des relais pour construire un réseau très performant et très flexible
Fonctionnement
- Peer Relay utilise un port UDP unique accessible depuis les deux nœuds
- Il peut être activé simplement avec la commande CLI
tailscale set --relay-server-port
- Lorsqu’une connexion directe est impossible, le système bascule automatiquement selon l’ordre Peer Relay → DERP (managé ou personnalisé)
- Toutes les connexions sont protégées par le chiffrement WireGuard®
- Il est possible de limiter les exceptions de pare-feu tout en n’autorisant que le trafic interne au tailnet
- La solution prend en charge l’extensibilité interrégionale, la tolérance aux incidents réseau et le fallback automatique vers DERP
Divers scénarios d’usage
- Relais à haut débit pour le trafic ne pouvant pas établir de connexion directe dans des environnements NAT cloud (comme AWS Managed NAT Gateway)
- Dans des environnements à pare-feu strict, un seul port UDP à ouvrir permet d’accélérer les procédures d’approbation
- Réduction de la charge sur le réseau DERP et suppression du besoin de maintenir un DERP personnalisé
- Lors de l’accès à des réseaux clients fermés, ouverture du minimum de ports via des endpoints prévisibles
- En pratique, les clients utilisent Peer Relay pour mettre en place l’accès à des réseaux non administrés, le contrôle des chemins de connexion partenaires et des architectures réseau granulaires basées sur le peering VPC
Bêta publique et politique de disponibilité
- Tailscale Peer Relays est disponible immédiatement en bêta publique
- Des travaux sont en cours pour améliorer certaines fonctions de visibilité et de débogage
- Les premiers partenaires ont validé une mise en place simple et des performances stables
- Jusqu’à 2 Peer Relays sont inclus gratuitement dans toutes les offres, y compris la formule gratuite, et des relais supplémentaires peuvent être ajoutés
- Si davantage de relais sont nécessaires, il est possible d’étendre le déploiement en contactant l’équipe commerciale de Tailscale
1 commentaires
Commentaires Hacker News
Je trouve cette fonctionnalité vraiment pertinente
La structure n’utilise un nœud intermédiaire que lorsqu’une connexion directe est impossible, et le trafic reste chiffré de bout en bout
C’est similaire au fait d’exploiter soi-même un serveur DERP, mais sans avoir à ouvrir de ports, tout en réduisant l’usage des relais de Tailscale, donc aussi les coûts de bande passante
En revanche, je me demande pourquoi l’utilisation de plus de deux relais est payante
Sinon, on pourrait se dire qu’on n’a peut-être pas besoin de tailscale au départ
Il existe toutefois des cas où deux clients peuvent accéder au relais sans pouvoir se connecter directement entre eux
L’ancien tinc résolvait déjà ce problème
Tous les nœuds pouvaient servir de relais, et cela fonctionnait comme un vrai réseau maillé sans serveur central
Au lieu de tout réimplémenter, il vaudrait mieux à mon avis le porter sur WireGuard avec un langage memory-safe
Il arrive fréquemment que la route tombe juste après l’établissement d’une connexion SSH
Comme le trafic est déchiffré puis rechiffré sur le nœud relais, il faut utiliser un protocole expérimental pour avoir du chiffrement de bout en bout
J’aimerais le réécrire sur la base du protocole cjdns, mais ce n’est pas simple
La nouvelle fonction Peer Relay de Tailscale ressemble à ce que ZeroTier faisait déjà auparavant
Ça me paraît difficile de prétendre que c’est une « fonctionnalité propre à Tailscale », et je trouve excessive une facturation supplémentaire en plus du prix par utilisateur
En revanche, son propre système de chiffrement, la baisse de performances en mono-thread et la lenteur du développement posaient problème
J’ai testé plusieurs alternatives, mais je n’ai encore rien vu qui réunisse à la fois les fonctionnalités et les performances de Tailscale
Ça me fait penser à une comparaison du style « pourquoi utiliser Dropbox alors qu’il y a FTP ? »
Je me demande s’il est possible de spécifier directement des adresses IPv4/IPv6 externes
Par exemple quand le trafic entrant et sortant utilise des adresses différentes, ou quand le pare-feu n’autorise qu’une partie des adresses parmi plusieurs connexions Internet
J’ai configuré headscale et split horizon SSL la semaine dernière, avant de découvrir au final que seul DERP était possible
Je pense qu’il vaut mieux exposer directement un port UDP sur le réseau local
Si la sécurité du client WireGuard est suffisamment éprouvée, c’est plus pratique
J’aimerais savoir si tu essayais d’ouvrir directement le port WireGuard, ou si tu parlais du port Tailscale
Si on utilise cette fonctionnalité à la place de DERP, ça ne fonctionne pas dans le navigateur
C’est parce que ça repose sur de l’UDP natif
Je me demande si cela pourra être implémenté plus tard via WebTransport
Mais cela ne résout pas les problèmes de traversée de NAT
Je suis aussi de près les avancées de QAD chez Iroh
Si tout s’aligne bien, on pourrait obtenir un réseau encore plus magique
Je me demande si, à l’étape suivante, tous les clients tailscale pourraient accepter automatiquement les demandes de transfert, afin que le réseau maillé se répare tout seul sans interruption
Mais la vraie question est de savoir s’il faut autoriser ou non le relais du trafic d’autres personnes
Avec Tailscale, il est possible de connecter des services entre eux, mais si Tailscale tombe en panne, est-ce que la communication entre mes propres services s’interrompt aussi ?
Il était impossible de se reconnecter faute d’accès à tailscale
Du coup, je prévois maintenant de déployer moi-même headscale
Le fait que même les appareils du LAN local ne puissent plus communiquer était assez absurde
J’ai bricolé tout le week-end une solution temporaire pour un Kubernetes Operator, et maintenant je vais pouvoir tout retirer grâce à cette fonctionnalité
Vraiment bravo
Je me demandais quel était le cas d’usage de cette fonctionnalité
Quand un produit SaaS a besoin de données provenant du système d’un client, on dirait que le client peut exposer ses données via un relais pour l’intégration
Il faudra quand même sans doute un logiciel pour l’authentification, la journalisation, etc.
Comme le contournement du NAT échoue souvent, DERP est fréquemment utilisé, mais il est lent
Désormais, on peut désigner comme relais un pair du réseau qui dispose d’une bonne connectivité, afin d’aller plus vite
Ce n’est pas tant un nouveau cas d’usage qu’une amélioration des performances du DERP existant
Au lieu d’une architecture hub-and-spoke traditionnelle, elle privilégie une architecture P2P où tous les nœuds se connectent directement en UDP/IP quand c’est possible
Mais à cause du NAT et des pare-feu, les connexions directes échouent souvent, et DERP sert alors de relais
DERP était lent et les utilisateurs n’avaient aucun moyen d’en améliorer les performances, alors qu’avec ce Peer Relay, ils peuvent désormais exploiter leur propre relais
Si l’emplacement est bien choisi, cela peut aussi réduire la latence
Bien sûr, ce n’est pas une fonctionnalité nécessaire pour tous les utilisateurs