Réseau en maille WireGuard : construire un réseau Zero Trust entre serveurs et NAS avec Tailscale et Netmaker

Guide pratique pour construire un réseau en maille Zero Trust entre serveurs distants et un NAS avec WireGuard, selon deux approches concrètes : Tailscale (SaaS) et Netmaker (auto-hébergé).

Nov 6, 2026 0 3

Réseau en maille WireGuard : construire un réseau Zero Trust entre serveurs et NAS avec Tailscale et Netmaker

Relier deux serveurs avec un VPN point à point basé sur WireGuard ne prend que quelques minutes. Le problème commence quand le nombre de nœuds grimpe à cinq, dix, vingt : des serveurs cloud répartis chez différents fournisseurs, un NAS sur site, quelques Raspberry Pi et les ordinateurs portables de l'équipe. Configurer manuellement chaque paire de peers devient vite un cauchemar de clés publiques, d'adresses IP et de fichiers de configuration à mettre à jour à la main à chaque changement.

C'est là qu'intervient le mesh networking (réseau en maille) : un réseau où chaque appareil peut communiquer directement avec tout autre appareil autorisé, sans passer par un point central unique, et où l'accès ne dépend pas du fait d'être "à l'intérieur du périmètre de l'entreprise" mais de règles explicites vérifiées pour chaque connexion. Ce second principe a un nom : Zero Trust. Dans ce guide, nous allons voir comment construire concrètement un réseau en maille Zero Trust entre des serveurs distants et un NAS, en utilisant WireGuard comme fondation cryptographique et deux outils qui l'orchestrent de façon très différente : Tailscale (service SaaS) et Netmaker (auto-hébergé).

WireGuard en bref : pourquoi c'est devenu la norme

WireGuard est un protocole VPN moderne, pensé pour être facile à auditer (son code source est bien plus réduit que celui d'OpenVPN ou d'IPsec) et rapide, puisqu'il s'exécute directement dans le noyau Linux depuis la version 5.6. Il utilise des algorithmes de cryptographie modernes comme Curve25519 pour l'échange de clés et ChaCha20 pour le chiffrement du trafic, et identifie chaque appareil par une paire de clés publique/privée plutôt que par un nom d'utilisateur et un mot de passe.

La limite de WireGuard "pur" n'est pas la sécurité, mais l'organisation : par défaut, il est pensé pour des liaisons point à point. Construire un réseau en maille avec de nombreux nœuds implique de générer et distribuer manuellement les clés de chaque peer vers tous les autres, de mettre à jour les adresses AllowedIPs à chaque changement, et de tout suivre à la main. C'est exactement ce que Tailscale et Netmaker automatisent : les deux reposent sur le protocole WireGuard, mais ajoutent une couche d'orchestration automatique (distribution des clés, découverte des peers, règles d'accès) qui le rend gérable même avec des dizaines de nœuds.

Le principe Zero Trust appliqué au réseau

Le modèle de sécurité réseau traditionnel repose sur un périmètre : si un appareil est "à l'intérieur" (au bureau, sur le VPN de l'entreprise), on lui fait presque entièrement confiance. Le problème, c'est qu'une fois ce périmètre franchi - un identifiant volé, un ordinateur compromis - un attaquant a le champ libre pour se déplacer latéralement entre les systèmes.

Le principe Zero Trust inverse cette logique : aucun appareil ni utilisateur n'est automatiquement considéré comme fiable, même ceux déjà "à l'intérieur" du réseau. Chaque connexion est authentifiée et autorisée individuellement, selon le principe du moindre privilège : un serveur de sauvegarde ne doit pouvoir atteindre que le NAS sur lequel il écrit, pas la base de données de production ni le poste de l'administrateur. Appliqué à un réseau en maille WireGuard, cela se traduit concrètement par deux éléments : une identité forte pour chaque nœud (la clé publique WireGuard, unique par appareil) et un système de règles (une ACL, liste de contrôle d'accès) qui décide explicitement qui peut parler à qui, au lieu de laisser "n'importe qui sur le réseau" accéder à tout.

Tailscale et Netmaker : deux philosophies différentes

Tailscale et Netmaker construisent tous deux un réseau en maille WireGuard automatisé, mais partent de postulats opposés. Tailscale est un service SaaS : le plan de contrôle (authentification, distribution des clés, interface de gestion) est géré par les serveurs de Tailscale, tandis que le trafic entre appareils circule directement en pair-à-pair quand c'est possible. Netmaker, à l'inverse, est conçu pour être auto-hébergé : on installe le plan de contrôle (l'édition Community, gratuite et open source) sur son propre serveur, et on reste propriétaire de toute l'infrastructure, y compris des données.

Cette différence se retrouve aussi dans les tarifs. Tailscale propose un plan "Personal" gratuit pour un usage non commercial, jusqu'à 6 utilisateurs avec des appareils illimités ; les plans d'équipe démarrent à 8 dollars par utilisateur et par mois (plan Standard), jusqu'à 18 dollars pour le plan Premium destiné aux plus grandes organisations. Netmaker propose à l'inverse une Community Edition gratuite et open source, sans limite annoncée sur le nombre d'appareils ou de réseaux, avec des plans payants (Team et Business) facturés à la connexion active, à partir d'environ 2 dollars par connexion et par mois, destinés à ceux qui veulent des fonctionnalités supplémentaires comme le basculement automatique ou une gestion avancée des utilisateurs.

En pratique : pour démarrer tout de suite sans gérer de serveur supplémentaire, et si l'on est à l'aise à l'idée de confier le plan de contrôle à un prestataire externe, Tailscale est la solution la plus rapide. Si la priorité est de garder toute l'infrastructure - y compris le serveur qui décide "qui parle à qui" - sous son propre contrôle, Netmaker est à envisager, au prix d'un serveur supplémentaire à administrer.

Première voie : un réseau en maille Zero Trust avec Tailscale

Tailscale s'installe sur chaque appareil devant rejoindre le réseau (serveurs, ordinateurs portables, Raspberry Pi) via un client léger. Une fois authentifiés, les appareils obtiennent une adresse IP virtuelle stable dans la plage privée 100.64.0.0/10 (la même plage utilisée pour le CGNAT) et peuvent se joindre directement.

Exposer un NAS sans rien installer sur celui-ci

De nombreux NAS ne permettent pas d'installer directement un client Tailscale, ou l'on préfère ne pas toucher au système du fabricant. La solution est le schéma du subnet router (routeur de sous-réseau) : on installe Tailscale sur un appareil toujours allumé, situé sur le même réseau local que le NAS (un petit serveur Linux ou un Raspberry Pi, par exemple), qui fait office de "pont" pour exposer tout le sous-réseau au réseau en maille, sans que le NAS lui-même ait besoin de connaître WireGuard ou Tailscale.

Sur l'appareil-pont, après avoir activé le routage IP au niveau du système, on démarre le client avec :

tailscale up --advertise-routes=192.168.1.0/24

où 192.168.1.0/24 est le sous-réseau local sur lequel se trouve le NAS. Cette seule opération ne suffit pas : la route annoncée doit être approuvée par un administrateur dans la console web de gestion (section "Machines", appareil portant le badge "Subnets"), sauf si elle est déjà couverte par une règle autoApprovers dans le fichier de politique. Ce n'est qu'à ce moment-là que les autres nœuds du réseau en maille, s'ils sont configurés pour accepter les routes via tailscale set --accept-routes (comportement automatique sur macOS, iOS, Android et Windows), peuvent atteindre le NAS à son adresse IP locale d'origine, comme s'ils étaient sur le même réseau local.

Écrire les règles d'accès (ACL/grants)

Par défaut, un nouveau "tailnet" (nom donné par Tailscale à son réseau privé) permet à tous les appareils de se joindre mutuellement : tout est autorisé sauf les règles explicites. Pour appliquer réellement le principe Zero Trust, il faut inverser cette logique, en supprimant la règle permissive par défaut et en n'écrivant que les permissions nécessaires dans le fichier de politique, au format JSON. La syntaxe moderne s'appelle grants (préférée à l'ancien format acls, bien que les deux puissent coexister), et chaque règle précise une source, une destination et les ports autorisés :

{
  "hosts": {
    "backup-server": "100.64.0.10",
    "nas": "100.64.0.20"
  },
  "grants": [
    {
      "src": ["backup-server"],
      "dst": ["nas"],
      "ip": ["tcp:445", "tcp:22"]
    }
  ]
}

Dans cet exemple, seul le serveur de sauvegarde peut atteindre le NAS, et uniquement sur les ports SMB (445) et SSH (22) : aucun autre appareil du réseau en maille, pas même un appareil ayant un accès complet à d'autres systèmes, ne peut y accéder. Pour organiser les permissions sur plusieurs appareils, on peut utiliser des tags, attribués dans la section tagOwners de la politique : un tag transfère la "propriété" de l'appareil d'un compte humain unique vers le tag lui-même, afin que l'accès ne dépende plus de la personne qui s'est connectée à l'origine sur cette machine. Un détail pratique non négligeable : retirer un tag d'un appareil n'est pas simple - cela demande souvent de retirer le nœud du réseau et de le ré-enregistrer depuis zéro - il vaut donc la peine de bien planifier son schéma de tags avant de le mettre en production.

Accès SSH sans clés à gérer

Un avantage pratique de s'appuyer sur l'identité Tailscale pour tout le réseau est de pouvoir activer l'accès SSH "sans clé" : en l'activant sur un serveur avec tailscale set --ssh, l'authentification SSH repose sur l'identité du tailnet plutôt que sur des clés à générer, distribuer et révoquer manuellement. Les règles définissant qui peut se connecter en SSH, et avec quel utilisateur système, se définissent dans un bloc distinct de la politique :

{
  "ssh": [
    {
      "action": "check",
      "src": ["group:sysadmin"],
      "dst": ["tag:server"],
      "users": ["deploy"]
    }
  ]
}

Avec "action": "check", l'accès exige une réauthentification périodique (l'intervalle se définit avec checkPeriod), utile sur les serveurs les plus sensibles ; avec "action": "accept", l'accès est accordé immédiatement une fois l'identité vérifiée. Dans les deux cas, la configuration SSH du système d'exploitation doit elle aussi autoriser cet utilisateur spécifique.

Deux avertissements pratiques avant la mise en production : les clés des nœuds expirent par défaut après 180 jours, ce qui peut déconnecter silencieusement un subnet router ou un exit node si l'on ne désactive pas l'expiration sur les appareils jouant un rôle d'infrastructure permanente ; et les modifications de la politique prennent effet immédiatement à l'enregistrement, donc une règle trop restrictive peut couper la session SSH même en cours d'utilisation - il est toujours préférable de relire le diff des modifications avant de les confirmer.

Seconde voie : un réseau en maille auto-hébergé avec Netmaker

Si la priorité est de garder un contrôle total de l'infrastructure, Netmaker Community Edition permet d'installer son propre plan de contrôle sur un serveur, sans dépendre d'un prestataire externe pour décider qui peut accéder à quoi.

Prérequis et installation

Pour la Community Edition, Netmaker nécessite un serveur Ubuntu 24.04 (une VM, une machine physique, ou même la machine qui fait tourner les autres services), avec au minimum 1 Go de RAM, 1 CPU et 2 Go de stockage pour les tests, mais au moins 2 Go de RAM et 2 CPU pour une utilisation en production. Il faut une adresse IP publique statique et, idéalement, un nom de domaine avec accès à la gestion DNS, car le tableau de bord, l'API, le broker MQTT et les outils de supervision (Prometheus, Grafana) nécessitent chacun leur propre sous-domaine public (ou un wildcard comme *.netmaker.exemple.fr). Il faut également ouvrir les ports 80/TCP et 443/TCP pour les certificats et l'interface web, ainsi que le port 51821/UDP pour le trafic WireGuard de l'agent.

L'installation guidée de la Community Edition se résume à télécharger et exécuter le script officiel depuis le dépôt GitHub de Netmaker :

curl -sfL https://raw.githubusercontent.com/gravitl/netmaker/master/scripts/nm-quick.sh -o /root/nm-quick.sh
chmod +x /root/nm-quick.sh
sudo /root/nm-quick.sh

Le script configure automatiquement les certificats TLS (via Caddy), le broker MQTT utilisé pour la communication avec les clients, et le tableau de bord d'administration. Un avertissement utile pour ceux qui utilisent Cloudflare comme proxy DNS : il faut désactiver le proxying ("nuage gris" plutôt qu'orange) sur les enregistrements utilisés par Netmaker, sous peine de voir le trafic MQTT bloqué d'une manière que Netmaker lui-même ne peut pas diagnostiquer.

Créer le réseau et ajouter des nœuds

Lors de la première connexion au tableau de bord, on crée un compte administrateur, puis on crée un nouveau réseau en choisissant une plage d'adresses privées ne chevauchant aucun autre réseau déjà utilisé (pour des réseaux de moins de 254 machines, un bloc comme 10.11.12.0/24 est largement suffisant). Le serveur Netmaker rejoint automatiquement le réseau en tant que premier nœud.

Pour ajouter un serveur distant ou l'appareil-pont vers le NAS, on génère depuis le tableau de bord une clé d'enrôlement (section "Keys"), en définissant le nombre d'utilisations autorisées et les réseaux auxquels elle donne accès. Sur le nouvel hôte, après avoir vérifié que WireGuard et systemd sont installés, on installe le netclient correspondant à son système d'exploitation et on enregistre le nœud avec :

netclient register -k  -s grpc.mondomaine.fr -p 50051

Quelques instants plus tard, le nœud apparaît dans le tableau de bord d'administration, et l'on peut vérifier la connectivité par un simple ping vers son adresse privée dans le réseau en maille, depuis un autre nœud déjà connecté. Pour les nœuds ajoutés ultérieurement à un réseau déjà existant, on peut utiliser à la place un jeton d'enregistrement dédié, conçu spécifiquement pour ce cas.

Netmaker gère la sécurité du réseau en maille via des ACL au niveau du réseau (quels nœuds, au sein d'un même réseau virtuel, sont autorisés à se parler) et des tags pouvant être attribués aux clés d'enrôlement - un mécanisme différent, mais conceptuellement proche des grants de Tailscale : là aussi, l'objectif est d'éviter que "faire partie du réseau en maille" n'équivaille automatiquement à "avoir accès à tout".

Bonnes pratiques de sécurité, quel que soit l'outil choisi

Quelle que soit la voie choisie, certaines précautions valent pour les deux. Premièrement : désactiver l'expiration automatique des clés sur les appareils jouant un rôle d'infrastructure permanent, comme le subnet router exposant le NAS ou le serveur Netmaker lui-même - une clé expirée sans préavis sur un nœud critique signifie une interruption de service silencieuse. Deuxièmement : toujours appliquer le principe du moindre privilège lors de la rédaction des règles d'accès, en n'accordant à chaque nœud que les ports et les peers dont il a réellement besoin, et non "tout ce qu'il faut plus un peu par sécurité" - c'est exactement l'inverse de l'esprit Zero Trust. Troisièmement : maintenir à jour à la fois le client WireGuard sous-jacent et le logiciel d'orchestration (Tailscale ou le netclient de Netmaker), car les deux reçoivent périodiquement des correctifs de sécurité. Quatrièmement, et souvent sous-estimé : tester les règles d'accès avant de s'y fier en production, en vérifiant non seulement que les connexions autorisées fonctionnent, mais aussi que celles qui ne sont pas autorisées sont effectivement bloquées.

Lequel choisir ?

Il n'existe pas de réponse universelle, mais quelques repères pratiques. Pour un homelab, une petite équipe, ou pour démarrer tout de suite sans administrer de serveur supplémentaire, Tailscale offre la voie la plus rapide, un plan gratuit généreux pour un usage personnel, et une gestion des politiques suffisamment fine pour mettre en œuvre un véritable modèle Zero Trust. Pour ceux qui gèrent déjà leur propre infrastructure serveur, qui ont des exigences de conformité imposant de garder les données et le plan de contrôle sur site, ou qui préfèrent simplement ne pas dépendre d'un prestataire SaaS externe pour un élément aussi critique que l'accès au réseau, Netmaker Community Edition offre les mêmes garanties de sécurité basées sur WireGuard, au prix d'un serveur supplémentaire à administrer et à maintenir à jour. Dans les deux cas, le résultat final est le même : un réseau en maille chiffré, performant car basé sur WireGuard, et conçu selon le principe qu'aucune connexion n'est accordée par défaut, mais uniquement parce qu'elle a été explicitement autorisée.