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

• Headscale est un projet alternatif open source conçu pour auto-héberger les fonctions du serveur de contrôle de Tailscale
• Tailscale est une solution VPN moderne basée sur WireGuard, permettant de construire un réseau overlay fonctionnant même dans des environnements NAT
• Le serveur de contrôle Tailscale d’origine est un logiciel propriétaire, tandis que Headscale a été développé comme un logiciel serveur librement installable pouvant le remplacer
• Les clients Windows, macOS et iOS nécessitent toujours l’interface graphique de Tailscale

Objectif et caractéristiques de Headscale

• Headscale ne prend en charge qu’un seul tailnet (réseau privé virtuel), afin de convenir à une utilisation personnelle et aux petites organisations open source
• Une solution adaptée aux utilisateurs souhaitant exploiter leur propre serveur et aux adeptes du logiciel libre
• Son périmètre de conception volontairement restreint facilite la maintenance et l’administration

Fonctionnalités principales

• Échange de clés publiques WireGuard entre les nœuds clients
• Attribution des adresses IP et définition des limites pour chaque nœud
• Fonction de partage de machines entre utilisateurs
• Gestion des annonces de routes des nœuds
• La liste officielle des fonctionnalités est disponible ici

Systèmes d’exploitation clients pris en charge

• La liste des systèmes d’exploitation et des clients compatibles avec Headscale est disponible dans la documentation officielle

Installation et exécution

• L’utilisation d’un reverse proxy ou d’une exécution basée sur des conteneurs n’est pas officiellement recommandée
• Pour les méthodes d’exécution et la configuration, voir la documentation officielle

Communauté et contributions

• La communauté d’utilisateurs et de développeurs est active sur le canal Discord
• Il est impératif de lire CONTRIBUTING.md avant de contribuer

Environnement de développement et style de code

• Principaux outils nécessaires au développement :
  • La dernière version de Go
  • Buf (générateur Protobuf)
  • Possibilité de configurer l’environnement de développement avec Nix (nix develop)
• Style de code :
  • Code Go : utilisation de golangci-lint, golines, gofumpt
  • Code Proto : utilisation de buf, clang-format
  • Autres fichiers : formatage avec prettier
• Avant tout commit, il est indispensable d’exécuter make lint et make fmt

Build et tests

• En cas de modification du code Protobuf, il faut régénérer le code Go : make generate
• Exécution des tests : make test
• Build :
  • nix build
  • ou la commande make build

Autres informations

• Une présentation liée à Headscale a eu lieu au FOSDEM 2023 : voir la vidéo
• Le projet n’a pas de lien direct avec Tailscale Inc., mais des contributeurs de Tailscale y participent, tandis que les revues de code et l’orientation du projet restent indépendantes

[GN⁺]

Avis Hacker News

• Tous les quelques mois, je repasse voir ce dépôt pour vérifier si tailnet lock fonctionne ou si un audit de sécurité a été réalisé. Malheureusement, rien n’a avancé sur ces deux points, ce qui me laisse incertain quant à la possibilité de faire confiance à ce système comme élément central de mon infrastructure

  • Tout le principe du SaaS de Tailscale est de créer des tunnels à travers les pare-feu et de permettre aux utilisateurs de gérer de manière intuitive et intégrée le routage via ces tunnels
  • Headscale semble bien résoudre la partie contournement des pare-feu et traversée de NAT. Mais je me demande s’il peut offrir assez de sécurité pour compenser ce qu’il contourne, ou s’il risque simplement de devenir un outil qui contrarie les administrateurs réseau locaux
  • Ne faire absolument aucun audit du code serveur de l’implémentation Tailscale, tout en ne donnant pas aux utilisateurs de moyen de comprendre ou de refuser ce que le serveur de contrôle ordonne aux clients, me paraît audacieux

• Si vous vous intéressez à l’auto-hébergement du serveur d’orchestration, vous pouvez jeter un œil à Netbird. C’est très similaire, mais le serveur est proposé en open source. Vous pouvez donc avoir un serveur de contrôle auto-hébergé avec toutes les fonctionnalités de la version payante, ainsi qu’une belle interface graphique

  • Lien de comparaison entre Netbird et Tailscale

• Ce serait bien si Headscale permettait le peering / la fédération entre instances (même après la refonte des ACL). L’un des principaux problèmes est le conflit d’adresses

  • Proposition : se consacrer à un réseau overlay IPv6 uniquement dans la plage des Unique Local Addresses (ULA), puis répartir les 121 bits restants en 20 bits pour l’adresse de l’appareil (~1 million) et 101 bits pour le hash de la clé publique du serveur. Ajouter les clés publiques d’autres instances et utiliser des politiques et des ACL pour gérer la communication entre les nœuds
  • Je pense que c’est une bonne idée, mais quand j’ai soulevé cette question en 2023, le mainteneur kradalby a dit que c’était hors périmètre Lien vers l’issue GitHub

• Il faudrait ajouter le nom du projet, Headscale, dans le titre

  • Headscale est déjà apparu plusieurs fois sur HN

• Je me demande si ça tourne sur Plan 9

• J’adore Headscale. Nous l’avons déployé en production et ça s’est très bien passé

• Je me demande à quel point mes appareils risquent d’être compromis si le serveur de coordination Tailscale est compromis et que tailnet lock est activé

• Pour de nombreux cas d’usage (accès mobile, GUI sur macOS), le client officiel Tailscale dépend de la capacité à configurer le serveur de contrôle

  • Si l’inévitable réduction fonctionnelle commence chez Tailscale, cette possibilité disparaîtra
  • Je dis cela en tant que client Tailscale actuellement très satisfait, malgré plusieurs déceptions passées avec d’autres entreprises vendues ou à court de financement VC

• Je me demande quelle valeur ajoutée cette configuration apporte par rapport à une configuration wireguard + openwrt

• L’affirmation « Ne faire absolument aucun audit du code serveur de l’implémentation Tailscale, tout en ne donnant pas aux utilisateurs de moyen de comprendre ou de refuser ce que le serveur de contrôle ordonne aux clients, me paraît audacieux » suggère que le simple fait de publier le code source du serveur de contrôle Headscale n’est pas une condition suffisante pour que les utilisateurs puissent « comprendre ou refuser ce que le serveur de contrôle ordonne aux clients »

  • Lorsqu’ils utilisent le serveur de contrôle Headscale, les utilisateurs peuvent « comprendre ou refuser tout ce que le serveur de contrôle ordonne aux clients ». Cela peut être obtenu en lisant, modifiant et compilant le code source
  • Lorsqu’ils utilisent le serveur de contrôle Tailscale, les utilisateurs ne peuvent « comprendre ou refuser ce que le serveur de contrôle ordonne aux clients » que dans les limites autorisées par l’entreprise Tailscale. Il leur est interdit de modifier ou compiler le code source
  • Tous les utilisateurs ne souhaitent pas forcément avoir la possibilité de lire, modifier et compiler les logiciels tiers qu’ils utilisent. Certains peuvent être satisfaits de dépendre des garanties continues d’une entreprise de la Silicon Valley financée par du capital-risque. Pour les utilisateurs qui veulent un projet 100 % open source, Headscale peut être utile
  • L’auteur de Headscale a qualifié le serveur de coordination Tailscale de « Dropbox partagé essentiellement pour des clés publiques »