Votre propre serveur de contrôle.
La carte est la chose qui mérite d'être détenue.

Il existe trois réponses honnêtes à « je veux que mes machines se joignent entre elles en privé », et une seule d'entre elles est ce guide. WireGuard nu est la plus petite : un module noyau, un fichier de configuration par pair, aucun démon au-delà de l'interface, rien à maintenir à jour sinon le système d'exploitation. Si vos appareils sont des serveurs à adresses fixes que vous pouvez compter sur les doigts d'une main, arrêtez-vous ici et lisez plutôt le guide WireGuard. Vous finirez avec moins de logiciel et une liste plus courte de choses qui peuvent casser.

Tailscale est la plus vaste : le même WireGuard en dessous, plus un service de coordination, une traversée NAT qui fonctionne depuis presque n'importe quel réseau, une flotte de relais sur plusieurs continents, une console web, une authentification unique et un contrat de support. C'est un logiciel réellement excellent, et le niveau gratuit couvre confortablement un foyer. Le prix n'est pas en argent — c'est que la carte de chaque appareil que vous possédez, et l'historique des lieux de connexion de chacun, vivent dans la base de données d'une entreprise.

Headscale est la troisième réponse, et elle est plus étroite que les deux autres : une réimplémentation open source du serveur de coordination, gérée par vous, à qui parle le même client officiel. Vous gardez l'automatisation et la traversée NAT ; vous héritez d'un petit service à faire tourner, d'un jeu de fonctionnalités partiel, et de mises à jour qu'il faut lire avant d'appliquer. Personne ne devrait prétendre que c'est gratuit. Cela achète exactement une chose, celle qui compte pour ce site : personne d'autre ne détient la carte.

Encore une chose à décider maintenant plutôt que plus tard, car cela change ce que vous installez : ce réseau est-il seulement pour vous, ou d'autres personnes vont-elles le rejoindre ? Un tailnet pour une seule personne peut rester grand ouvert en interne sans que rien de fâcheux n'arrive. Un tailnet avec un collègue, un prestataire ou un membre de la famille dessus a besoin de règles d'accès écrites dès la première semaine — étape 05 — et il a besoin d'utilisateurs séparés plutôt que d'une connexion partagée par tous. Décider cela en amont coûte un paragraphe ; le corriger après coup coûte un après-midi.

Headscale et Caddy, et rien d'autre. Headscale écoute en HTTP nu à l'intérieur du réseau Docker ; Caddy termine le TLS, obtient le certificat au premier démarrage et le renouvelle sans qu'on le lui demande. L'écouteur de métriques reste sur localhost, car c'est une surface de débogage interne, pas une surface publique.

Une règle avant le fichier : figez l'image sur une version exacte. Headscale est un logiciel pré-1.0 qui a renommé ses clés de configuration et ses sous-commandes CLI au fil des versions mineures, plus d'une fois. Un tag flottant transforme un redémarrage de conteneur de routine en panne sur un service dont le rôle est justement de vous permettre de joindre tout le reste.

/srv/headscale/docker-compose.yml

services:
  headscale:
    image: docker.io/headscale/headscale:0.26            # pin it; never :latest
    container_name: headscale
    command: serve
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "3478:3478/udp"                                  # STUN, for your own DERP
    restart: unless-stopped

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
    restart: unless-stopped

volumes:
  caddy_data:

/srv/headscale/Caddyfile

vpn.example.com {
    reverse_proxy headscale:8080
}

C'est là toute la configuration du proxy. Caddy parle HTTP/2 et fait passer les connexions longue durée à un niveau supérieur sans qu'on le lui demande, ce qui compte ici puisque chaque client en garde une ouverte pour recevoir les mises à jour de carte. Prenez le fichier de configuration d'exemple fourni avec la version que vous avez figée, et modifiez-le plutôt que d'en écrire un depuis zéro — le fichier est long, l'essentiel n'est que des valeurs par défaut sensées, et les clés qui comptent sont celles-ci :

/srv/headscale/config/config.yaml — the lines that matter

server_url: https://vpn.example.com          # exactly what clients will dial
listen_addr: 0.0.0.0:8080                    # inside the Docker network only
metrics_listen_addr: 127.0.0.1:9090          # debug surface, keep it local

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

noise:
  private_key_path: /var/lib/headscale/noise_private.key

database:
  type: sqlite                               # postgres for a large fleet
  sqlite:
    path: /var/lib/headscale/db.sqlite

dns:
  magic_dns: true
  base_domain: ts.example.com                # NOT a parent or child of server_url
  nameservers:
    global:
      - 1.1.1.1                              # replaced by your own in step 05

Démarrez-le, puis lisez le journal plutôt que de supposer. Un premier démarrage qui ne parvient pas à obtenir un certificat, ou qui rejette le suffixe DNS parce qu'il chevauche le nom d'hôte du serveur, le dit clairement, puis s'arrête.

docker compose up -d
docker compose logs -f headscale

# From your laptop — a control server that is up answers this:
curl -s https://vpn.example.com/health

Le premier démarrage génère le matériel de clé privée dans /srv/headscale/data. Copiez-le en lieu sûr dès maintenant, avant qu'un seul appareil ne s'enregistre, puis à nouveau après le premier enrôlement : perdre cette clé signifie que chaque appareil rejette le serveur auquel il faisait confiance, et la seule réparation possible est de tous les réenrôler à la main. L'étape 06 transforme cette copie en une véritable sauvegarde.

Un tailnet où chaque appareil peut joindre tous les autres est déjà utile. Trois ajouts en font un véritable réseau plutôt qu'un simple jeu de tunnels, et tous trois partagent un même piège : le client annonce une capacité, et le serveur doit l'approuver. Une route annoncée mais non approuvée n'existe tout simplement pas, silencieusement, et le symptôme est que vous pouvez pinguer le routeur mais rien derrière lui.

Un routeur de sous-réseau — placez tout un réseau local sur le tailnet. Une machine du réseau domestique ou de bureau annonce la plage du réseau ; tous les autres appareils peuvent alors joindre les imprimantes, le NAS et les interfaces d'administration qui se trouvent derrière elle, sans rien avoir à installer là-bas. Activez d'abord le forwarding dans le noyau, sinon les paquets s'arrêtent au routeur sans le moindre message d'erreur.

# On the machine that sits inside the LAN:
echo 'net.ipv4.ip_forward = 1'          | sudo tee /etc/sysctl.d/99-ts.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-ts.conf
sudo sysctl -p /etc/sysctl.d/99-ts.conf

sudo tailscale up --login-server https://vpn.example.com \
  --advertise-routes=192.168.1.0/24 --accept-routes

# On the control server — approve it, or it does not exist.
# The subcommand moved between releases; check `hs nodes --help` first.
hs nodes list
hs nodes approve-routes --identifier 3 --routes 192.168.1.0/24

Un nœud de sortie — faites sortir tout le trafic par le VPS. Le même mécanisme avec une route plus large : un appareil qui s'annonce comme nœud de sortie propose de porter toute la connexion internet d'un autre appareil. Sur un réseau de café ou d'hôtel non fiable, c'est exactement ce qu'il vous faut, et c'est ce qui, dans ce guide, se rapproche le plus d'un VPN personnel.

# On the VPS that will do the exiting (forwarding must be on, as above):
sudo tailscale up --login-server https://vpn.example.com --advertise-exit-node

# Approve it on the control server, then on the laptop:
tailscale set --exit-node=100.64.0.1 --exit-node-allow-lan-access
tailscale set --exit-node=                    # turn it off again

Un nœud de sortie n'est pas un VPN commercial et ne doit pas se vendre comme tel, même à vous-même. Son adresse est à vous seul et elle est stable, ce qui est excellent contre le Wi-Fi d'un café et inutile contre une corrélation à long terme entre plusieurs sites — le compromis est détaillé dans le guide pilier. Notez aussi que vous pouvez faire tourner le nœud de sortie sur un second VPS, moins cher, et garder le serveur de contrôle entièrement libre de tout trafic relayé.

Règles d'accès — rédigez-les avant qu'une deuxième personne ne rejoigne le réseau. La politique par défaut autorise tout, ce qui est correct pour un tailnet d'une seule personne et faux dès qu'une autre personne s'y trouve. La politique est un petit document HuJSON : des groupes d'utilisateurs, des tags pour les machines, et une liste de règles qui disent quelles sources peuvent joindre quelles destinations sur quels ports. Pointez la configuration vers le fichier, gardez le fichier sous contrôle de version, et rechargez après chaque modification.

{
  "groups": {
    "group:admin":     ["alice"],
    "group:contractor":["bob"]
  },
  "tagOwners": {
    "tag:server": ["group:admin"],
    "tag:exit":   ["group:admin"]
  },
  "acls": [
    // Admins reach everything.
    { "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },

    // The contractor reaches one machine, on two ports, and nothing else.
    { "action": "accept", "src": ["group:contractor"],
      "dst": ["tag:server:22,443"] }
  ],
  "autoApprovers": {
    "routes":   { "192.168.1.0/24": ["tag:server"] },
    "exitNode": ["tag:exit"]
  }
}

Deux remarques sur ce fichier. Le langage de politique est celui de Tailscale, et Headscale en implémente un sous-ensemble large et croissant plutôt que la totalité — consultez la documentation de votre version avant de compter sur une règle exotique. Et l'endroit où vit la politique a changé : les anciennes versions nommaient un chemin dans la configuration de premier niveau, les plus récentes la regroupent sous une section de politique avec un mode qui peut aussi garder les règles en base de données. Les deux sont documentés ; celui qui compte est celui que fournit la version que vous avez figée.

MagicDNS — des noms courts, et votre propre résolveur partout. Une fois MagicDNS activé, chaque appareil répond à un nom court à l'intérieur du suffixe que vous avez choisi à l'étape 02, si bien que ssh nas fonctionne depuis n'importe où sans fichier hosts. La seconde moitié est la plus intéressante : le serveur de contrôle pousse aussi une liste de serveurs de noms à chaque client, ce qui signifie que le résolveur que vous avez construit dans le guide du résolveur DNS privé peut servir votre téléphone en données mobiles — en filtrant, en mettant en cache et en ne journalisant rien — tout en écoutant sur une adresse du tailnet qui n'est absolument pas joignable depuis internet.

dns:
  magic_dns: true
  base_domain: ts.example.com
  override_local_dns: true          # beat whatever DHCP handed the device
  nameservers:
    global:
      - 100.64.0.5                  # your resolver, on the tailnet

Auto-héberger le plan de contrôle est une amélioration réelle et précise, et ce n'est pas un tour de passe-passe. Cinq choses restent vraies une fois tout ce qui précède accompli, et les connaître fait la différence entre une véritable défense et une histoire rassurante.

Le serveur de contrôle est un point de terminaison public et nommé. Chaque appareil l'appelle, il possède donc un nom d'hôte, et ce nom d'hôte est publié dans les journaux de transparence des certificats dès que le certificat est émis. Il est repérable même si vous ne le liez jamais nulle part, et son adresse est la seule constante que tous vos appareils ont en commun. Utilisez un sous-domaine d'un nom que vous publiez déjà, plutôt qu'un nom qui décrit ce qu'il est.

Headscale est une réimplémentation, et il le dit lui-même. Il n'est ni construit ni pris en charge par Tailscale, la parité fonctionnelle est partielle par construction, et une partie de ce que vend le produit hébergé — la console web, la flotte de relais publique, les parcours d'authentification unique bien polis — soit n'existe pas ici, soit est un projet tiers que personne n'a audité. Consultez la documentation du projet pour savoir si une fonctionnalité existe avant de bâtir un plan dessus, et traitez les mises à jour comme une tâche à part entière plutôt que comme un processus de fond.

Les relais par défaut appartiennent toujours à quelqu'un d'autre. Tant que vous n'activez pas le serveur DERP intégré, une connexion qui ne peut pas passer en direct se replie sur la flotte de relais publique. La charge utile reste chiffrée de bout en bout et personne ne peut la lire — mais le fait que deux de vos appareils se parlent, et combien, transite par une infrastructure que vous ne possédez pas. C'est la partie de la chaîne de confiance que la plupart des gens ratent dès le premier après-midi.

Un nœud de sortie, c'est une adresse stable, pas une foule. Faire passer votre trafic par votre propre VPS déjoue le réseau du café et le profilage du FAI. Cela ne déjoue pas la corrélation, car cette adresse vous appartient à vous seul et ne change pas. L'adresse partagée d'un VPN commercial est pire à tous égards, sauf sur celui qui compte pour cette menace précise.

La machine se trouve toujours dans un bâtiment. Un serveur loué tourne sur du matériel, dans un datacentre avec des portes et du personnel. Ce qui change, c'est qu'il n'existe aucun index produit de vos appareils, aucune base de données d'entreprise consignant d'où chacun se connecte, et aucune politique de confidentialité susceptible d'être modifiée le trimestre prochain. Ce qui ne change pas, c'est que le disque est physique et qu'il ne se trouve pas chez vous.

Ce que vous avez réellement acheté, précisément : la liste de chaque machine que vous possédez, l'historique des lieux de connexion de chacune, et l'autorité d'en ajouter une nouvelle, sont tous détenus sur une machine que vous louez sous aucun nom en particulier. C'est une affirmation étroite, mais réelle. Elle ne vaut ce qu'elle coûte que si l'étape 06 est accomplie — un plan de contrôle auto-hébergé sans restauration testée n'est pas une amélioration de la confidentialité, c'est un point de défaillance unique avec un meilleur habillage marketing.