Protéger sa connexion sans abonnement

Le cas que je prends pour la suite est fréquent chez un indépendant. Le travail se fait presque toujours à la maison, sur une fibre. Les déplacements sont rares, et ils mènent chez des proches. Le portable se branche alors au partage de connexion du téléphone, en 4G ou en 5G, pour éviter le Wi-Fi de l’endroit. Un seul appareil porte les accès qui comptent. L’ancien poste et le second téléphone dorment dans un tiroir.

Dans ce cadre, « sécuriser Internet » désigne trois situations différentes. Les mélanger est ce qui fait payer un abonnement toute l’année pour un risque qui n’existe que quelques jours.

Entre le navigateur et un site en HTTPS, le contenu de la page, les mots de passe et les cookies sont chiffrés. Un voisin sur le Wi-Fi du café ne lit pas le message. Ce qu’il peut encore voir, sans tunnel, c’est surtout le nom du site : la requête DNS, et souvent le nom envoyé en clair au début de la connexion TLS (le SNI), tant que le site ne le chiffre pas. Il voit aussi tout ce qui ne passe pas par HTTPS : un vieux protocole, un outil en ligne de commande mal réglé, une application qui parle en clair.

Le VPN enveloppe l’ensemble dans un second tunnel, du portable jusqu’à un serveur de sortie. Le réseau local ne voit plus qu’un seul flux, vers ce serveur. Le nom des sites devient visible pour l’opérateur de la sortie, et cesse de l’être pour le café et pour le fournisseur d’accès du lieu. On déplace la confiance. On ne la supprime pas.

Un kill switch, ou coupe-circuit, ferme la fuite du moment où le tunnel tombe. Sans lui, la panne du VPN remet le trafic sur le réseau local, souvent sans que rien ne s’affiche à l’écran. C’est le réglage qui sépare un tunnel décoratif d’un tunnel sur lequel on peut s’appuyer.

La suite du mémo juge les outils sur ces deux colonnes, et sur une troisième : qui peut être obligé de dire ce que vous avez fait. Une politique « sans journaux » ne vaut que si quelqu’un d’extérieur l’a regardée, ou si une saisie réelle est repartie les mains vides. Le pays du siège donne le cadre juridique. Il ne remplace pas cette preuve.

Les montants bougent avec les promotions. Ce qui suit nomme la page lue et la date. Un devis, ou une résiliation, se refait sur la page du jour.

Les marques à gros volume, NordVPN, Surfshark et leurs voisines, descendent souvent sous 40 € par an sur un engagement long. Elles coûtent moins. Sur le code ouvert, les audits répétés et la retenue de données, elles sont en dessous de Proton et de Mullvad. Elles répondent à un autre critère que celui de ce mémo.

Mullvad ferme son résolveur DNS public le 2 novembre 2026 et finance Quad9 à la place. Le DNS interne du VPN Mullvad, lui, continue pour les clients connectés. Qui utilisait les adresses publiques Mullvad dans son réseau doit migrer avant cette date.

Un montage « à zéro euro » empile des contrôles gratuits. Aucune ligne ne couvre la suivante. On lit le risque, on décide si on l’a, on pose la couche ou on la laisse.

Le mémo sur l’auto-hébergement rappelle la question qui reste après le tableau : qui répare le dimanche où la sortie ne répond plus. Si la réponse est « personne », Mullvad ou le gratuit Proton sont le bon arrêt, et les couches du tableau qui ne dépendent pas du serveur se posent quand même.

Headscale est le serveur de coordination de Tailscale, publié pour un usage personnel ou une petite structure. Les clients officiels Tailscale s’y connectent à la place de tailscale.com. Le trafic utile va en WireGuard d’une machine à l’autre. Headscale ne voit pas le contenu : il distribue les clés et dit qui a le droit de parler à qui.

La version stable au 23 septembre 2026 est la 0.29.4. Elle demande un client Tailscale au moins en 1.80.0. Les commandes ci-dessous sont celles de la documentation stable ce jour-là (headscale.net/stable). La ligne de commande a déjà changé une fois : l’ancienne forme headscale routes enable est devenue headscale nodes approve-routes. Le jour de l’installation, on rouvre cette page avant de coller.

Il faut une machine Debian 12 ou Ubuntu 22.04 au minimum, avec une adresse publique que le téléphone peut joindre, un nom de domaine, et le port 443 libre. Une box à la maison dont l’opérateur partage l’adresse avec d’autres abonnés ne peut pas tenir ce rôle. Un serveur déjà loué le peut. On garde sous la main la console de l’hébergeur : c’est elle qui rouvre la machine si une règle de pare-feu coupe le SSH.

Poser le paquet officiel

Le paquet .deb publié par le projet crée l’utilisateur, le service systemd et un fichier de configuration. J’écarte les dépôts tiers qui promettent « la dernière version » : ajouter une source de paquets, c’est lui donner le droit d’installer ce qu’elle veut sur le serveur.

# La version se lit sur https://github.com/juanfont/headscale/releases/latest
# Pas de « v » dans HEADSCALE_VERSION. L’architecture : dpkg --print-architecture
HEADSCALE_VERSION="0.29.4"
HEADSCALE_ARCH="amd64"
wget --output-document=headscale.deb \
  "https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"
sudo apt install ./headscale.deb
headscale version

Dire à quelle adresse les clients vont le trouver

Le fichier est /etc/headscale/config.yaml. L’exemple commenté, livré avec le paquet, est dans /usr/share/doc/headscale/examples/config-example.yaml. On y règle server_url sur https://vpn.exemple.fr, avec le nom réel. Deux façons tiennent le HTTPS. Soit Headscale écoute lui-même le 443 et obtient le certificat (la section TLS de l’exemple, et la 0.29.4 corrige un blocage de renouvellement ACME). Soit un reverse proxy déjà en place termine le TLS et transmet à 127.0.0.1:8080, et listen_addr reste sur cette adresse locale. On choisit la façon déjà connue sur la machine, et une seule.

sudo systemctl enable --now headscale
sudo systemctl status headscale
sudo headscale users create maison

Dans la section derp du même fichier d’exemple, on active le serveur embarqué, et l’URL https://controlplane.tailscale.com/derpmap/default se retire. Sans ce retrait, deux machines qui ne se joignent pas en direct empruntent un relais de Tailscale : le contenu reste chiffré, mais le fait que ces deux machines se parlent repasse par eux. Le relais embarqué écoute en UDP, souvent sur 3478. Ce port doit être ouvert, comme le 443.

Enrôler le portable

Le client vient de Tailscale. C’est le point de confiance qui reste : le binaire est le leur, le serveur de coordination est le vôtre. Le script d’installation officiel est https://tailscale.com/install.sh. Ensuite, tailscale version doit annoncer au moins 1.80.0. Le paquet de la distribution est parfois plus vieux : dans ce cas il ne convient pas à Headscale 0.29.4.

sudo tailscale up --login-server https://vpn.exemple.fr

Le client affiche une clé de machine. On l’enregistre côté serveur, une fois :

sudo headscale nodes register --user maison --key CLE_AFFICHEE_PAR_LE_CLIENT
sudo headscale nodes list

La clé d’invitation (headscale preauthkeys create --user maison) évite cette aller-retour. Par défaut elle expire en une heure et ne sert qu’une fois. Une clé réutilisable se traite comme un mot de passe : quiconque la possède entre dans le réseau. On évite de la laisser dans l’historique du shell.

Sur Android, l’application officielle Tailscale (Play Store ou F-Droid) a, dans Comptes, l’entrée « Use an alternate server ». On y met la même URL. L’enregistrement se termine par la même commande nodes register, ou par une clé d’invitation. L’iPhone suit la page Apple de la documentation Headscale. On n’enrôle pas les appareils qui dorment dans un tiroir : tant que la politique est ouverte, chaque nœud peut parler aux autres.

Le nœud de sortie est en général le même serveur. Il doit router le trafic des autres. Headscale renvoie pour cela à la documentation Tailscale, et les deux lignes suivantes sont celles que cette documentation utilise depuis des années. On les vérifie le jour même si la page a bougé.

# Sur le serveur qui va servir de sortie
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-forward.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-forward.conf
sudo sysctl --system

sudo tailscale up --login-server https://vpn.exemple.fr --advertise-exit-node

# Puis, toujours sur le serveur, lire l’identifiant et approuver
sudo headscale nodes list-routes
sudo headscale nodes approve-routes --identifier 1 --routes 0.0.0.0/0

L’identifiant 1 dans l’exemple est celui de la ligne affichée par list-routes. On recopie le nombre lu. Approuver 0.0.0.0/0 approuve aussi la route IPv6. Sans cette approbation, le client peut « voir » une sortie que le réseau refuse encore.

sudo tailscale set --exit-node NOM_DU_SERVEUR
curl -4 --max-time 10 https://api.ipify.org

L’adresse affichée doit être celle du serveur. On recommence après avoir retiré la sortie (sudo tailscale set --exit-node=) : l’adresse doit redevenir celle du lieu. Les deux résultats, notés, sont le compte rendu. Un seul des deux ne prouve rien.

Chez soi, on retire la sortie. Le réseau privé continue de servir pour atteindre les serveurs, sans détourner toute la navigation. En déplacement, on la remet avant d’ouvrir une session de travail. Le partage de connexion du téléphone ne dispense pas de ce geste sur le portable.

Si une adresse de sortie de l’ancien VPN est autorisée chez un hébergeur pour le SSH, elle se remplace par l’adresse du nouveau serveur avant la résiliation. Sinon l’administration à distance casse le jour où l’ancien tunnel s’arrête, et le symptôme ressemble à une panne du serveur.

Fermer ce qui n’a plus de raison d’être public

Une fois le portable et le serveur dans le réseau, le SSH du serveur peut n’écouter que sur son adresse Headscale (le préfixe 100.64.0.0/10). On le vérifie depuis le portable, par cette adresse, avant de retirer le port 22 de l’adresse publique. L’authentification par mot de passe SSH se coupe au même moment, après avoir confirmé qu’une clé fonctionne. Le détail des clés est dans le mémo sur les accès.

Sans fichier de politique, Headscale laisse chaque nœud parler à chaque nœud. Pour une personne seule et deux machines, c’est tenable. Le jour où un appareil de test entre, on pose un fichier huJSON et on indique son chemin dans la configuration (la clé est dans l’exemple, sous la politique). La forme minimale, reprise de la documentation, limite le réseau à l’utilisateur maison et lui laisse la sortie Internet :

{
  "grants": [
    {
      "src": ["maison@"],
      "dst": ["maison@"],
      "ip": ["*"]
    },
    {
      "src": ["maison@"],
      "dst": ["autogroup:internet"],
      "ip": ["*"]
    }
  ]
}

• Les mises à jour. Le paquet officiel se met à jour en téléchargeant la publication suivante, pas en ajoutant un dépôt inconnu. On lit le guide de migration de la version avant de remplacer le binaire. Une base SQLite d’une version ne se relit pas toujours avec la suivante.
• La copie. /var/lib/headscale/db.sqlite, /etc/headscale/config.yaml, et la clé privée du relais embarqué. On restaure la copie sur une machine d’essai une fois, et on note la date. Le mémo des sauvegardes explique pourquoi une archive jamais ouverte ne compte pas.
• Le certificat. Un HTTPS expiré empêche les clients de joindre la coordination. Les machines déjà enrôlées peuvent continuer un temps en direct. Un téléphone neuf, lui, ne rentre plus.
• Le journal. Headscale n’a pas à écrire les sites visités. On vérifie que le serveur de sortie ne garde pas, lui, un journal de connexions détaillé « pour dépanner ». Ce journal, sur une machine à votre nom, est exactement ce qu’une réquisition viendrait chercher.
• L’hôte. L’hébergeur voit le trafic qui sort de sa machine, parce que c’est lui qui porte l’adresse. Choisir le pays du serveur, c’est choisir le droit qui s’applique à cette adresse. La Suisse de Proton n’est pas incluse dans le prix nul.

Headscale sur un serveur à soi égale un VPN commercial contre le réseau du lieu : le café, ou le partage de connexion, ne voit plus les destinations. Il est en retrait dès que l’adversaire est une autorité qui peut interroger l’hébergeur, ou un attaquant qui prend le serveur. Il est en retrait aussi dans un hôtel qui bloque l’UDP : WireGuard sur son port habituel ne passe pas, là où le protocole Stealth de Proton est fait pour ce cas. Le contournement existe, il se maintient, et il n’a pas sa place dans un premier montage.

Aucune des couches de ce mémo n’arrête un message qui vous convainc de donner un code, ni un poste déjà ouvert par un logiciel piégé. Ces deux risques-là se traitent par les accès, les mises à jour, et le refus d’exécuter ce qu’un courriel demande. Le tunnel vient après, et seulement là où le réseau n’est pas le vôtre.

Pour le cas du début, je poserais Quad9 et les mises à jour même sur connexion mesurée tout de suite, chez moi comme dehors. Je monterais Headscale sur un serveur déjà loué, j’y ferais entrer le portable et le téléphone, et je fermerais le SSH public des serveurs. J’activerais la sortie Internet seulement en déplacement, après l’essai du coupe-circuit. Je laisserais l’ancien poste et le second téléphone hors du réseau tant qu’ils ne servent pas. Je résilierais l’abonnement payant une fois les essais notés. Si le serveur devait être tenu par personne, je resterais sur Proton gratuit, limité à ce portable, et je garderais les couches qui ne demandent pas une machine.