[{"data":1,"prerenderedAt":214},["ShallowReactive",2],{"seo-verification":3,"blog-deployer-netbird-controle-vpn-mesh-vps-ma-fr":6,"promo-bar-likely":213},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-deployer-netbird-controle-vpn-mesh-vps-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":148,"ctaBody":149,"ctaButton":150,"ctaUrl":151,"relatedPosts":152},291,"deployer-netbird-controle-vpn-mesh-vps",{"fr":10,"en":12,"ar":13,"es":14},"netbird-self-hosted-wireguard-mesh-vpn-on-a-vps","netbird-شبكة-vpn-مشبكة-wireguard-باستضافة-ذاتية","desplegar-netbird-vpn-mesh-wireguard-en-vps","Netbird : réseau mesh WireGuard auto-hébergé sur VPS","Reliez des VPS clients sans ouvrir de port : déployez le plan de contrôle Netbird (serveur combiné, relais, interface web) et isolez chaque client.",18,4,false,"2026-08-21T00:00:00+00:00","2026-11-09T20:55:15+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},3,"Déploiement","deploiement","bg-success\u002F10 text-success",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdeployer-netbird-controle-vpn-mesh-vps-poster.svg","Vous gérez des serveurs répartis sur plusieurs comptes clients et vous vous retrouvez à ouvrir des ports, à maintenir des règles UFW distinctes ou à distribuer des clés WireGuard statiques à la main. Headscale répond au même besoin pour un réseau plat — nous y avons consacré \u003Ca href=\"\u002Fblog\u002Fself-host-headscale-tailscale-vps\">un guide dédié\u003C\u002Fa>. Netbird est une autre réponse, conçue pour la gestion de plusieurs réseaux isolés : groupes de pairs, règles d'accès par réseau et interface web incluse. Ce guide déploie le plan de contrôle Netbird (plus de 30 000 étoiles sur GitHub, AGPLv3 côté serveur) sur un VPS dédié, raccorde trois nœuds en mesh sans ouvrir un seul port public, puis couvre l'isolation par client, la publication d'un service avec `netbird expose` et le dépannage.",[34,38,41,44,69,72,75,78,112,115,119,122,125,134,137,145],{"type":35,"title":36,"body":37},"h2","WireGuard P2P, Headscale, Netbird : trois angles différents","WireGuard statique (voir \u003Ca href=\"\u002Fblog\u002Finstaller-wireguard-vps\">notre guide WireGuard\u003C\u002Fa>) repose sur une configuration figée : chaque pair doit connaître la clé publique et l'adresse joignable de ses homologues, et chaque nouvel homologue impose d'éditer `\u002Fetc\u002Fwireguard\u002Fwg0.conf` sur les autres. Efficace pour deux ou trois serveurs fixes. Ingérable dès qu'un parc d'agence mêle des VPS, des postes nomades et des bureaux derrière un CGNAT : ajouter une machine, c'est retoucher toutes les autres ; retirer un technicien, c'est révoquer sa clé partout.\n\nHeadscale réimplémente le serveur de coordination Tailscale : vous gardez les clients Tailscale officiels et obtenez un réseau plat sans plafond d'utilisateurs. L'isolation entre clients passe par un fichier de politique ACL unique pour tout le réseau. C'est le bon choix pour une équipe unique qui veut rester dans l'écosystème Tailscale.\n\nNetbird prend le parti inverse : il apporte son propre client, son propre plan de contrôle et une notion de **groupes** reliés par des règles d'accès granulaires, gérées depuis l'interface web incluse d'emblée. Une instance unique peut héberger plusieurs parcs entièrement cloisonnés, ce qui en fait l'outil naturel pour une agence qui gère des clients séparés.",{"type":35,"title":39,"body":40},"Architecture Netbird : un serveur combiné","Le script d'installation actuel ne déploie plus quatre conteneurs séparés. Il génère une stack Docker Compose de trois services :\n\n**`netbird-server`** — le serveur combiné. Il réunit dans un seul conteneur le **Management** (distribution des clés WireGuard, application des règles d'accès, API REST), le **Signal** (échange des descripteurs de connexion ICE entre pairs), le **Relay** et un serveur **STUN** intégré. Il se configure par un unique `config.yaml`, qui remplace les anciens `management.json` et `relay.env`. Stockage SQLite par défaut, PostgreSQL en option.\n\n**`netbird-dashboard`** — l'interface web qui consomme l'API Management : groupes, pairs, règles d'accès, clés d'enrôlement, sans ligne de commande.\n\n**`netbird-traefik`** — le reverse proxy qui termine le TLS (certificat Let's Encrypt automatique) et route le gRPC, le WebSocket et l'API vers le serveur.\n\nDeux changements comptent par rapport aux anciens tutoriels. Le relais n'est plus COTURN : depuis la v0.29, Netbird utilise sa propre implémentation, qui fait passer les connexions relayées par le port 443 (WebSocket sur TCP, ou QUIC sur UDP) au lieu d'allouer une plage de ports UDP. Et l'authentification est intégrée : depuis la v0.62, un fournisseur d'identité embarqué (basé sur Dex) gère les utilisateurs locaux, sans Zitadel ni Keycloak à déployer. Un cinquième service, le **proxy Netbird**, s'ajoute si vous l'activez pour publier des services sur Internet (voir plus bas).\n\nTous les flux entre clients passent en **WireGuard chiffré de bout en bout** : le serveur ne voit que les métadonnées d'enrôlement, jamais le trafic applicatif. Côté licences, le client est sous BSD-3-Clause ; les répertoires `management\u002F`, `signal\u002F`, `relay\u002F` et `combined\u002F` du dépôt sont sous AGPLv3.",{"type":35,"title":42,"body":43},"Prérequis","**VPS dédié au plan de contrôle.** Prévoyez un VPS distinct de vos nœuds clients. La documentation Netbird demande au moins 1 vCPU et 2 Go de RAM ; un VPS Solo convient pour démarrer.\n\n**Ports à ouvrir sur le VPS de contrôle :**\n\n`80` (TCP) — validation Let's Encrypt et redirection vers HTTPS.\n`443` (TCP) — Dashboard, API et gRPC Management, Signal, Relay en WebSocket.\n`3478` (UDP) — STUN intégré au serveur.\n\nLa plage `49152-65535` en UDP n'est plus nécessaire : elle ne servait qu'au relais COTURN des versions antérieures à la v0.29, et ne reste ouverte que si d'anciens clients en dépendent encore. Les nœuds clients n'ont **aucun port entrant à ouvrir** : le client Netbird établit des connexions sortantes vers le plan de contrôle.\n\n**Logiciels requis sur le VPS de contrôle :** Docker avec le plugin Compose, `jq` et `curl`, et un nom de domaine dont l'enregistrement A pointe vers l'IP du VPS (`netbird.votre-domaine.com`). Si vous activez le proxy Netbird, ajoutez un CNAME `*.netbird` vers ce même nom. Derrière Cloudflare, la documentation Netbird prévoit ces deux enregistrements en DNS seul.\n\n**Sur chaque nœud client :** le client `netbird` (paquet Debian\u002FRPM ou binaire statique), accès root ou sudo.",{"type":45,"title":46,"steps":47},"steps","Déployer le plan de contrôle et raccorder trois nœuds",[48,51,54,57,60,63,66],{"title":49,"body":50},"Lancer le script d'installation","Sur le VPS de contrôle, téléchargez le script officiel et exécutez-le :\n\n```bash\ncurl -fsSL https:\u002F\u002Fgithub.com\u002Fnetbirdio\u002Fnetbird\u002Freleases\u002Flatest\u002Fdownload\u002Fgetting-started.sh | bash\n```\n\nLe script demande votre domaine (`netbird.votre-domaine.com`), puis le reverse proxy à utiliser : gardez l'option `[0]` (Traefik intégré, TLS automatique). Il propose ensuite d'activer le proxy Netbird, que vous pourrez ajouter plus tard. Il génère `docker-compose.yml`, `config.yaml` et `dashboard.env` (plus `proxy.env` si le proxy est activé), puis démarre la stack. Pour une installation sans questions (cloud-init, CI), exportez au préalable `NETBIRD_DOMAIN`, `NETBIRD_LETSENCRYPT_EMAIL` et `NETBIRD_NON_INTERACTIVE=true`.",{"title":52,"body":53},"Vérifier que les services répondent","Depuis le répertoire d'installation, confirmez que les conteneurs sont debout :\n\n```bash\ndocker compose ps\n```\n\nVous devez voir `netbird-traefik`, `netbird-dashboard` et `netbird-server` en état `running` (plus le proxy s'il est activé). En cas de doute, la plupart des erreurs de configuration apparaissent dans le journal du serveur :\n\n```bash\ndocker compose logs -f netbird-server\n```",{"title":55,"body":56},"Créer le compte administrateur et une Setup Key","Ouvrez `https:\u002F\u002Fnetbird.votre-domaine.com` dans un navigateur. Le script déploie Netbird **sans aucun utilisateur** : vous êtes redirigé vers la page `\u002Fsetup`, où vous créez le compte administrateur (e-mail, nom, mot de passe). Cette page n'est accessible que tant qu'aucun utilisateur n'existe.\n\nDans le menu **Setup Keys**, cliquez **Create Setup Key**. Donnez-lui un nom (`vps-client-a`), choisissez le type `Reusable` (pour enrôler plusieurs machines avec la même clé) et une durée d'expiration. Copiez la clé : vous en aurez besoin sur chaque nœud.",{"title":58,"body":59},"Enrôler le nœud 1","Sur le premier VPS client, installez le client Netbird :\n\n```bash\ncurl -fsSL https:\u002F\u002Fpkgs.netbird.io\u002Finstall.sh | sh\n```\n\nPuis raccordez-le au plan de contrôle en pointant vers votre instance (sans `--management-url`, le client vise le service cloud de Netbird) :\n\n```bash\nnetbird up \\\n  --management-url https:\u002F\u002Fnetbird.votre-domaine.com \\\n  --setup-key \u003CVOTRE_SETUP_KEY>\n```\n\nConfirmez la connexion :\n\n```bash\nnetbird status\n```\n\nVous devez lire `Management: Connected` et `Signal: Connected`, ainsi qu'une IP mesh dans la plage `100.64.x.x` attribuée par votre serveur.",{"title":61,"body":62},"Enrôler les nœuds 2 et 3","Répétez exactement la même procédure sur les deux autres VPS clients. Même commande `curl` pour installer le client, même commande `netbird up` avec le même `--management-url` et la même `--setup-key` (si elle est de type `Reusable`).\n\nUne fois les trois nœuds enrôlés, vérifiez depuis le nœud 1 que les pairs sont visibles :\n\n```bash\nnetbird status --detail\n```\n\nLa sortie liste chaque pair avec son IP mesh, son état et sa latence. Depuis la v0.82, `netbird status --table` présente la même information sous forme de tableau.",{"title":64,"body":65},"Tester la connectivité mesh sans port public ouvert","Avant de tester, vérifiez l'état du pare-feu sur le nœud 1 — aucun port entrant ne doit être ouvert vers les autres nœuds :\n\n```bash\nsudo ufw status numbered\n```\n\nSeul le port SSH (22) doit apparaître. Pinguez maintenant le nœud 2 via son IP mesh (visible dans `netbird status --detail`, par exemple `100.64.0.2`) :\n\n```bash\nping -c 3 100.64.0.2\n```\n\nLe ping traverse le tunnel WireGuard établi entre les pairs. Si une connexion directe est impossible, le relais intégré au serveur prend le relais sur le port 443 : le ping fonctionne dans les deux cas, sans aucune règle UFW supplémentaire.",{"title":67,"body":68},"Distinguer connexions directes et relayées","Pour savoir si un pair passe en direct ou par le relais :\n\n```bash\nnetbird status --detail\n```\n\nLe champ `Connection type` affiche `P2P` pour une connexion directe ou `Relayed` lorsque le trafic transite par le relais. Pour ne lister que les pairs relayés :\n\n```bash\nnetbird status -d --filter-by-connection-type Relayed\n```\n\n`P2P` est l'état attendu entre deux VPS dotés d'une IPv4 publique. `Relayed` reste chiffré de bout en bout, mais ajoute de la latence : la section Dépannage indique quoi vérifier.",{"type":35,"title":70,"body":71},"Isolation multi-clients : groupes et règles d'accès","La force de Netbird face à Headscale est le cloisonnement par **groupe**, piloté depuis l'interface. Un point à connaître d'abord : à la création du compte, Netbird pose une politique **Default** qui autorise tous les pairs du groupe spécial `All` à communiquer entre eux. Tant qu'elle existe, aucune isolation ne tient. Pour séparer les serveurs du client A de ceux du client B :\n\n**1. Créez un groupe par client** dans l'interface web (`client-a`, `client-b`) et un groupe `agence-ops` pour les postes de l'équipe.\n\n**2. Assignez chaque pair à son groupe.** Dans la fiche du pair, section des groupes, ajoutez le groupe correspondant. Une Setup Key peut aussi attribuer un groupe automatiquement à chaque machine enrôlée avec elle : prévoyez une clé par client.\n\n**3. Définissez les règles d'accès** (Access Control → Policies). Une politique `client-a-interne` autorise le trafic entre pairs du groupe `client-a`. Une politique `ops-ssh` autorise le seul groupe `agence-ops` à joindre le port 22 des groupes clients : un poste compromis dans le mesh ne peut alors pas servir de rebond vers tous les VPS. Aucune règle n'est créée entre `client-a` et `client-b`.\n\n**4. Supprimez la politique Default**, une fois les politiques de remplacement en place. Dans l'autre ordre, toute communication entre pairs s'arrête.\n\nRésultat : le poste d'un administrateur du client A joint le VPS A par son IP mesh mais ne voit pas le VPS B, et le groupe `agence-ops` reste le seul membre transversal. Vous pouvez aussi définir des **Network Routes** : un pair joue le rôle de routeur pour un sous-réseau privé (ex. `192.168.10.0\u002F24`) et l'expose aux autres pairs du groupe, sans client Netbird sur chaque machine de ce sous-réseau.",{"type":35,"title":73,"body":74},"Fermer le SSH public : n'écouter que sur l'interface mesh","Une fois les nœuds enrôlés, l'administration n'a plus besoin d'un port SSH ouvert sur Internet : `ssh admin@100.64.0.2` transite entièrement dans le tunnel chiffré. Le client Netbird crée l'interface WireGuard `wt0` (nom par défaut) ; autorisez SSH sur cette interface, puis refusez-le ailleurs :\n\n```bash\nsudo ufw allow in on wt0 to any port 22 proto tcp\nsudo ufw deny 22\u002Ftcp\nsudo ufw status numbered\n```\n\nUFW applique la première règle qui correspond : la règle `wt0` doit apparaître avant le refus. Gardez votre session SSH en cours ouverte et testez une nouvelle connexion par l'IP mesh avant de la fermer : si le tunnel ne monte pas, vous gardez une porte de sortie. La politique `ops-ssh` vue plus haut limite ensuite qui, dans le mesh, peut atteindre ce port.",{"type":35,"title":76,"body":77},"`netbird expose` : publier un service local sans ouvrir de port","Le mesh relie vos machines entre elles. Pour rendre un service accessible **depuis Internet** sans toucher au pare-feu du VPS, Netbird propose depuis la v0.66 (février 2026) la commande `netbird expose`. Elle s'appuie sur le proxy Netbird : sur une instance auto-hébergée, il doit être activé (à l'installation ou plus tard), avec un enregistrement DNS wildcard vers le serveur.\n\nUn administrateur doit d'abord autoriser la fonction : **Settings → Clients → Peer Expose**, en limitant si besoin les groupes de pairs autorisés. Ensuite, sur le VPS où tourne par exemple un Grafana en `127.0.0.1:3000` :\n\n```bash\nnetbird expose 3000 --with-name-prefix grafana --with-user-groups supervision-admins\n```\n\nLa commande affiche une URL publique sur le domaine du proxy et garde la session ouverte ; `Ctrl+C` la retire. Le service est **éphémère** : le client le renouvelle toutes les 30 secondes, et le serveur le supprime environ 90 à 120 secondes après le dernier renouvellement si le client disparaît. Le port 3000 reste fermé sur le pare-feu du VPS.\n\nSans option d'authentification, l'URL est **publique** pour quiconque la connaît. Trois protections existent pour le HTTP : `--with-user-groups` (connexion SSO, réservée aux groupes cités), `--with-password \u003Cmot-de-passe>` (mot de passe que vous choisissez) et `--with-pin \u003C6 chiffres>`. `--protocol tcp` publie un service non HTTP, sans authentification possible. Chaque pair peut tenir 10 sessions simultanées, et la commande échoue si l'option Block Inbound Connections est active sur le pair. Pour un service permanent, créez-le plutôt dans le Dashboard.",{"type":79,"title":80,"headers":81,"rows":86},"comparison","Netbird, Headscale et WireGuard manuel en un coup d'œil",[82,83,84,85],"Critère","Netbird auto-hébergé","Headscale","WireGuard manuel",[87,92,97,102,107],[88,89,90,91],"Gestion des pairs","Automatique, plan de contrôle et interface web","Automatique, clients Tailscale officiels","Manuelle, fichier `wg0.conf` sur chaque nœud",[93,94,95,96],"NAT et CGNAT","STUN intégré, relais sur le port 443","Serveurs DERP (serveur DERP intégré en option)","Exige une IP publique ou une redirection de port",[98,99,100,101],"Cloisonnement","Groupes et politiques dans l'interface","Fichier de politique ACL (HuJSON)","Aucun, en dehors des `AllowedIPs` de chaque pair",[103,104,105,106],"Publication d'un service","`netbird expose` ou proxy Netbird","Non intégré","Tunnel SSH ou reverse proxy à monter soi-même",[108,109,110,111],"Licence","BSD-3 (client), AGPLv3 (serveur)","BSD-3-Clause","Libre (noyau Linux et outils)",{"type":35,"title":113,"body":114},"Opérations courantes","**Renouveler ou révoquer une Setup Key.** Dans l'interface web, Setup Keys → votre clé → Revoke. Les pairs déjà enrôlés conservent leur connexion ; les nouvelles tentatives d'enrôlement avec cette clé sont refusées. Créez une nouvelle clé pour les prochains enrôlements.\n\n**Révoquer un pair.** Peers → sélectionnez le pair → Delete. Le nœud est retiré du mesh ; côté client, la connexion au Management tombe et les tunnels WireGuard vers ce pair sont détruits.\n\n**Accès API pour l'automatisation.** Netbird expose une API REST documentée. Créez un utilisateur de service (Team → Service Users) et son jeton d'accès, puis pilotez l'ensemble depuis vos scripts Ansible ou vos pipelines CI :\n\n```bash\ncurl -s https:\u002F\u002Fnetbird.votre-domaine.com\u002Fapi\u002Fpeers \\\n  -H 'Authorization: Token \u003CPAT>'\n```\n\n**Monitoring.** Le serveur combiné expose ses métriques Prometheus sur `\u002Fmetrics`, port `9090` par défaut (clé `server.metricsPort` de `config.yaml`) : une seule cible de scrape couvre Management, Signal et Relay. Branchez Grafana dessus pour suivre les pairs connectés et l'activité du relais.\n\n**Mettre à jour.** Depuis le répertoire d'installation, tirez les nouvelles images puis recréez les conteneurs :\n\n```bash\ndocker compose pull netbird-server dashboard\ndocker compose up -d --force-recreate netbird-server dashboard\n```\n\nAjoutez `proxy` aux deux commandes s'il est activé. Si `docker-compose.yml` épingle des versions, modifiez d'abord les étiquettes `image:` : `docker compose pull` ne les change pas. Les pairs perdent le plan de contrôle quelques secondes pendant le redémarrage ; planifiez l'opération hors des heures chargées. Traefik se met à jour séparément de Netbird.",{"type":116,"title":117,"body":118},"tip","Durcissement : MFA sur le Dashboard et sauvegarde des données","Le fournisseur d'identité embarqué gère la double authentification des comptes locaux : **Settings → Authentication → Local MFA** impose un code TOTP à chaque utilisateur. Vous pouvez aussi brancher un fournisseur OIDC (Keycloak, Authentik, Microsoft Entra ID…) et y appliquer votre propre politique MFA.\n\nL'état persistant de votre réseau (base Management, clés de chiffrement) vit dans le volume Docker `netbird_data`, monté sur `\u002Fvar\u002Flib\u002Fnetbird` : le perdre signifie réenrôler tous vos pairs. Arrêtez la stack pour obtenir une copie cohérente, sauvegardez les fichiers de configuration et le volume, puis redémarrez :\n\n```bash\ndocker compose stop\nmkdir -p backup\ncp docker-compose.yml config.yaml dashboard.env backup\u002F\ndocker compose cp -a netbird-server:\u002Fvar\u002Flib\u002Fnetbird\u002F backup\u002F\ndocker compose start\n```\n\nSi le proxy est activé, ajoutez `proxy.env` et `traefik-dynamic.yaml`. Conservez au moins sept jours de sauvegardes, hors du VPS.",{"type":35,"title":120,"body":121},"Dépannage","**Pairs bloqués en `Relayed`.**\nLe relais fonctionne, mais la connexion directe échoue. Vérifiez d'abord que le port UDP 3478 du VPS de contrôle est ouvert (`ufw status`), puis que les nœuds peuvent émettre de l'UDP sortant. Sur un VPS doté d'une IP publique, sans NAT, un pare-feu d'hôte qui refuse l'UDP entrant non sollicité suffit à faire échouer la connexion directe ; la documentation Netbird propose alors `sudo ufw allow in proto udp to any port 49152:65535`, au prix d'une ouverture plus large, ou d'accepter le relais. Un pair `Connected` qui ne répond pas au ping signale souvent le même blocage, côté interface `wt0`.\n\n**UDP bloqué par un réseau d'entreprise.**\nRien à configurer : depuis la v0.36, le client essaie le relais en QUIC (UDP\u002F443) et en WebSocket (TCP\u002F443), et garde le premier qui répond. Si seul le TCP\u002F443 sortant passe, le pair reste connecté, en mode relayé.\n\n**Pair bloqué en `Connecting`.**\nL'enrôlement a réussi mais le tunnel ne se forme pas. Contrôlez que `netbird status` affiche bien `Signal: Connected`, que le serveur annonce une adresse publique correcte (champ `exposedAddress` de `config.yaml`) et que les ports 443\u002FTCP et 3478\u002FUDP sont joignables depuis le nœud.\n\n**Lire les journaux.**\nCôté serveur, `docker compose logs -f netbird-server`. Côté client, le journal est écrit par défaut dans `\u002Fvar\u002Flog\u002Fnetbird\u002Fclient.log`. Pour un diagnostic complet, `netbird debug for 5m` passe le client en journalisation détaillée pendant cinq minutes puis produit une archive de diagnostic (`netbird debug bundle` la produit immédiatement).\n\n**Résolution DNS entre pairs.**\nNetbird attribue un nom DNS à chaque pair, visible dans le champ **Domain Name** de sa fiche. Si le ping par nom échoue alors que `ping 100.64.0.2` fonctionne, vérifiez que le service tourne sur le pair (`sudo netbird service status`) et que le DNS du système passe bien par Netbird (`resolvectl status`).",{"type":35,"title":123,"body":124},"Proxy Netbird bloqué sur « Issuing certificate… »","Quand le proxy est activé, un symptôme revient : le service créé reste sur « Issuing certificate… » (statut `certificate_pending`, ou `certificate_failed`) et n'est jamais joignable. Le ticket netbird #5517, ouvert le 5 mars 2026, est toujours ouvert au 7 novembre 2026 avec 36 commentaires et l'étiquette `triage-needed`. Le message le plus fréquent dans le journal du proxy, `no viable challenge type found`, dit seulement que l'autorité de certification n'a obtenu aucune réponse valide à ses défis : il n'existe pas de cause unique. Commencez par lire le journal (`docker compose logs proxy | grep -i acme`) et notez l'erreur exacte, puis éliminez les causes une à une.",{"type":126,"title":127,"items":128},"ul","Ordre de diagnostic d'un certificat qui ne sort pas",[129,130,131,132,133],"**Droits du dossier des certificats** — une erreur `permission denied` sur `\u002Fcerts` est le seul cas tranché par un collaborateur du dépôt : aucune mise à jour ne la corrigera, ce sont les permissions du système de fichiers. Vérifiez l'utilisateur sous lequel tourne le conteneur avant de changer les droits.","**DNS, CAA et ports** — le nom doit résoudre vers le proxy et aucun enregistrement CAA ne doit exclure Let's Encrypt. Le port 443 doit être joignable depuis Internet pour le défi `tls-alpn-01` (par défaut), le port 80 pour `http-01`. Let's Encrypt valide depuis plusieurs régions du monde : un filtrage géographique fait échouer la validation.","**CDN ou proxy en amont** — Cloudflare et certains équipements ne transmettent pas le protocole ALPN `acme-tls\u002F1`. Passez alors à `NB_PROXY_ACME_CHALLENGE_TYPE=http-01` dans `proxy.env`.","**Traefik en tête** — si Traefik relaie le TLS vers le proxy en passthrough, son point d'entrée HTTPS doit porter `allowACMEByPass=true`, que le script d'installation pose sur `websecure`. Sur un Traefik existant, utilisez le nom de votre propre point d'entrée ; des participants du ticket ont dû l'ajouter aussi au point d'entrée HTTP, d'autres l'avaient déjà sans résultat.","**Ce qui n'est pas établi** — aucune de ces pistes n'est « la » cause : testez-les sur votre installation avant de conclure.",{"type":35,"title":135,"body":136},"Origine fermée : le certificat par DNS-01 avec lego","Les défis `tls-alpn-01` et `http-01` exigent que l'autorité joigne votre proxy depuis Internet, ce qui s'oppose à une origine fermée aux plages d'un CDN ou à un filtrage géographique. Le défi `dns-01` lève cette contrainte : il prouve la maîtrise du domaine par un enregistrement TXT temporaire, créé via l'API de votre fournisseur DNS. Le proxy Netbird ne l'intègre pas nativement : la demande (ticket #5450, ouvert le 25 février 2026) est toujours ouverte. La documentation Netbird décrit en revanche un montage « private proxy with lego » : lego obtient et renouvelle un certificat wildcard par DNS-01, un hook de déploiement le dépose dans un volume partagé, et le proxy le recharge à chaud après chaque renouvellement.",{"type":126,"title":138,"items":139},"Points d'attention du montage lego",[140,141,142,143,144],"**Variables du proxy** — `NB_PROXY_WILDCARD_CERT_DIR` désigne le dossier des certificats wildcard, `NB_PROXY_PRIVATE=true` active les écoutes privées sur le mesh. Épinglez une image du proxy qui connaît ces deux variables.","**Le mode privé ne ferme rien seul** — `NB_PROXY_PRIVATE` ne désactive pas l'écoute ordinaire du proxy. Retirez vous-même les ports publiés et les routes d'entrée (labels Traefik, Caddy, nginx) qui mènent au conteneur.","**Portée du wildcard** — `*.proxy.votre-domaine.com` ne couvre qu'un niveau de sous-domaine. Un nom hors couverture retombe sur l'ACME intégré, qui ne peut pas aboutir si le proxy est entièrement privé.","**Exposition du certificat** — le wildcard et le domaine de base apparaissent dans les journaux Certificate Transparency, pas les noms des services qu'il couvre ; une clé wildcard compromise touche en revanche tous ces noms.","**Exploitation** — utilisez le serveur ACME de production de Let's Encrypt (ses certificats de test ne sont pas reconnus), sauvegardez les volumes de lego et des certificats, et épinglez des versions testées de lego et du proxy.",{"type":35,"title":146,"body":147},"Ce que le mesh change pour la gestion de parc","Un réseau mesh Netbird auto-hébergé remplace trois couches que vous maintenez à la main : la distribution de clés WireGuard, les règles UFW entre serveurs et la documentation des accès croisés. Chaque nouveau VPS client s'enrôle en une commande ; chaque révocation est immédiate et centralisée. Le SSH public peut se fermer, et `netbird expose` publie à la demande un service sans ouvrir de port.\n\nL'isolation par groupe vous permet de grandir sans risque de collision : les serveurs de deux clients différents ne peuvent pas se voir, même s'ils tournent sur la même infrastructure. Et le plan de contrôle reste sous votre maîtrise : aucune dépendance à un SaaS tiers, aucune limite de sièges, aucun abonnement par nœud.\n\nPour aller plus loin, couchez le provisionnement des nœuds dans Ansible (voir \u003Ca href=\"\u002Fblog\u002Fansible-automatiser-serveurs-vps\">notre guide Ansible\u003C\u002Fa>) : l'installation du client, la commande `netbird up` et les règles UFW sur `wt0` deviennent des tâches idempotentes dans un rôle réutilisable.","Vos VPS et les comptes de vos clients, sur un seul compte","Votre espace client ServOrbit.com regroupe vos domaines, hébergements et VPS, avec leurs échéances. L'Espace Reseller y ajoute les comptes cPanel de vos clients. Ajoutez un VPS dédié au plan de contrôle Netbird.","Découvrir l'offre agences","\u002Fsolutions\u002Fagences",[153,178,197],{"id":154,"slug":155,"slugs":156,"title":160,"excerpt":161,"readTime":162,"views":163,"isPinned":19,"noindex":19,"publishedAt":164,"updatedAt":165,"category":166,"categories":172,"featuredImage":29,"bgImage":30,"posterImage":174,"relatedSolution":175},164,"self-host-headscale-tailscale-vps",{"fr":155,"en":157,"ar":158,"es":159},"self-host-headscale-on-a-vps-your-own-tailscale-control-server","استضافة-headscale-على-vps-خادم-تحكم-tailscale-خاص-بك","auto-alojar-headscale-en-un-vps-servidor-tailscale","Héberger Headscale sur un VPS : serveur de contrôle Tailscale","Remplacez le serveur de contrôle cloud de Tailscale par Headscale sur votre VPS : utilisateurs illimités, maillage WireGuard complet, magic DNS et ACL, sans SaaS.",19,2,"2026-07-05T00:00:00+00:00","2026-11-08T01:13:12+00:00",{"id":167,"name":168,"slug":169,"color":170,"icon":171},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[173],{"id":167,"name":168,"slug":169,"color":170,"icon":171},"\u002Fblog\u002Fcovers\u002Fself-host-headscale-tailscale-vps-poster.svg",{"categorySlug":176,"appSlug":177},"reseau","headscale",{"id":179,"slug":180,"slugs":181,"title":185,"excerpt":186,"readTime":187,"views":163,"isPinned":19,"noindex":19,"publishedAt":188,"updatedAt":189,"category":190,"categories":194,"featuredImage":29,"bgImage":30,"posterImage":196,"relatedSolution":29},236,"ansible-automatiser-serveurs-vps",{"fr":180,"en":182,"ar":183,"es":184},"automating-vps-server-management-with-ansible","أتمتة-إدارة-خوادم-vps-باستخدام-ansible","automatizar-servidores-vps-con-ansible","Automatiser la gestion de ses serveurs VPS avec Ansible","Automatisez la gestion d'une flotte de serveurs VPS avec Ansible : inventaire, playbooks, rôles et Vault pour une infrastructure reproductible.",10,"2026-08-08T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":163,"name":191,"slug":192,"color":193,"icon":192},"Automatisation","automatisation","bg-brand-action\u002F10 text-brand-action",[195],{"id":163,"name":191,"slug":192,"color":193,"icon":192},"\u002Fblog\u002Fcovers\u002Fansible-automatiser-serveurs-vps-poster.svg",{"id":198,"slug":199,"slugs":200,"title":204,"excerpt":205,"readTime":167,"views":206,"isPinned":19,"noindex":19,"publishedAt":207,"updatedAt":208,"category":209,"categories":210,"featuredImage":29,"bgImage":30,"posterImage":212,"relatedSolution":29},228,"durcissement-serveur-linux-initial",{"fr":199,"en":201,"ar":202,"es":203},"initial-linux-server-hardening","تصليب-الخادم-linux-الأولي","hardening-inicial-servidor-linux","Durcissement initial d'un serveur Linux","Créez un utilisateur sudo, configurez SSH avec clés, activez UFW et fail2ban sur Ubuntu ou Debian en moins d'une heure.",1,"2026-08-06T00:00:00+00:00","2026-10-20T23:18:07+00:00",{"id":167,"name":168,"slug":169,"color":170,"icon":171},[211],{"id":167,"name":168,"slug":169,"color":170,"icon":171},"\u002Fblog\u002Fcovers\u002Fdurcissement-serveur-linux-initial-poster.svg",true,1794270697421]