J’accède à mes hôtes privés par un réseau maillé. J’exploite moi-même ce réseau, avec Headscale comme serveur de contrôle et Headplane comme interface web. Cet article explique pourquoi, et comment je gère maintenant les accès sans modifier de fichiers sur le serveur.
Pourquoi un serveur de contrôle autohébergé
Les clients Tailscale ont besoin d’un serveur de contrôle pour enrôler les appareils et distribuer les règles d’accès. Headscale est une implémentation autohébergée à code source ouvert de ce serveur de contrôle, sous licence BSD-3-Clause. Le plan de contrôle s’exécute sur une machine que j’exploite, selon mes propres règles d’accès.
Le gérer dans un navigateur
Headplane est une interface web pour Headscale. Elle affiche les machines, les utilisateurs, le DNS et la liste de contrôle d’accès. Je l’ai mise à niveau de la version 0.7.1 à la version 0.8.1 en changeant une seule épingle de version dans mon dépôt d’infrastructure, et la vérification d’état est restée au vert.
Les règles d’accès dans la base de données, pas dans un fichier
Mes règles d’accès ont commencé comme un fichier JSON révisé dans git. Headscale peut aussi stocker la politique dans sa base de données. Une fois la politique à cet endroit, vous pouvez la modifier par l’API, avec GET et PUT sur /api/v1/policy. Headscale valide la politique avant de l’enregistrer ; une politique invalide est donc refusée plutôt que chargée.
Le changement comporte une étape qui demande de la prudence. En mode fichier, Headscale rejette les écritures de politique ; on ne peut donc pas importer la politique au préalable. Par défaut, sans politique chargée, Headscale autorise tout le trafic ; la politique en vigueur doit donc être stockée immédiatement après le changement. Je l’ai fait sur mon VPN partagé et j’ai confirmé que la politique stockée correspondait à celle en vigueur.
Ce dont je suis reconnaissant
Merci aux mainteneurs et aux contributeurs de Headscale et de Headplane. Un serveur de contrôle compatible avec les clients Tailscale standards est difficile à construire, et le maintenir fonctionnel d’une version à l’autre demande un effort constant. Leurs versions, leurs tickets et leurs journaux des modifications m’ont permis d’exploiter mon propre réseau.
À vous d’essayer
Commencez par la documentation de Headscale et le guide d’installation de Headplane. Testez d’abord les changements de règles d’accès sur un réseau hors production, et utilisez des clés d’API à courte expiration pour l’automatisation.
Runzivo exploite des exécuteurs GitHub Actions gérés, chaque tâche s’exécutant dans une microVM neuve à usage unique. Inscrivez-vous à app.runzivo.dev.