Un plan de contrôle pour un maillage privé.

Comprendre ce qui est coordonné

Le plan de contrôle gère l'enregistrement des nœuds et distribue les informations réseau. Le trafic de données peut utiliser des connexions directes entre pairs ou un relais selon la connectivité. Faire tourner le coordinateur ne signifie pas que chaque paquet le traverse.

Rendre l'inscription intentionnelle

Protégez le API administratif et utilisez des méthodes d'enregistrement de courte durée ou correctement limitées. Supprimez les appareils perdus ou mis au rebut. La possibilité de rejoindre le maillage ne doit pas impliquer l'accès à tous les services.

Vérifiez les ACL et les routes

Appliquez des règles de moindre privilège entre les utilisateurs et les nœuds. Les routes de sous-réseau annoncées et les nœuds de sortie étendent le réseau accessible et nécessitent une approbation explicite. Testez le trafic refusé avec autant de soin que le trafic autorisé.

Conservez le matériel de récupération

Sauvegardez la configuration, l'état et les clés selon la procédure de la version prise en charge. Conservez un moyen d'administrer le VPS si le maillage échoue. Vérifiez la compatibilité des clients et les notes de mise à niveau avant de modifier le plan de contrôle.

L'enregistrement, le routage et la politique sont des contrôles distincts

Headscale coordonne les clients Tailscale compatibles ; les connexions directes et les chemins de relais DERP ont un comportement réseau différent. Un routeur de sous-réseau annonce une plage, le serveur de contrôle l'approuve et le client doit accepter la route. Activez le transfert sur le nœud de routage et gardez des plages annoncées étroites. Une route approuvée nécessite encore une politique d'accès limitant qui peut utiliser quelle destination et quel port.

• Vérifiez la liste des routes du serveur de contrôle
• Testez depuis un appareil autorisé
• Répétez le même test depuis un appareil qui doit être refusé

headscale nodes list-routes

Documentation officielle : Routes Headscale

Ne placez pas l'unique chemin de récupération à l'intérieur du maillage

Conservez un second moyen d'accéder à la console du serveur ou une route administrateur strictement restreinte. Testez ce qui se passe lorsque le coordinateur, le relais ou le client est indisponible. Préservez l'état du plan de contrôle et les clés selon la version installée. Un maillage privé peut simplifier l'accès, mais il ne doit pas devenir une dépendance non documentée qui empêche sa propre réparation.

Fixez l'identité du plan de contrôle et la voie de rétablissement

Choisissez un nom HTTPS stable, une version Headscale prise en charge et des clients Tailscale compatibles. Lisez l'exemple de configuration fourni avec cette version exacte ; une configuration copiée depuis une autre version peut échouer à la validation ou décrire silencieusement une politique différente. Persistez la base de données du plan de contrôle et les clés requises. Gardez le API administratif privé et conservez une console distincte ou une route SSH restreinte, afin que la perte du maillage ne rende pas son coordinateur impossible à réparer.

• Utilisez un certificat valide pour le nom public du plan de contrôle.
• Limitez la durée de vie des clés d'enrôlement et définissez correctement leur portée.
• Traitez la conception du relais et l'espace de noms DNS comme des choix explicites.

Documentation officielle : Déploiement du conteneur Headscale

Enrôlez un appareil avant d'annoncer un réseau

Démarrez le serveur selon les instructions amont et enregistrez un utilisateur/appareil de test via la méthode d'enrôlement documentée. Confirmez que l'appareil atteint le URL de contrôle attendu et apparaît sous l'identité prévue. Inspectez l'état du client et testez un service privé avant d'ajouter des routes de nœud de sortie ou de sous-réseau. Un chemin DERP peut préserver la connectivité lorsqu'un chemin direct est indisponible ; il n'indique pas que le coordinateur transmet chaque paquet.

• Commencez par un appareil et un service que vous pouvez retirer sans risque.
• Vérifiez si le trafic des pairs est direct ou relayé.
• Protégez les points de terminaison de relais et de contrôle selon le déploiement choisi.

Documentation officielle : Référence de déploiement Headscale

Approuvez le routage et l'autorisation séparément

Pour l'accès à un sous-réseau, activez le transfert sur le nœud de routage, annoncez une plage étroite, approuvez-la sur le serveur de contrôle et assurez-vous que le client de destination l'accepte. Évitez les réseaux qui se chevauchent et rendent la route de retour ambiguë. Une route approuvée n'est pas une politique d'accès : définissez qui peut se connecter à quelle destination et quel port, y compris les appareils invités. Testez une connexion autorisée et une connexion identique refusée avant d'étendre le maillage.

# Run on the control server; syntax follows the installed release:
headscale nodes list-routes
# Client-side inspection:
tailscale status

Documentation officielle : Sous-réseau et routes de sortie Headscale

Identifiez la couche défaillante avant de modifier la politique

Si l'enrôlement échoue, inspectez DNS, HTTPS et le URL du serveur. Si l'appareil rejoint mais qu'un sous-réseau est injoignable, inspectez l'annonce, l'approbation, l'acceptation des routes par le client, le transfert et le chemin de retour. Si un seul service échoue, inspectez son adresse de liaison, le pare-feu de l'hôte et la politique du maillage. Conservez une sauvegarde cohérente de la base de données et de la configuration et testez une mise à niveau de version avec un client jetable avant de modifier l'unique plan de contrôle.