Headscale - implémentation open source auto-hébergée du serveur de contrôle de Tailscale

 (github.com/juanfont)
2 points par GN⁺ 2025-04-04 | 1 commentaires | Partager sur WhatsApp
  • Headscale est un projet qui implémente le serveur de contrôle de Tailscale en open source et en auto-hébergement, avec pour cible les self-hosters et les environnements de projet ou de labo de développeurs hobbyistes
  • Tailscale est un VPN moderne basé sur WireGuard, qui fonctionne comme un réseau superposé entre les ordinateurs d’un réseau grâce au NAT traversal
  • Le serveur de contrôle de Tailscale gère l’échange des clés publiques WireGuard des nœuds, l’attribution des IP clientes, la création de frontières entre utilisateurs, le partage de machines entre utilisateurs et l’exposition des routes annoncées par les nœuds
  • Headscale fournit une implémentation volontairement limitée d’un réseau Tailscale unique (tailnet), adaptée à un usage personnel ou à de petites organisations open source
  • Le projet n’est pas lié à Tailscale Inc. et ne prend pas en charge ni ne recommande l’utilisation de reverse proxies et de conteneurs pour exécuter Headscale

Objectif et périmètre de Headscale

  • Headscale vise à être une alternative open source, auto-hébergeable, au serveur de contrôle de Tailscale
  • Les utilisateurs visés sont les self-hosters, les développeurs hobbyistes et les personnes qui utilisent des projets personnels ou des environnements de labo
  • Le périmètre d’implémentation est volontairement restreint et fournit un tailnet unique
    • Adapté à un usage personnel
    • Adapté aussi à de petites organisations open source

Tailscale et le rôle du serveur de contrôle

  • Tailscale est un VPN moderne construit sur WireGuard
  • Tailscale fonctionne comme un réseau superposé entre les ordinateurs d’un réseau, en utilisant le NAT traversal
  • Dans Tailscale, tous les éléments sont open source à l’exception d’une partie des clients GUI et du serveur de contrôle
    • Les clients GUI cités en exception sont ceux destinés à des OS propriétaires comme Windows et macOS/iOS
  • Le serveur de contrôle sert de point d’échange des clés publiques WireGuard entre les nœuds du réseau Tailscale
    • Il attribue les adresses IP clientes
    • Il crée des frontières entre utilisateurs
    • Il permet le partage de machines entre utilisateurs
    • Il expose les routes annoncées par les nœuds
  • Le réseau Tailscale, c’est-à-dire le tailnet, est un réseau privé attribué par Tailscale à un utilisateur individuel ou à une organisation

Documentation et précautions de version

Exécution et build

  • L’exécution de Headscale avec des reverse proxies et des conteneurs n’est ni prise en charge ni recommandée
  • Pour savoir comment l’exécuter, il faut se référer à la documentation officielle
  • Un module pour les utilisateurs de NixOS se trouve dans le répertoire nix/
  • Des builds de développement de la branche main sont fournis sous forme d’images de conteneur et de binaires

Relation du projet et contribution

  • Ce projet n’a aucun lien avec Tailscale Inc.
  • L’un des mainteneurs principaux actifs de Headscale est employé par Tailscale et peut contribuer au projet sur son temps de travail
    • Les contributions de ce mainteneur sont relues par d’autres mainteneurs
  • Les mainteneurs définissent ensemble l’orientation du projet selon le principe de construire un projet durable tout en soutenant la communauté des self-hosters, des utilisateurs passionnés et des développeurs hobbyistes
  • Les contributeurs doivent lire CONTRIBUTING.md

Environnement de développement et workflow

  • Contribuer nécessite une version récente de Go et de Buf
    • Buf est utilisé comme générateur Protobuf
  • Il est recommandé d’utiliser Nix pour configurer l’environnement de développement
    • Exécuter nix develop installe les outils nécessaires et fournit un shell
    • Cette méthode garantit le même environnement de développement que celui des mainteneurs de Headscale
  • Le code Go est linté avec golangci-lint et formaté avec golines et gofumpt
    • La largeur de ligne de golines est définie à 88
    • Il est recommandé d’exécuter make lint et make fmt avant de commit
  • Le code Proto est linté avec buf et formaté avec clang-format
  • La documentation est formatée avec mdformat, et les autres fichiers comme Markdown et YAML avec prettier
  • En cas de modification de proto/, il faut régénérer le code Go à partir des Protobuf
    • La commande est make generate
    • Il est recommandé de placer les modifications de gen/ dans un commit séparé pour faciliter la revue
  • Les tests et le build s’exécutent respectivement avec make test et make build
  • Le workflow recommandé consiste à exécuter make test, puis make build, après nix develop
    • Si vous gérez les dépendances vous-même, vous pouvez utiliser Make directement
    • Le Makefile avertit si des outils nécessaires sont absents et suggère d’exécuter nix develop
    • Les cibles disponibles peuvent être consultées avec make help

À lire aussi

1 commentaires

 
GN⁺ 2025-04-04
Avis de Hacker News

  • Tous les quelques mois, je reviens sur ce dépôt pour vérifier si Tailnet lock fonctionne enfin, et si quelqu’un a réalisé un audit de sécurité entre-temps
    Malheureusement, il semble qu’il n’y ait eu d’avancée sur aucun des deux points, ce qui me rend de plus en plus incertain quant au niveau de confiance que je peux accorder à ce projet comme composant central de mon infrastructure
    Le principe du SaaS Tailscale est de créer des tunnels qui contournent les pare-feu, puis de permettre à l’utilisateur de contrôler, de façon intuitive et intégrée, ce qui est routé via ces tunnels
    Headscale semble bien gérer le contournement des pare-feu et la traversée NAT avancée, mais je me demande s’il peut offrir sa propre sécurité au point de compenser celle que l’on vient justement de contourner
    Si l’utilisateur n’a aucun moyen de comprendre ou de refuser ce que le serveur de contrôle ordonne aux clients de faire, et s’il n’existe aucun audit de sécurité du code serveur, cela paraît être un choix assez audacieux

    • Tailnet lock semble beaucoup moins important dans Headscale que dans Tailscale, puisqu’on contrôle soi-même l’infrastructure Headscale
    • Je me demande si Headscale implémente réellement ces fonctionnalités lui-même
      Je pensais qu’il s’agissait d’une couche de contrôle par-dessus les services backend de base de Tailscale ; est-ce qu’il négocie les connexions d’une nouvelle manière ?
      J’utilise assez souvent ZeroTier, mais je connais moins Tailscale, donc la question est peut-être évidente
    • L’un des mainteneurs travaille désormais chez Tailscale
    • À ce sujet, voir https://github.com/juanfont/headscale/issues/2416

  • Si vous vous intéressez aux serveurs d’orchestration auto-hébergés, Netbird vaut aussi le détour
    C’est un outil similaire, dont le serveur est également open source, avec une bonne GUI pour le serveur de contrôle auto-hébergé et des fonctionnalités proposées dans la version payante
    https://netbird.io/knowledge-hub/tailscale-vs-netbird

    • Comparé à Headscale, Netbird comporte vraiment beaucoup de pièces mobiles
      Il semble robuste, puissant et riche en fonctionnalités, mais Headscale auto-hébergé est bien plus simple et a moins d’exigences
    • Je migre progressivement de Tailscale vers Netbird, et cela fonctionne très bien, à part le comportement un peu absurde de Tailscale qui s’approprie toute la route CGNAT
      Pour l’instant, je continue aussi à faire tourner Tailscale, mais je m’approche de plus en plus du moment où je le supprimerai pour passer entièrement à Netbird
    • J’aimerais utiliser Netbird, mais il n’a pas encore de fonctionnalité intégrable dans un binaire Go comme tsnet de Tailscale
      L’issue GitHub correspondante est ici
      https://github.com/netbirdio/netbird/issues/1103
    • L’absence d’IPv6 est vraiment rédhibitoire : https://github.com/netbirdio/netbird/issues/46
    • Je me demande si Netbird fournit une traversée NAT aussi sophistiquée que Tailscale

  • Ce serait bien de mettre Headscale, le nom du projet, dans le titre
    Headscale est un projet qui est déjà passé plusieurs fois sur HN

  • Ce serait chouette que Headscale prenne en charge le peering/la fédération entre instances. Peut-être après la refonte des ACL
    L’un des principaux problèmes est le conflit d’adresses
    Voici la proposition : définir un réseau overlay exclusivement IPv6 dans la plage des adresses locales uniques (ULA), puis répartir les 121 bits restants entre les 20 bits de poids faible pour l’adresse de l’appareil (environ un million) et les 101 bits de poids fort comme hash de la clé publique du serveur
    Il suffirait d’ajouter la clé publique d’autres instances pour les fédérer, puis de gérer les communications entre nœuds avec des politiques et des ACL
    Je pense que c’est une bonne idée, mais lorsque je l’ai évoquée en 2023, le mainteneur kradalby a dit que c’était hors périmètre : https://github.com/juanfont/headscale/issues/1370

  • J’utilise Headscale avec succès depuis six mois
    C’est tellement bien que je ne sais plus comment je faisais auparavant sans réseau Tailscale
    Il est packagé pour OpenBSD, et j’utilise ce paquet comme serveur

  • J’aime Headscale, et je viens de le mettre en production : il fonctionne très bien

    • J’exploite Headscale depuis 2,5 ans, et c’est plutôt satisfaisant
      Pour la connexion, nous utilisons un domaine Gmail, avec le gros avantage que les utilisateurs peuvent enregistrer eux-mêmes leurs appareils
      Avec l’ancien OpenVPN, l’équipe d’exploitation devait transmettre elle-même les certificats et les configurations
      Le seul inconvénient, c’est que des utilisateurs se connectent par erreur au serveur de login de Tailscale au lieu de notre propre serveur, puis ne comprennent pas pourquoi ils n’arrivent pas à accéder aux services
      Nous configurons les services accessibles par groupes d’utilisateurs
      Nous utilisons encore une ancienne version de Headscale, car certaines intégrations doivent être portées vers le nouveau plan de contrôle
      D’après headscale node list | wc, nous avons environ 250 nœuds, principalement des serveurs
      Je n’aime pas trop la façon dont Tailscale modifie comme par magie la table de routage et les règles de pare-feu, mais dans l’ensemble cela n’a pas vraiment posé problème et a plutôt bien fonctionné
    • Je me demande si cela veut dire que vous l’avez déployé comme service interne pour toute l’entreprise

  • Dans plusieurs cas d’usage, par exemple l’accès mobile ou l’interface graphique macOS, il faut que le client Tailscale officiel conserve la possibilité de configurer le serveur de contrôle pour pouvoir utiliser Headscale.
    Cette fonctionnalité disparaîtra dès que la dégradation inévitable de la qualité commencera chez Tailscale.
    Je dis ça en tant que client aujourd’hui très satisfait de Tailscale, mais aussi comme quelqu’un qui s’est déjà fait avoir plusieurs fois par le passé quand d’autres entreprises ont été rachetées ou ont épuisé leur financement en capital-risque.

    • À l’exception des parties GUI des systèmes d’exploitation non open source, la plupart des clients Tailscale ne sont-ils pas open source ?
    • Si je me souviens bien, Tailscale a dit quelque part que Headscale avait même un effet positif sur le chiffre d’affaires.
      Ça se tient. Headscale est surtout utilisé par des homelabers et de petits utilisateurs hobbyistes, et il concurrence OpenVPN ou WireGuard auto-hébergés plutôt que Pulsesecure, Cisco Anyconnect ou GlobalProtect.
      C’est une porte d’entrée vers Tailscale pour des gens qui aiment les nouvelles technologies sur leur temps libre, mais ne veulent pas abandonner le contrôle de leur infrastructure.
      Ces personnes apportent ensuite leur expertise et leur enthousiasme pour Tailscale au travail.
      Les entreprises n’ont généralement pas très envie de gérer leur infrastructure IT, sauf si c’est une compétence cœur de métier.
      Bien sûr, certaines entreprises choisiront Headscale plutôt que le produit Tailscale lui-même, mais au vu de leur taille et des montants en jeu, elles seront probablement peu nombreuses.
      Ça ressemble plutôt à un coût d’acquisition, pas très différent de publicités Facebook ou de panneaux publicitaires au bord des routes dans la Silicon Valley.
    • Ce qui me déplaît le plus dans Tailscale, c’est le client, en particulier la consommation de batterie du client mobile.
      La raison pour laquelle nous ne pouvons pas utiliser Tailscale au travail, c’est que le trafic est routé via des serveurs que nous ne contrôlons pas.
      J’aimerais vraiment utiliser Tailscale au travail, et cela résoudrait beaucoup de problèmes.
      S’il faut ouvrir un port, je peux l’accepter, mais tunneliser du trafic via ce port m’inquiète beaucoup.

  • Ça a l’air intéressant. Je me demande quelle valeur ajoutée cela apporte par rapport à une configuration WireGuard + OpenWrt.

    • Les appareils se connectent entre eux en pair à pair, même derrière des NAT complexes, sans configuration manuelle.
      Le tout fonctionne simplement, avec les contraintes d’ACL gérées de façon centralisée.
      Certains réduisent Tailscale à « juste un orchestrateur WireGuard », mais en réalité c’est bien plus que ça.
      Du point de vue produit, WireGuard n’est qu’un détail d’implémentation.
    • Comme c’est un VPN maillé, les pairs communiquent directement, donc il n’y a pas de latence supplémentaire.
      J’avais choisi Netbird à l’époque parce que l’interface de Headscale me semblait trop rudimentaire, mais elle s’est peut-être améliorée depuis quelques années.
    • La proposition de valeur de Tailscale, c’est WireGuard que même une personne assez à l’aise techniquement peut configurer et gérer seule.
      Ça fonctionne sur une multitude de clients, et mes Apple TV sont aussi connectées à mon réseau Tailscale.
      La configuration m’a pris environ une minute, et elles peuvent aussi servir de passerelle.
    • Certaines personnes n’ont pas d’IP fixe ou ne veulent pas qu’un service écoute sur leur réseau domestique.
      Avec Tailscale, ou Headscale hébergé à l’extérieur, c’est possible.

  • Je me demande à quel point mes appareils seraient exposés si le serveur de coordination Tailscale était compromis et que Tailnet lock était activé.