NetBird ou Tailscale : quel VPN mesh choisir ?
NetBird et Tailscale utilisent WireGuard. Comparez leur control plane, les règles d’accès, les relays et les contraintes réelles du self-hosting.
NetBird ou Tailscale : réponse courte
Choisir entre NetBird et Tailscale revient à choisir un control plane, car ces deux VPN mesh transportent vos paquets avec WireGuard. Tailscale exploite son serveur de coordination pour vous, et ce serveur est closed source. NetBird propose le même type de service hébergé. Il publie également son serveur de management sous une licence open source, ce qui vous permet d’exécuter l’ensemble du système sur un seul VPS. Choisissez Tailscale si personne de votre côté ne doit exploiter un serveur. Choisissez NetBird si le control plane doit lui-même fonctionner sur du matériel que vous contrôlez.
Si vous comparez encore plus de deux outils, commencez par la liste plus large des alternatives à Tailscale. Les sections ci-dessous comparent directement ces deux outils sur les quatre points qui les différencient réellement.
Ce qui est identique : WireGuard en dessous
Un VPN mesh (réseau privé virtuel) connecte directement chaque appareil à tous les autres. Le trafic ne passe pas par une passerelle centrale. Les deux outils attribuent à chaque appareil une paire de clés WireGuard. La clé privée est créée sur l’appareil et ne le quitte jamais. Les deux outils tentent ensuite d’établir un tunnel direct entre deux peers. Ils utilisent un relay uniquement lorsqu’un chemin direct échoue.
Le chiffrement sur le réseau repose donc sur le même protocole dans les deux produits. Dans les deux systèmes, un relay transfère les paquets WireGuard qu’il ne peut pas déchiffrer, car il ne détient aucune clé privée. Pour disposer d’une référence sans aucun control plane, consultez ce que Tailscale ajoute à WireGuard seul.
Une différence concerne toutefois le data path. Tailscale exécute WireGuard en userspace via wireguard-go. Le README de NetBird indique que WireGuard s’exécute dans le kernel sous Linux. Ne choisissez pas uniquement sur ce critère. Exécutez iperf3 dans le tunnel sur votre propre VPS. La limite vient généralement d’abord du CPU, de la bande passante autorisée ou du chemin réseau entre les peers.
Qui gère le control plane ?
Le control plane est le serveur qui connaît la clé publique et l’adresse du tunnel de chaque appareil. Il indique à chaque appareil quels peers existent et lesquels il peut joindre. Il ne transporte pas votre trafic.
Tailscale. Le serveur de coordination est closed source. Il fonctionne uniquement comme service hébergé par Tailscale. Les clients sont open source : le daemon principal sur chaque plate-forme, ainsi que les clients Linux et Android complets. Les applications graphiques pour Windows et macOS sont closed source. Le code de DERP, le serveur relay de Tailscale, est open source. Si vous avez besoin d’un control plane compatible avec Tailscale sur votre propre serveur, Headscale est disponible. Tailscale le décrit comme un projet indépendant, maintenu par la communauté, qu’il ne dirige pas. La procédure est présentée dans exécuter Headscale comme serveur de contrôle Tailscale auto-hébergé.
NetBird. Un cloud hébergé est disponible à app.netbird.io, et le même code est publié sur GitHub pour que vous puissiez l’exécuter. En octobre 2026, le README du dépôt indique clairement les licences. Le client et la plus grande partie du dépôt sont sous licence BSD-3-Clause. Les répertoires management/, signal/ et relay/ sont sous licence AGPLv3 (GNU Affero General Public License, version 3). L’AGPL ajoute une condition. Si vous modifiez ces serveurs et permettez à d’autres personnes de les utiliser sur un réseau, vous devez leur proposer le code source que vous avez modifié.
Le côté serveur de NetBird comporte trois parties. Le service management conserve l’état du réseau : clés des peers, allocation des adresses IP, contrôle d’accès et paramètres DNS. Le service signal aide deux peers à échanger leurs candidats de connexion. Ces messages sont chiffrés entre les peers ; signal ne peut donc pas les lire. Le service relay transporte le trafic lorsqu’aucun chemin direct n’existe.
Comment écrire les règles d’accès dans chaque produit ?
Les deux produits créent un nouveau réseau avec une règle qui autorise tout. Chaque appareil peut joindre tous les autres tant que vous ne modifiez pas cette règle. Remplacez-la avant d’ajouter un serveur qui contient des données importantes.
Tailscale : un seul fichier de stratégie
Tailscale conserve toutes les règles d’accès dans le fichier de stratégie du tailnet. Il s’agit de HuJSON (human JSON), un format JSON qui autorise également les commentaires et les virgules finales. Vous pouvez le modifier dans la console d’administration ou l’envoyer via l’API. Les règles actuelles sont écrites sous la forme grants. Ce fichier permet à un groupe d’accéder aux serveurs de production marqués, uniquement en SSH et en HTTPS. Il inclut également un test :
{
"groups": {
"group:engineering": ["alice@example.com", "bob@example.com"]
},
"tagOwners": {
"tag:production": ["group:engineering"]
},
"grants": [
{
"src": ["group:engineering"],
"dst": ["tag:production"],
"ip": ["tcp:22", "tcp:443"]
}
],
"tests": [
{
"src": "alice@example.com",
"accept": ["tag:production:22"]
}
]
}La section tests est importante. Ses assertions sont exécutées comme des contrôles chaque fois que le fichier de stratégie est modifié. Une erreur de modification est donc détectée avant l’application de la stratégie. La stratégie par défaut d’un nouveau tailnet est une seule entrée acls avec "src": ["*"] et "dst": ["*:*"]. L’absence totale du champ acls signifie également que tout est autorisé. Supprimez cette entrée une fois vos autorisations en place. En octobre 2026, l’offre gratuite Personal permet de créer 3 groupes ACL.
NetBird : groupes et stratégies dans le dashboard
NetBird construit le contrôle d’accès à partir de groupes et de stratégies. Un groupe est un ensemble de peers. Vous pouvez ajouter des peers à un groupe manuellement, via les groupes associés à une setup key ou depuis les groupes d’utilisateurs de votre identity provider. Une stratégie indique un groupe source et un groupe destination. Elle peut être unidirectionnelle ou bidirectionnelle. Elle peut également limiter le protocole et les ports, avec des plages écrites sous la forme 8000-9000. Une stratégie peut aussi appliquer des contrôles de posture. Un contrôle de posture est une condition qu’un peer doit respecter avant que la connexion soit autorisée.
Vous configurez tout cela dans le dashboard. Un nouveau compte est fourni avec une stratégie nommée Default qui permet à tous les peers de communiquer entre eux. Ajoutez d’abord vos propres stratégies, puis désactivez Default. Si vous voulez gérer les règles sous forme de texte, NetBird fournit une API REST publique. Il propose également un provider Terraform officiel (netbirdio/netbird), compatible avec NetBird Cloud et avec un management server auto-hébergé. La documentation du contrôle d’accès de NetBird ne décrit pas d’assertions de test intégrées comparables à la section tests de Tailscale. Avec Terraform, vous examinez plutôt la sortie de plan.
Comment le trafic est-il relayé lorsqu’aucun chemin direct n’existe ?
Les deux outils tentent d’abord d’établir une connexion directe. Ils utilisent STUN (session traversal utilities for NAT) pour connaître l’adresse publique de chaque pair. Ils tentent ensuite d’ouvrir un chemin à travers le NAT (network address translation) des deux côtés. Les pare-feu stricts et certains réseaux mobiles bloquent cette opération. Les deux outils ont donc besoin d’une solution de secours.
Tailscale utilise alors des serveurs DERP (designated encrypted relay for packets). Tailscale en déploie dans de nombreuses régions et ils transportent le trafic via HTTPS. Cette fonction ne vous coûte rien de plus. Tailscale prend également en charge les relais de pairs. Un relais de pair est l’un de vos appareils qui sert de relais. Tailscale l’essaie avant DERP. La documentation de Tailscale présente les relais de pairs comme l’option à utiliser lorsque vous avez besoin d’une latence plus faible et d’un débit supérieur à ceux fournis par DERP. Les relais de pairs sont généralement disponibles depuis le 18 February 2026, sur tous les plans, y compris le plan gratuit. Vous pouvez en activer un avec un port UDP de votre choix et l’autoriser avec une règle dans le fichier de policy :
sudo tailscale set --relay-server-port=40000Pour voir quel chemin utilise une connexion, exécutez tailscale ping vers un pair. Une réponse indiquant via DERP(fra) signifie que la connexion est relayée. Une réponse indiquant une adresse IP et un port signifie que la connexion est directe. Si une connexion reste relayée, les raisons pour lesquelles une liaison Tailscale relayée est lente et comment en obtenir une directe détaille les causes.
NetBird relayait le trafic via le serveur TURN coturn dans les anciennes releases. La version 0.29.0 a introduit NetBird Relay, qui a depuis remplacé coturn pour les connexions relayées. Le relais accepte les connexions WebSocket sur le chemin /relay ou les connexions QUIC sur le port UDP 33080. Les recommandations actuelles déplacent également STUN dans le service de relais. Avec NetBird Cloud, NetBird gère les relais. Sur un serveur auto-hébergé, vous gérez le relais. Chaque octet relayé est décompté de la bande passante de votre VPS. Chaque chemin relayé passe par l’emplacement de ce VPS. Vérifiez le chemin utilisé pour chaque pair avec :
netbird status -dChaque pair affiche un type de connexion P2P (direct) ou Relayed.
Que recouvre l’auto-hébergement de NetBird sur un seul VPS ?
Le guide de démarrage officiel configure toute la partie serveur avec un seul script. En octobre 2026, il demande une machine Linux avec au moins 1 CPU et 2 GB de mémoire. Il faut également un nom de domaine public qui pointe vers le VPS, ainsi que Docker avec le plugin compose, jq et curl. Ouvrez les ports TCP 80, TCP 443 et UDP 3478 dans le firewall du VPS. Ouvrez-les également dans le firewall réseau de votre fournisseur, qui constitue un contrôle distinct dans la plupart des panels.
export NETBIRD_DOMAIN=netbird.example.com; curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bashLe script déploie quatre types de services :
- Traefik comme reverse proxy, avec des certificats TLS (transport layer security) de Let's Encrypt.
- Un serveur Dex intégré comme identity provider, afin de créer des utilisateurs dans le dashboard sans système de login externe.
- Les services de management, de signalisation et de relay décrits plus haut.
- Des composants optionnels : le service NetBird Proxy et le filtrage de réputation IP de CrowdSec.
Vous devez désormais administrer chaque composant. L'identity provider détermine qui peut se connecter et ajouter des appareils. Dex suffit pour une petite équipe. Vous pourrez connecter ultérieurement un fournisseur externe de single sign-on, par exemple un serveur SSO Authentik auto-hébergé. TLS dépend de l'ordre des opérations. Let's Encrypt valide le domaine en se connectant à ce VPS. Créez donc l'enregistrement DNS et ouvrez les ports avant d'exécuter le script. Si le domaine ne pointe pas encore vers le VPS, la validation échoue et aucun certificat n'est émis. Les sauvegardes et les mises à niveau sont également à votre charge. L'installation complète, avec une vérification après chaque étape, est présentée dans le guide pour auto-héberger un serveur VPN NetBird.
Inscrire un serveur Linux dans chacun
Rejoindre un mesh nécessite un accès réseau sortant vers le control plane. Exécutez donc ces commandes sur votre propre machine. Un serveur n’a pas de navigateur. Les deux outils utilisent donc une clé créée à l’avance au lieu d’une connexion interactive.
Tailscale, avec une auth key générée depuis la console d’administration :
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --auth-key=YOUR_AUTH_KEY
tailscale statustailscale status doit afficher cette machine avec une adresse 100.x.y.z, ainsi que les autres appareils de votre tailnet. Une auth key sans date d’expiration expire après 90 jours, ce qui est la durée maximale. Un serveur déjà inscrit reste inscrit. Un script qui inscrit de nouveaux serveurs doit utiliser une nouvelle clé.
NetBird, avec une setup key générée depuis le dashboard :
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --setup-key YOUR_SETUP_KEY
netbird statusSur un serveur auto-hébergé, ajoutez --management-url https://netbird.example.com à la ligne netbird up. Sinon, le client contacte NetBird Cloud, qui ne connaît pas une setup key créée sur votre propre serveur. netbird status doit indiquer que les services de management et de signal sont connectés.
Tarifs et offres gratuites, en octobre 2026
Ces chiffres proviennent des deux pages tarifaires consultées le 2 octobre 2026. Les tarifs évoluent. Vérifiez-les à nouveau avant de vous engager.
Tailscale Personal est gratuit jusqu’à 6 utilisateurs, avec un nombre illimité d’appareils par utilisateur. L’offre inclut 50 ressources marquées (des serveurs associés à un tag plutôt qu’à une personne) et 3 groupes ACL. Les offres payantes sont Standard à $8 par utilisateur et par mois, et Premium à $18. Le tarif Enterprise est communiqué sur demande. La répartition de ce qu’un foyer ou une petite équipe paie réellement pour Tailscale couvre les cas particuliers.
NetBird Cloud est gratuit jusqu’à 5 utilisateurs et 100 machines. L’offre Team coûte €6 par utilisateur et par mois, et l’offre Business €12. Le tarif Enterprise est communiqué sur demande. Les offres payantes incluent 100 machines, plus 10 machines par utilisateur. Chaque machine supplémentaire coûte €0.50 par mois. Self-hosted NetBird n’a aucun frais de licence. Vous payez le VPS et le temps nécessaire à son exploitation.
Choisissez Tailscale si...
- Personne dans votre équipe ne veut administrer, mettre à jour ou sauvegarder un serveur de contrôle.
- Vous voulez gérer les règles d’accès dans un seul fichier texte, avec des tests qui détectent une modification incorrecte avant son application.
- Vos utilisateurs se déplacent et se connectent depuis des réseaux d’hôtel ou mobiles. Dans ce cas, les serveurs DERP de Tailscale répartis dans plusieurs régions fournissent un relais de secours proche, sans configuration supplémentaire.
- Votre groupe correspond à l’offre gratuite de 6 utilisateurs ou le prix par utilisateur vous convient.
Choisissez NetBird si...
- Le control plane doit s’exécuter sur une infrastructure que vous possédez, avec le projet officiel plutôt qu’une réimplémentation distincte.
- Vous devez connecter plus de 6 personnes sur un réseau self-hosted sans frais par utilisateur.
- Votre équipe préfère gérer les groupes et les policies dans un dashboard, ou utilise déjà Terraform pour tout le reste.
- Vous voulez commencer avec NetBird Cloud tout en conservant la possibilité de migrer vers votre propre serveur, avec le même client.
Ce qui manque à chaque solution
Chaque élément ci-dessous provient de la documentation ou de la page tarifaire du fournisseur, vérifiée le 2 octobre 2026.
Tailscale n’a pas :
- De serveur de contrôle officiellement auto-hébergé. Le serveur de coordination est propriétaire, et Headscale est un projet communautaire distinct.
- De clients graphiques open source pour Windows et macOS. Le daemon sous-jacent est open source, mais pas les applications.
NetBird n’a pas :
- D’assertions de test intégrées pour les règles d’accès. Sa documentation sur le contrôle d’accès n’en décrit aucune. La vérification des règles dépend donc de vous ou des plans Terraform.
- De relais gérés par un tiers lorsque vous l’auto-hébergez. Votre relais se trouve sur votre VPS. Un pair éloigné de ce VPS emprunte un chemin relayé long, et vous payez la bande passante.
Les deux solutions commencent avec une règle qui autorise tout. Un nouveau réseau est donc entièrement ouvert tant que vous n’avez pas écrit de règles. Pour le modèle de menace complet du côté hébergé, voir ce qu’un plan de contrôle hébergé peut et ne peut pas voir.
FAQ
NetBird est-il entièrement open source ?
Oui, mais sous deux licences. En octobre 2026, le README de NetBird indique que le client et la majeure partie du dépôt sont sous licence BSD-3-Clause. Les répertoires management/, signal/ et relay/ sont sous licence AGPLv3. Si vous modifiez ces composants serveur et permettez à d’autres personnes de les utiliser sur un réseau, l’AGPL vous oblige à leur proposer le code source que vous avez modifié.
Puis-je auto-héberger le serveur de contrôle de Tailscale comme celui de NetBird ?
Non. Le serveur de coordination de Tailscale est closed source et fonctionne uniquement comme service hébergé. Le remplacement auto-hébergé habituel est Headscale, un serveur de coordination open source indépendant qui fonctionne avec les clients Tailscale officiels. Tailscale emploie le mainteneur principal de Headscale, mais indique ne pas diriger le projet.
Le relay peut-il lire mon trafic dans NetBird ou Tailscale ?
Non. Dans les deux produits, la clé privée WireGuard est créée sur l’appareil et ne le quitte jamais. Un serveur Tailscale DERP, un peer relay Tailscale et un relay NetBird ne transmettent que des paquets WireGuard chiffrés. Le relay peut toutefois voir avec quels peers il établit des connexions et quelle quantité de données transite entre eux.
De quel VPS ai-je besoin pour auto-héberger NetBird ?
En octobre 2026, le quickstart officiel demande au minimum 1 CPU et 2 GB de mémoire. Il faut également un domaine public qui pointe vers le VPS, Docker avec le plugin compose, ainsi que les ports TCP 80, TCP 443 et UDP 3478 ouverts. Prévoyez aussi de la bande passante pour le trafic relayé. Sur un serveur auto-hébergé, chaque connexion relayée transite par votre VPS.
Lequel propose le forfait gratuit le plus avantageux ?
En octobre 2026, Tailscale Personal autorise jusqu’à 6 utilisateurs avec un nombre illimité d’appareils par utilisateur. Le forfait gratuit NetBird Cloud autorise jusqu’à 5 utilisateurs et 100 machines. Un serveur NetBird auto-hébergé n’impose aucune limite d’utilisateurs et ne facture aucune licence, mais vous payez le VPS et vous l’administrez vous-même.