WireGuard et Tailscale VPN sur un VPS Linux

20 min de lecture·Matthieu·securitydebianubuntulinuxheadscalevpntailscalewireguard|

Installez WireGuard de zéro ou déployez Tailscale pour un accès VPN géré sur Ubuntu 24.04 et Debian 12, avec prévention des fuites DNS, renforcement PreSharedKey et une comparaison neutre incluant Headscale.

Ce guide couvre deux approches pour l'accès VPN à un VPS Linux : WireGuard (manuel, contrôle total) et Tailscale (géré, clé en main). Les deux utilisent le protocole WireGuard. La différence tient à qui gère les clés, le routage et la coordination.

Choisissez la section qui correspond à votre situation, ou lisez les trois parties pour faire un choix éclairé.

Prérequis :

  • Un VPS sous Ubuntu 24.04 ou Debian 12 (fonctionne sur un VPS Virtua Cloud)
  • Un accès SSH avec un utilisateur non-root disposant de sudo
  • Un pare-feu configuré et actif
  • Une machine locale (Linux, macOS ou Windows) comme client VPN

Pourquoi établir un VPN vers votre VPS Linux ?

Chaque service exposé sur une IP publique est une cible. Les bots de brute-force SSH trouvent les nouveaux serveurs en quelques minutes. Les ports de bases de données, les panneaux d'administration et les endpoints d'API sont scannés en permanence. Un VPN permet de garder les interfaces de gestion hors de l'internet public.

Le principe est simple : liez les services sensibles à l'adresse de l'interface VPN plutôt qu'à 0.0.0.0. Seuls les appareils possédant des clés VPN valides peuvent y accéder. L'internet public ne voit jamais que ces ports existent.

Cas d'usage courants :

  • Accès admin sans SSH public. Liez sshd à l'IP WireGuard. Plus de port 22 exposé au monde. Fail2ban devient optionnel quand il n'y a rien à forcer.
  • Tunnel vers des API d'inférence IA privées. Vous faites tourner Ollama ou un endpoint LLM privé sur votre VPS ? Placez-le derrière le VPN. Pas besoin de passerelle API ni de gestion de tokens pour l'accès interne.
  • Réseau mesh multi-cloud. Connectez des nœuds VPS chez différents fournisseurs (Virtua, Hetzner, OVH) dans un réseau privé. Les services communiquent par tunnels chiffrés sans endpoints publics.
  • Chiffrement du trafic sur les réseaux non fiables. Routez tout le trafic via le VPS quand vous travaillez depuis un café ou un WiFi d'hôtel. Votre FAI et l'opérateur du réseau local ne voient que des paquets WireGuard chiffrés.

Le modèle de menace compte. Si vous n'accédez à votre VPS que depuis une IP de bureau fixe, des règles de pare-feu peuvent suffire. Mais si vous travaillez depuis plusieurs endroits, utilisez plusieurs appareils ou gérez une équipe avec différents niveaux d'accès, un VPN est la solution la plus propre.

Comment installer WireGuard sur Ubuntu 24.04 ou Debian 12 ?

WireGuard est un protocole VPN intégré au noyau Linux depuis la version 5.6. Il utilise Curve25519 pour l'échange de clés, ChaCha20 pour le chiffrement, et compte environ 4 000 lignes de code (contre plus de 100 000 pour OpenVPN). Installez-le avec apt, générez les paires de clés, écrivez un fichier de configuration et démarrez le tunnel. L'opération prend moins de 10 minutes.

Installez WireGuard sur le serveur :

sudo apt update && sudo apt install wireguard wireguard-tools -y

Le paquet wireguard fournit le module noyau. Le paquet wireguard-tools fournit les utilitaires wg et wg-quick en espace utilisateur.

Comment générer les clés WireGuard et configurer le serveur ?

WireGuard utilise des paires de clés asymétriques (une par pair) plus une clé pré-partagée optionnelle pour la défense post-quantique. Générez une paire de clés serveur, une paire client et une clé pré-partagée commune. La clé pré-partagée ajoute une couche de chiffrement symétrique en plus de l'échange Curve25519 de WireGuard. Si un futur ordinateur quantique casse l'échange de clés asymétriques, la clé pré-partagée symétrique protège toujours le tunnel.

Sur le serveur, générez les clés avec un umask restrictif pour que les fichiers soient créés avec des permissions 600 :

umask 077
wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key
wg genpsk | sudo tee /etc/wireguard/psk.key

ls -la /etc/wireguard/

-rw------- 1 root root   45 Mar 19 10:01 psk.key
-rw------- 1 root root   45 Mar 19 10:01 server_private.key
-rw------- 1 root root   45 Mar 19 10:01 server_public.key

Les trois fichiers sont en 600 (lecture/écriture propriétaire uniquement). La clé privée et la clé pré-partagée ne doivent jamais quitter le serveur.

Sur votre machine locale (le client), générez sa propre paire de clés :

umask 077
wg genkey | tee client_private.key | wg pubkey > client_public.key

Vous avez besoin de la clé publique du client sur le serveur, et de la clé publique du serveur sur le client. La clé pré-partagée va des deux côtés. Ne transférez jamais les clés privées.

Activer le routage IP

Le serveur doit router le trafic pour les clients VPN. Activez le routage IPv4 et IPv6 :

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-wireguard.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-wireguard.conf
sudo sysctl -p /etc/sysctl.d/99-wireguard.conf

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Utiliser un fichier dans /etc/sysctl.d/ est préférable à l'édition directe de /etc/sysctl.conf. Cela résiste aux mises à jour de paquets et rend explicite quels réglages appartiennent à quel service.

Fichier de configuration du serveur

Identifiez l'interface réseau publique de votre serveur :

ip route show default

default via 203.0.113.1 dev eth0 proto static metric 100

Dans cet exemple, l'interface est eth0. La vôtre peut être ens3, ens18 ou autre chose. Utilisez ce qui apparaît après dev.

Créez la configuration du serveur :

sudo nano /etc/wireguard/wg0.conf

[Interface]
Address = 10.66.66.1/24, fd42:42:42::1/64
ListenPort = 51820
PrivateKey = <contenu de /etc/wireguard/server_private.key>
PostUp = nft add table ip wireguard; nft add chain ip wireguard forward { type filter hook forward priority 0 \; policy accept \; }; nft add rule ip wireguard forward iifname "wg0" accept; nft add table ip nat; nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }; nft add rule ip nat postrouting oifname "eth0" masquerade
PostDown = nft delete table ip wireguard; nft delete table ip nat

[Peer]
PublicKey = <contenu de client_public.key>
PresharedKey = <contenu de /etc/wireguard/psk.key>
AllowedIPs = 10.66.66.2/32, fd42:42:42::2/128

Remplacez eth0 dans les lignes PostUp/PostDown par le nom réel de votre interface.

Ce que fait chaque section :

  • Address : l'IP VPN attribuée à ce serveur. Le /24 et /64 définissent la taille du sous-réseau VPN.
  • ListenPort : le port UDP sur lequel WireGuard écoute. 51820 est la convention.
  • PostUp/PostDown : les règles nftables qui activent le NAT masquerading. Quand un client VPN envoie du trafic vers internet, le serveur réécrit l'IP source avec sa propre IP publique. C'est ce qui fait fonctionner le VPN en tunnel complet.
  • AllowedIPs dans la section [Peer] : quelles IP VPN ce client peut utiliser. /32 signifie exactement une IP. Cela empêche les clients d'usurper d'autres adresses VPN.

Si vous utilisez ufw plutôt que nftables directement, remplacez PostUp/PostDown par :

PostUp = ufw route allow in on wg0 out on eth0; iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostDown = ufw route delete allow in on wg0 out on eth0; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Verrouillez le fichier de configuration. Il contient votre clé privée :

sudo chmod 600 /etc/wireguard/wg0.conf

Ouvrir le pare-feu et démarrer le tunnel

Autorisez le port UDP de WireGuard dans le pare-feu :

sudo ufw allow 51820/udp

Ou directement avec nftables :

sudo nft add rule inet filter input udp dport 51820 accept

Démarrez le tunnel. La directive enable le rend persistent après redémarrage. Le drapeau --now le démarre immédiatement :

sudo systemctl enable --now wg-quick@wg0

sudo systemctl status wg-quick@wg0

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/usr/lib/systemd/system/wg-quick@.service; enabled; preset: enabled)
     Active: active (exited) since ...

Le statut affiche active (exited) car wg-quick configure l'interface puis se termine. Le module noyau gère le tunnel à partir de ce moment. Inspectez le tunnel actif :

sudo wg show

interface: wg0
  public key: aB3dEfGhIjKlMnOpQrStUvWxYz1234567890abc=
  private key: (hidden)
  listening port: 51820

peer: xY9zAbCdEfGhIjKlMnOpQrStUvWxYz1234567890=
  preshared key: (hidden)
  allowed ips: 10.66.66.2/32, fd42:42:42::2/128

La sortie (hidden) signifie que WireGuard protège les clés sensibles. Si vous voyez latest handshake pour un pair, ce pair s'est connecté avec succès.

Configuration du client

Sur votre machine locale, créez la configuration WireGuard :

sudo nano /etc/wireguard/wg0.conf

[Interface]
Address = 10.66.66.2/24, fd42:42:42::2/64
PrivateKey = <contenu de client_private.key>
DNS = 10.66.66.1

[Peer]
PublicKey = <contenu de server_public.key>
PresharedKey = <contenu de psk.key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = YOUR_SERVER_PUBLIC_IP:51820
PersistentKeepalive = 25

Explication des paramètres clés :

  • AllowedIPs = 0.0.0.0/0, ::/0 route tout le trafic via le VPN (tunnel complet). Pour du split tunneling où seul le trafic du sous-réseau VPN passe par le tunnel, utilisez AllowedIPs = 10.66.66.0/24, fd42:42:42::/64 à la place.
  • Endpoint est l'IP publique et le port du serveur. Le client en a besoin pour initier la connexion. Le serveur n'a pas besoin de l'endpoint du client car il l'apprend depuis les paquets entrants.
  • PersistentKeepalive = 25 envoie un paquet keepalive toutes les 25 secondes. Cela maintient les associations NAT actives pour que le serveur puisse joindre le client. Sans cela, la connexion tombe après l'expiration du NAT (typiquement 30 à 120 secondes d'inactivité).
  • DNS = 10.66.66.1 dirige les requêtes DNS vers l'adresse VPN du serveur. Cela empêche les fuites DNS (expliqué dans la section suivante).

Sur macOS et Windows, utilisez l'application WireGuard. Importez le fichier de configuration ou collez-le.

Connectez-vous depuis le client :

sudo wg-quick up wg0

ping 10.66.66.1

PING 10.66.66.1 (10.66.66.1) 56(84) bytes of data.
64 bytes from 10.66.66.1: icmp_seq=1 ttl=64 time=4.23 ms
64 bytes from 10.66.66.1: icmp_seq=2 ttl=64 time=3.98 ms

Depuis votre machine locale, confirmez que votre IP publique a changé (si vous utilisez le tunnel complet) :

curl -s https://ifconfig.me

Cela devrait retourner l'IP publique du VPS, pas votre IP personnelle.

Ajouter d'autres clients

Pour chaque client supplémentaire, générez une nouvelle paire de clés et une nouvelle clé pré-partagée (une PSK par paire de pairs). Ajoutez un bloc [Peer] dans le fichier wg0.conf du serveur :

[Peer]
PublicKey = <nouvelle clé publique du client>
PresharedKey = <nouvelle clé pré-partagée>
AllowedIPs = 10.66.66.3/32, fd42:42:42::3/128

Incrémentez l'adresse IP pour chaque client. Après modification, rechargez sans couper les connexions existantes :

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)

Cela applique la nouvelle configuration de pairs sans redémarrer l'interface. Les connexions existantes restent actives.

Ajustement du MTU

WireGuard ajoute 60 octets de surcharge par paquet (28 octets pour les en-têtes IPv4 et UDP externes, 32 octets pour l'en-tête WireGuard). Si votre VPS a un MTU standard de 1500 octets, réglez le MTU WireGuard à 1420 dans la section [Interface] :

MTU = 1420

Définissez ceci côté serveur et client. Des MTU différents provoquent de la fragmentation de paquets et des chutes de débit difficiles à diagnostiquer. Si vous faites tourner WireGuard sur un lien avec un MTU déjà réduit (PPPoE, VXLAN), soustrayez en conséquence.

Comment empêcher les fuites DNS avec WireGuard ?

Les fuites DNS surviennent quand votre système envoie des requêtes DNS en dehors du tunnel VPN, exposant les domaines que vous visitez à votre FAI ou au réseau local. Cela annule le bénéfice de confidentialité du routage via le VPN. La solution : lancez un résolveur DNS local sur le serveur VPN et pointez le DNS du client vers ce résolveur à travers le tunnel.

Installez Unbound sur le serveur :

sudo apt install unbound -y

Créez un fichier de configuration pour qu'Unbound écoute sur l'interface WireGuard :

sudo nano /etc/unbound/unbound.conf.d/wireguard.conf

server:
    interface: 10.66.66.1
    interface: fd42:42:42::1
    interface: 127.0.0.1
    access-control: 10.66.66.0/24 allow
    access-control: fd42:42:42::/64 allow
    access-control: 127.0.0.0/8 allow
    do-ip6: yes
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    prefetch: yes

Les directives hide-identity et hide-version empêchent Unbound de divulguer sa version logicielle dans les réponses DNS. La divulgation de version aide les attaquants à cibler des vulnérabilités connues. Les options harden-* appliquent la validation DNSSEC et empêchent l'empoisonnement de cache. L'option use-caps-for-id ajoute un encodage 0x20 aux requêtes DNS, une défense légère contre les réponses usurpées.

Sur Ubuntu 24.04, systemd-resolved écoute sur le port 53 par défaut et entre en conflit avec Unbound. Désactivez-le :

sudo systemctl disable --now systemd-resolved
sudo rm /etc/resolv.conf
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf

Démarrez Unbound :

sudo systemctl enable --now unbound

sudo systemctl status unbound

● unbound.service - Unbound DNS server
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; preset: enabled)
     Active: active (running) since ...

Testez la résolution depuis l'interface WireGuard :

dig @10.66.66.1 example.com +short

Vous devriez obtenir une ou plusieurs adresses IP. Les IP exactes dépendent des enregistrements DNS actuels du domaine.

La configuration client définit déjà DNS = 10.66.66.1. Quand le tunnel WireGuard est actif, toutes les requêtes DNS passent par le tunnel chiffré vers Unbound. Aucune requête ne fuit vers votre FAI.

Pour confirmer côté client, connectez-vous au VPN et vérifiez :

resolvectl status wg0

Le serveur DNS devrait afficher uniquement 10.66.66.1. Vous pouvez aussi utiliser dnsleaktest.com.

Test Avant VPN Après VPN (avec Unbound)
Serveur DNS affiché Résolveur FAI (ex. 192.168.1.1) 10.66.66.1 (Unbound du VPS)
IP vue par le site de test IP domicile/bureau IP publique du VPS
Requêtes DNS visibles par le FAI Oui Non

Pour aller plus loin sur la sécurité DNS, notamment DNSSEC et DNS-over-HTTPS, voir .

Kill switch : que se passe-t-il quand le tunnel tombe ?

Si le tunnel WireGuard tombe, le trafic circule en clair sur votre route par défaut. Votre IP réelle et vos requêtes DNS sont exposées. Un kill switch empêche cela en bloquant tout le trafic non-VPN au niveau du pare-feu.

Sur le client, ajoutez des règles nftables qui n'autorisent le trafic qu'à travers l'interface WireGuard et la connexion chiffrée vers l'endpoint du serveur :

sudo nft add table inet killswitch
sudo nft add chain inet killswitch output { type filter hook output priority 0 \; policy drop \; }
sudo nft add rule inet killswitch output oifname "wg0" accept
sudo nft add rule inet killswitch output ip daddr YOUR_SERVER_PUBLIC_IP udp dport 51820 accept
sudo nft add rule inet killswitch output oifname "lo" accept

Avec cela en place, si wg0 tombe, tout le trafic sortant est bloqué. Pas de fuite DNS, pas de paquets en clair. Le seul trafic autorisé est le handshake WireGuard chiffré vers le serveur.

Supprimez le kill switch pour restaurer le routage normal :

sudo nft delete table inet killswitch

Pour un kill switch persistant qui s'active automatiquement, sauvegardez ces règles dans un fichier et chargez-les avec un service systemd qui démarre avant wg-quick@wg0.

Comment installer Tailscale sur un VPS Linux ?

Tailscale est un VPN maillé construit sur WireGuard. Il gère la distribution des clés, la traversée NAT et la découverte des pairs via un serveur de coordination. Vous installez le client, vous vous authentifiez avec votre fournisseur d'identité, et vos appareils peuvent communiquer entre eux. Pas d'échange de clés manuel, pas de redirection de port, pas de règle de pare-feu à ouvrir.

Le compromis : le serveur de coordination de Tailscale est un service tiers. Il voit les métadonnées de vos appareils (IP, noms d'hôte, quels appareils sont en ligne) mais jamais votre trafic, qui transite en pair-à-pair via WireGuard.

Comment installer Tailscale sur Ubuntu 24.04 ou Debian 12 ?

Ajoutez le dépôt officiel Tailscale et installez le paquet. Cela évite curl | sh et permet de vérifier les mises à jour via apt.

Pour Ubuntu 24.04 (Noble) :

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale -y

Pour Debian 12 (Bookworm) :

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale -y

Démarrez Tailscale et authentifiez-vous :

sudo tailscale up

Cela affiche une URL d'authentification. Ouvrez-la dans votre navigateur et connectez-vous avec votre fournisseur d'identité (Google, Microsoft, GitHub, etc.). Une fois authentifié, le VPS rejoint votre tailnet.

sudo systemctl status tailscaled

● tailscaled.service - Tailscale node agent
     Loaded: loaded (/usr/lib/systemd/system/tailscaled.service; enabled; preset: enabled)
     Active: active (running) since ...

Vérifiez l'IP Tailscale attribuée :

tailscale ip -4

100.64.0.1

Chaque appareil sur votre tailnet reçoit une adresse stable en 100.x.x.x (plage CGNAT). Cette IP persiste à travers les redémarrages et reconnexions. Utilisez-la pour joindre votre VPS depuis n'importe quel autre appareil du même tailnet.

Vérifiez la connectivité avec vos autres appareils :

tailscale status

100.64.0.1    vps-frankfurt    youruser@  linux   -
100.64.0.2    laptop           youruser@  macOS   active; direct 203.0.113.50:41641

L'indication direct signifie que le trafic transite en pair-à-pair via WireGuard. Si relay apparaît, le trafic passe par un serveur relais DERP, ce qui ajoute de la latence. Le relais DERP intervient quand les deux pairs sont derrière des NAT restrictifs qui empêchent les connexions directes.

Désactiver l'expiration des clés pour les serveurs

Les clés Tailscale expirent après 180 jours par défaut. Quand les clés expirent, l'appareil passe hors ligne jusqu'à une ré-authentification. Pour un VPS qui doit rester connecté, deux options s'offrent à vous.

Option 1 : désactiver l'expiration dans la console d'administration. Allez sur la page Machines, trouvez votre VPS, cliquez sur le menu et sélectionnez « Disable key expiry ».

Option 2 (recommandée) : utiliser une clé d'authentification avec tag. Les appareils taggués ont l'expiration automatiquement désactivée. Générez une clé d'authentification réutilisable et taggée dans la console d'administration sous Settings > Keys, puis rejoignez avec :

sudo tailscale up --auth-key=tskey-auth-XXXXX --advertise-tags=tag:server

Les tags fonctionnent aussi avec les ACL (abordées ci-dessous), ce qui en fait le meilleur choix pour l'infrastructure serveur.

Comment configurer un nœud de sortie Tailscale sur votre VPS ?

Un nœud de sortie (exit node) route tout le trafic internet de vos appareils via le VPS. Votre trafic sortant semble provenir de l'adresse IP du VPS. Cela fonctionne comme un VPN traditionnel : tout chiffrer, sortir depuis la localisation du VPS.

Activez le routage IP sur le VPS :

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Déclarez le VPS comme nœud de sortie :

sudo tailscale set --advertise-exit-node

Approuvez le nœud de sortie dans la console d'administration. Trouvez le VPS, cliquez sur le menu, allez dans « Edit route settings » et activez « Use as exit node ».

Depuis votre appareil client, activez le nœud de sortie :

sudo tailscale set --exit-node=<vps-tailscale-ip>

Pour conserver l'accès au réseau local (imprimantes, NAS, autres appareils) tout en routant le trafic internet via le nœud de sortie :

sudo tailscale set --exit-node=<vps-tailscale-ip> --exit-node-allow-lan-access=true

Pour arrêter le routage via le nœud de sortie :

sudo tailscale set --exit-node=

Confirmez le fonctionnement du nœud de sortie en vérifiant votre IP publique depuis le client :

curl -s https://ifconfig.me

Cela devrait retourner l'IP publique du VPS.

Routage de sous-réseau

Le routage de sous-réseau expose un réseau privé situé derrière le VPS à votre tailnet. C'est utile quand votre VPS peut atteindre un sous-réseau de base de données privé ou des services internes qui ne font pas tourner Tailscale.

sudo tailscale set --advertise-routes=192.168.1.0/24

Approuvez la route dans la console d'administration de la même manière que les nœuds de sortie. Une fois approuvée, tous les appareils du tailnet peuvent joindre 192.168.1.0/24 via le VPS comme passerelle, sans installer Tailscale sur chaque hôte de ce sous-réseau.

Vous pouvez déclarer plusieurs routes en les séparant par des virgules :

sudo tailscale set --advertise-routes=192.168.1.0/24,10.0.0.0/16

Pour les routeurs de sous-réseau fortement sollicités avec beaucoup de flux simultanés, Tailscale recommande le mode noyau (Linux uniquement) plutôt que le mode espace utilisateur. Sous Linux, le mode noyau est le défaut. Vérifiez avec :

tailscale debug prefs | grep RouteAll

Comment configurer les ACL Tailscale pour l'accès au VPS ?

Par défaut, tous les appareils d'un tailnet peuvent communiquer entre eux sur tous les ports. En production, restreignez cela avec les ACL dans le fichier de politique du tailnet.

Une politique minimale qui limite l'accès au VPS à un groupe admin :

{
  "groups": {
    "group:admins": ["alice@example.com", "bob@example.com"]
  },
  "tagOwners": {
    "tag:server": ["group:admins"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:admins"],
      "dst": ["tag:server:*"]
    }
  ]
}

Cela signifie : seuls les membres de group:admins peuvent accéder aux appareils taggués tag:server. Toutes les autres connexions sont refusées par défaut. Modifiez ceci dans la console d'administration sous Access Controls.

Tagguez le VPS lors de son rattachement au tailnet :

sudo tailscale up --advertise-tags=tag:server

Une politique plus granulaire peut restreindre par port :

{
  "groups": {
    "group:admins": ["alice@example.com"],
    "group:developers": ["bob@example.com", "charlie@example.com"]
  },
  "tagOwners": {
    "tag:server": ["group:admins"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:admins"],
      "dst": ["tag:server:*"]
    },
    {
      "action": "accept",
      "src": ["group:developers"],
      "dst": ["tag:server:22,80,443"]
    }
  ]
}

Les développeurs obtiennent l'accès SSH (22) et web (80, 443). Les admins ont un accès complet. Personne d'autre ne peut joindre le serveur. Tailscale applique ces règles côté client, donc le trafic est bloqué avant même d'atteindre le serveur.

MagicDNS

Tailscale inclut MagicDNS, qui attribue à chaque appareil un nom d'hôte résolvable au sein du tailnet. Au lieu de retenir 100.64.0.1, vous faites du SSH vers vps-frankfurt. Activez-le dans la console d'administration sous les paramètres DNS. Pas besoin d'Unbound ni de configuration DNS manuelle.

Qu'est-ce que Headscale et quand l'utiliser ?

Headscale est une implémentation open source et auto-hébergée du serveur de coordination Tailscale. Il utilise les clients Tailscale standards mais fait tourner le plan de contrôle sur votre propre infrastructure. Pas de limite d'appareils, pas de télémétrie, pas de dépendance au SaaS Tailscale. Compatible avec tous les clients officiels Tailscale (Linux, macOS, Windows, iOS, Android).

L'architecture :

┌─────────────┐       ┌──────────────────┐       ┌─────────────┐
│  Client A    │──────▶│   Headscale      │◀──────│  Client B    │
│  (tailscale) │       │ (votre serveur)  │       │  (tailscale) │
└──────┬───────┘       └──────────────────┘       └──────┬───────┘
       │                                                  │
       └────────────── Tunnel WireGuard ──────────────────┘
                     (direct, pair-à-pair)

Headscale gère l'échange de clés, l'enregistrement des appareils et l'application des ACL. Le trafic VPN réel circule directement entre les pairs via WireGuard. Headscale ne voit jamais vos données, seulement les métadonnées de coordination.

Ce que Headscale supporte aujourd'hui : enregistrement des appareils (CLI et OIDC), ACL, routeurs de sous-réseau, nœuds de sortie, MagicDNS, clés pré-autorisées et tags. Il couvre l'essentiel des fonctionnalités Tailscale.

Ce qu'il ne supporte pas : Tailscale Funnel, Serve, les journaux de flux réseau et certaines fonctionnalités bêta. L'interface d'administration est en ligne de commande uniquement. Des interfaces web communautaires existent (headscale-ui) mais ne couvrent pas toutes les fonctionnalités.

Quand Headscale est pertinent :

  • La réglementation interdit les serveurs de coordination tiers. Des accords de traitement des données RGPD peuvent être requis pour le SaaS Tailscale. Headscale élimine cette dépendance.
  • Vous avez besoin de plus d'appareils que ce que le plan gratuit de Tailscale autorise.
  • Vous voulez un contrôle total sur l'audit de l'enregistrement des appareils et la gestion des clés.
  • Vous construisez une infrastructure où dépendre d'un SaaS externe est un point de défaillance unique.

Quand il n'est pas adapté :

  • Vous avez besoin du réseau mondial de relais DERP de Tailscale pour une traversée NAT fiable. Headscale peut utiliser DERP, mais vous devez faire tourner vos propres relais ou accepter d'utiliser ceux de Tailscale.
  • Vous voulez une interface d'administration soignée. Headscale est orienté ligne de commande.
  • Vous avez une petite équipe et aucune envie de maintenir un service de plus.

Un tutoriel complet de mise en place de Headscale est prévu pour un prochain article. En attendant, consultez la documentation Headscale.

WireGuard vs Tailscale vs Headscale : lequel correspond à votre cas ?

Utilisez WireGuard si vous avez besoin d'un contrôle total, d'une latence minimale, de réseaux air-gapped ou de contraintes réglementaires interdisant les serveurs de coordination tiers. Utilisez Tailscale si vous gérez plusieurs appareils, avez besoin de traversée NAT sans redirection de port ou voulez des ACL sans configuration manuelle. Pour les équipes souhaitant les fonctionnalités Tailscale avec un contrôle auto-hébergé, considérez Headscale.

Dimension WireGuard Tailscale Headscale
Temps d'installation 10-15 min par pair 2 min par appareil 30-60 min (serveur + clients)
Gestion des clés Manuelle (générer, distribuer, renouveler soi-même) Automatique (serveur de coordination) Automatique (votre serveur de coordination)
Traversée NAT Aucune. Nécessite une redirection de port ou une IP publique d'au moins un côté Intégrée (relais DERP + STUN) Partielle (DERP en propre ou relais publics)
Découverte des pairs Configuration manuelle par pair Maillage automatique Maillage automatique
ACL Règles de pare-feu (nftables/iptables) Fichier de politique dans la console admin Fichier de politique sur votre serveur
Nombre d'appareils Illimité Le plan gratuit a des limites (voir la page tarifs) Illimité
Maillage multi-cloud Config sur chaque nœud, N*(N-1)/2 entrées de pairs Rejoindre le tailnet, le maillage se forme automatiquement Comme Tailscale, contrôle auto-hébergé
Dépendance tierce Aucune Tailscale Inc. (coordination uniquement) Aucune
RGPD / conformité Contrôle total, pas de sous-traitant tiers Tailscale traite les métadonnées d'appareils Contrôle total
DNS Manuel (Unbound, etc.) MagicDNS (automatique, noms par appareil) MagicDNS (avec configuration)
Latence Minimale (WireGuard au niveau noyau) Minimale en direct ; +20-50 ms via DERP Comme Tailscale
Intégration d'équipe Partager configs et clés manuellement Lien d'invitation, connexion SSO Enregistrement via CLI ou OIDC
Défense post-quantique PreSharedKey (configuration manuelle) Non configurable par l'utilisateur Non configurable par l'utilisateur

Raccourcis de décision

Développeur solo, un VPS : WireGuard. Le chemin le plus simple. Zéro dépendance. La latence la plus basse possible. Vous générez deux clés et écrivez deux fichiers de configuration.

Équipe de 3 à 15 personnes, plusieurs appareils : Tailscale. Le serveur de coordination économise des heures de gestion de clés. Les ACL sont plus propres que de maintenir des règles nftables par pair. La traversée NAT fonctionne sans modification réseau.

Environnement réglementé ou obligation d'auto-hébergement : Headscale si vous voulez l'expérience Tailscale sans la dépendance tierce. WireGuard brut si vous voulez zéro pièce mobile et que votre équipe peut gérer les configurations.

Maillage multi-cloud (5+ nœuds chez différents fournisseurs) : Tailscale ou Headscale. Avec WireGuard, 10 nœuds nécessitent 45 entrées de pairs au total. À 20 nœuds, on monte à 190. La charge de gestion de configuration croît de façon quadratique.

Accès à un endpoint d'inférence IA : Si vous créez un tunnel vers un VPS GPU depuis votre portable, les deux fonctionnent. Tailscale est plus rapide à configurer. WireGuard n'ajoute aucune surcharge mesurable pour les appels d'inférence sensibles à la latence. Pour des configurations multi-GPU chez différents fournisseurs, le maillage Tailscale vaut le compromis.

Dépannage

Tunnel WireGuard actif mais aucun trafic ne passe :

Vérifiez le routage IP :

sysctl net.ipv4.ip_forward

Devrait retourner net.ipv4.ip_forward = 1. Vérifiez que les règles de masquerade sont chargées :

sudo nft list ruleset | grep masquerade

Si vide, les règles PostUp ne se sont pas exécutées. Redémarrez avec sudo systemctl restart wg-quick@wg0 et consultez journalctl -u wg-quick@wg0 pour les erreurs.

Le handshake WireGuard ne s'établit jamais :

sudo wg show

Si latest handshake n'apparaît jamais pour un pair, le port UDP 51820 est bloqué quelque part. Confirmez que le serveur écoute :

sudo ss -ulnp | grep 51820

UNCONN 0      0        0.0.0.0:51820      0.0.0.0:*

WireGuard utilise directement le module noyau, donc ss peut ne pas afficher de nom de processus pour le socket.

Testez ensuite côté client. Si votre client est derrière un pare-feu d'entreprise, l'UDP 51820 peut être bloqué. Certains réseaux n'autorisent que le TCP 443.

Tailscale affiche « offline » dans la console d'administration :

sudo systemctl status tailscaled

Si le service tourne mais reste hors ligne, ré-authentifiez :

sudo tailscale up --force-reauth

Si tailscaled ne tourne pas, vérifiez les conflits de port avec d'autres logiciels VPN.

DNS fuit toujours après l'installation d'Unbound :

Vérifiez qu'Unbound écoute sur l'IP WireGuard :

ss -ulnp | grep :53

Cherchez 10.66.66.1:53 dans la sortie. Si Unbound ne se lie qu'à 127.0.0.1, revoyez les lignes interface: dans /etc/unbound/unbound.conf.d/wireguard.conf.

Sur Ubuntu, vérifiez aussi que systemd-resolved est bien arrêté :

sudo systemctl is-active systemd-resolved

S'il retourne active, il entre en compétition avec Unbound pour le port 53.

Journaux des services :

journalctl -u wg-quick@wg0 -f
journalctl -u tailscaled -f
journalctl -u unbound -f

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.

Prêt à essayer ?

Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD.

Voir les offres VPS