Relier des sites : VPN, Tailscale, NetBird ou Cloudflare Mesh ?

Je travaille beaucoup sur l’interconnexion des réseaux d’entreprises. Les mêmes questions reviennent régulièrement : quelle est la meilleure solution pour relier nos sites ? Faut-il des adresses IP publiques ? Est-ce sûr ? Et la solution conviendra-t-elle encore avec une nouvelle agence, un autre accès Internet ou des collaborateurs supplémentaires ?

Ma réponse dépend des besoins réels de l’entreprise. Deux sites fixes déjà équipés de pare-feu ne partent pas des mêmes conditions que plusieurs petites agences aux connexions changeantes. Au-delà du tunnel, il faut savoir qui l’exploite, où les accès sont contrôlés et quelles dépendances l’entreprise accepte de maintenir.

Je préfère donc comprendre l’architecture avant de choisir un produit. Un VPN site à site classique peut très bien convenir. Tailscale ou NetBird peuvent simplifier l’administration et l’établissement des connexions. Cloudflare Mesh fait passer les données par le réseau du fournisseur. Ces différences déterminent, pour moi, les usages pertinents de chaque approche.

Il s’agit ici de relier des réseaux de sites entiers. L’accès individuel des collaborateurs à domicile sera traité séparément comme un usage complémentaire d’accès distant.

Notre exemple : Trois réseaux de sites interconnectés

Le siège utilise 10.1.0.0/24, l’agence 10.2.0.0/24 et le laboratoire personnel 10.3.0.0/24. Chaque site possède une passerelle qui rend les réseaux distants accessibles. Les imprimantes et NAS derrière elle n’ont pas besoin de client VPN. Tous les modèles comparés répondent au même objectif : une connectivité contrôlée entre ces trois réseaux.

On obtient un réseau routé de couche 3. Les sites ne partagent pas automatiquement un domaine de diffusion et les protocoles de découverte locale ne fonctionnent pas tous entre les sites. Le DNS doit résoudre correctement les noms internes et les routeurs locaux doivent connaître les routes vers les réseaux distants.

Je veux d’abord savoir quel réseau a besoin de quels services. L’agence peut avoir besoin du serveur de fichiers sans accéder à l’administration du laboratoire. Le serveur de sauvegarde doit atteindre sa destination, pas tous les équipements de l’autre site. Ces décisions restent nécessaires quelle que soit la solution.

Le site à site décrit la liaison, pas la topologie

Site à site signifie réseau à réseau. Cela n’impose pas de faire passer tout le trafic par un pare-feu central. Une étoile centrée sur le siège est fréquente ; des tunnels directs entre paires de sites assurent aussi une liaison site à site. Les passerelles de Tailscale, NetBird et Cloudflare Mesh peuvent remplir ce même rôle.

Tailscale et NetBird cherchent des chemins directs pour les données, même si l’inscription et la coordination sont centralisées. Le réseau de Cloudflare est géographiquement distribué, mais le trafic intersites traverse toujours Cloudflare. Ce n’est pas une liaison directe entre pairs. Le réseau du fournisseur remplace le pare-feu central comme point de transit.

Adresses IP publiques et besoins qui évoluent

La question de l’IP publique arrive vite. Je distingue l’accessibilité depuis l’extérieur et la stabilité de l’adresse. Une adresse publique fixe facilite la mise en place d’un point de terminaison VPN accessible. Elle n’est cependant pas nécessaire sur chaque site. Une agence peut établir un tunnel sortant vers une passerelle centrale accessible ; selon le montage, le DNS dynamique peut gérer une adresse changeante.

La situation se complique lorsque les deux extrémités sont derrière un NAT opérateur restrictif, sans point directement accessible. Pour les accès mobiles en particulier, il faut vérifier les adresses et connexions entrantes réellement proposées par l’opérateur. Tailscale et NetBird tentent de traverser le NAT directement et utilisent des relais si nécessaire. Cloudflare Mesh établit des connexions sortantes vers son réseau.

Je souhaite aussi que le prochain changement reste maîtrisable. Un site supplémentaire, un changement d’opérateur ou un accès sans joignabilité entrante peut transformer une petite configuration en un autre problème. Il n’est pas nécessaire de remplacer préventivement une solution fonctionnelle, mais il faut envisager ces possibilités avant de fixer la topologie.

VPN site à site classique : Les passerelles s’en chargent

Deux pare-feu ou routeurs établissent un tunnel chiffré, souvent en IPsec ou avec WireGuard configuré manuellement. Le routage local dirige les paquets destinés au réseau distant dans ce tunnel. L’autre passerelle les déchiffre et les transmet au réseau cible.

Avec trois sites, le siège peut servir de concentrateur. L’agence et le laboratoire s’y connectent séparément. La structure est simple, mais leurs échanges passent par le siège. Un maillage complet relie directement chaque paire. Pour n sites, il faut n × (n − 1) / 2 connexions : trois pour trois sites, déjà 45 pour dix. Les contrôleurs et mécanismes dynamiques peuvent réduire ce travail ; les VPN classiques ne se limitent pas aux étoiles configurées à la main.

Avantages : cette approche s’intègre aux pare-feu existants et à des périmètres de sites clairs. Vous contrôlez les extrémités. Aucun fournisseur de maillage supplémentaire ne se trouve sur le chemin des données ; règles, routage et journaux rejoignent l’administration existante.

Inconvénients : routage, clés et exploitation demandent davantage de travail à mesure que les sites s’ajoutent. NAT, adresses changeantes et équipements de constructeurs différents compliquent le diagnostic. Les utilisateurs mobiles nécessitent souvent une configuration d’accès distant distincte.

Une adresse publique fixe partout n’est pas une obligation universelle. Dans de nombreux cas, un concentrateur accessible et des tunnels sortants depuis les agences suffisent. DNS dynamique et traversée du NAT peuvent aider. Avec un CGNAT restrictif aux deux extrémités, une liaison directe devient toutefois difficile sans point accessible ou intermédiaire.

Pour deux sites stables avec des pare-feu adaptés, cela reste un choix raisonnable. Un VPN fonctionnel ne mérite pas d’être remplacé simplement parce qu’un autre produit affiche moins de champs de configuration.

Tailscale : Connexions directes et coordination centrale

Tailscale ajoute à WireGuard l’inscription des appareils, la coordination et les politiques d’accès. Son service de contrôle aide les participants à se trouver. Les données circulent directement entre pairs lorsque c’est possible. Si NAT ou pare-feu l’empêchent, un relais fournit un autre chemin. Même via DERP, les données restent chiffrées entre les pairs Tailscale.

Les routeurs de sous-réseau raccordent des LAN entiers au tailnet. Le scénario site à site documenté par Tailscale utilise Linux aux deux extrémités. Les appareils derrière eux n’ont pas besoin d’agent, mais nécessitent des routes appropriées. Désactiver le NAT source pour conserver les adresses d’origine impose de soigner particulièrement le chemin retour.

Avantages : les appareils LAN existants participent par les routeurs de sous-réseau. Les liaisons directes entre passerelles évitent le détour obligatoire par un site central. Des appareils individuels supplémentaires rejoignent la même plateforme.

Inconvénients : le chemin direct n’est pas garanti. Un relais peut modifier latence et débit. Le service de coordination hébergé reste une dépendance opérationnelle ; l’abonnement et les fonctions doivent convenir au déploiement.

Le chiffrement WireGuard s’arrête au pair. Si celui-ci est un routeur de sous-réseau, le segment LAN suivant se trouve hors du tunnel. HTTPS ou SSH restent donc utiles à l’intérieur du réseau privé.

NetBird : Un maillage similaire, avec possibilité d’auto-hébergement

NetBird repose également sur WireGuard, cherche des connexions directes et utilise des relais si nécessaire. Des pairs de routage desservent les réseaux dont les appareils n’exécutent pas le client. Le guide site à site actuel décrit Networks, Resources et les politiques d’accès correspondantes.

Avantages : le projet open source propose une alternative auto-hébergée au service cloud. C’est intéressant lorsque infrastructure et administration doivent rester sous votre responsabilité. Groupes et politiques permettent de restreindre précisément les accès.

Inconvénients : l’auto-hébergement implique mises à jour, sauvegardes, supervision et disponibilité des services de coordination et de relais. Une installation rapide n’élimine pas ces tâches. Le montage site à site documenté avec Networks conserve le masquage activé : la destination ne voit donc pas simplement l’adresse source initiale. Les autres variantes de routage exigent une conception distincte.

Tailscale et NetBird sont proches, mais leurs configurations ne sont pas interchangeables. Je les évaluerais selon le routage et le modèle d’identité requis. Open source ne signifie pas non plus que toutes les fonctions sont utilisables sans restriction : il faut vérifier les licences et les fonctions nécessaires au déploiement.

Cloudflare Mesh : Le réseau du fournisseur devient le chemin

Les participants établissent des connexions sortantes vers Cloudflare. Les échanges entre sites traversent son réseau. Inutile de relier chaque site à tous les autres ou d’exploiter son propre concentrateur VPN. Le périmètre de confiance et le chemin des données diffèrent néanmoins d’un maillage WireGuard direct.

Avantages : connectivité et politiques Gateway sont centralisées. Cela peut particulièrement convenir à une infrastructure utilisant déjà Cloudflare One. Sites derrière NAT et clients mobiles s’inscrivent par des connexions sortantes.

Inconvénients : exploitation et chemins dépendent du fournisseur. Son traitement des données doit satisfaire les exigences de confiance et de confidentialité. TLS ou SSH restent utiles pour les applications. L’intérêt du chemin pour une application donnée doit être mesuré ; un backbone mondial ne garantit pas de meilleures performances partout.

Pour un nouveau déploiement, je suivrais le client actuellement documenté. Cloudflare présente Mesh en bêta et exige MASQUE dans le profil des nœuds. Avec WireGuard, le fournisseur documente des limites pour la haute disponibilité et les routes IPv6 et par nom d’hôte. Le support de WireGuard sur un routeur ne suffit donc pas à en faire un nœud Mesh équivalent.

Il faut aussi distinguer Mesh d’un tunnel cloudflared pour certaines applications. Ici, il s’agit de connexions IP privées bidirectionnelles entre participants et réseaux routés.

Les différences en un coup d’œil

Voici les différences que je pèse en premier. Abonnement et chemin réel doivent toujours être vérifiés dans l’environnement concerné.

Ce que j’attends d’une interconnexion sûre

Quand on me demande quelle solution est la plus sûre, je regarde d’abord les connexions permises et la gestion des accès. Un tunnel chiffré peut accorder trop de droits. Je veux déterminer quels réseaux atteignent quels services, comment protéger les administrateurs et comment révoquer un accès. MFA pour l’administration et les utilisateurs inscrits personnellement, droits limités et passerelles entretenues font partie de cette évaluation.

Les limites du chiffrement diffèrent aussi. Le VPN classique se termine aux passerelles ; Tailscale et NetBird chiffrent entre pairs, éventuellement des routeurs de sous-réseau. Le LAN suivant n’est pas automatiquement chiffré. Chez Cloudflare, le traitement dans le réseau du fournisseur doit également correspondre aux exigences de l’entreprise. HTTPS et SSH restent utiles pour l’application.

Une connexion sortante simplifie parfois l’installation et évite un service VPN publiquement accessible dans l’agence. Elle ne remplace pas une politique d’accès. Inversement, une IP publique ne rend pas automatiquement un pare-feu dangereux. Le risque dépend des services exposés, de leur protection et de l’exploitation quotidienne. Je ne classe pas la sécurité sur le seul nom du produit.

Ce que je veux vérifier avant la réception

Les chemins aller et retour doivent fonctionner. La route vers 10.2.0.0/24 doit être sur le routeur ou client responsable. Si la cible répond par une autre passerelle par défaut, le retour nécessite une route adaptée. Le SNAT facilite les réponses, mais change l’adresse visible dans les journaux et les règles. Cela doit être un choix conscient.

Deux nœuds superposés ne suffisent pas à assurer la haute disponibilité. Après une panne, les appareils LAN doivent toujours atteindre leur prochaine passerelle. Keepalived et VRRP permettent par exemple une adresse virtuelle. Les routes distantes doivent aussi sélectionner un nœud sain. Je veux donc voir le comportement des sessions TCP nouvelles et existantes quand une passerelle ou son tunnel tombe. Un processus actif et un ping réussi n’en disent qu’une partie.

Les essais fonctionnels doivent inclure des connexions volontairement bloquées. Si SSH doit passer et une autre application être refusée, il faut vérifier précisément ce comportement. ICMP ne prouve pas qu’une règle TCP fonctionne. Inscription, politiques et pare-feu de destination doivent s’accorder.

Il reste les détails qui déterminent l’utilisation quotidienne : préfixes distincts, résolution des noms internes et MTU adaptée. Ni 192.168.x.x ni 10.x.x.x ne garantit l’absence de conflit. Si les petits pings passent mais les gros transferts restent bloqués, la connexion n’est pas terminée pour moi.

Comparer les performances exige le même transfert et la même application interactive sur les accès réels. Il faut relever chemin direct ou relayé, charge CPU et comportement après un changement d’accès. Mon appréciation porte sur l’architecture et l’exploitation ; elle ne constitue pas un classement de débit mesuré de ces produits.

Accès distant : Ajouter des appareils individuels

Un collaborateur qui relie son ordinateur depuis chez lui au réseau d’entreprise utilise l’accès distant, ou client à site. Le client fonctionne sur son ordinateur et ne relie pas automatiquement tout son réseau domestique au siège. On peut utiliser le service d’accès distant du pare-feu central ou les clients des plateformes comparées. Une inscription personnelle permet également des droits associés aux utilisateurs et groupes.

Un bureau à domicile peut aussi constituer un site : une passerelle y relie un réseau autorisé ou un VLAN au siège. La différence porte sur l’appareil individuel ou le réseau raccordé, pas sur le lieu de travail. L’accès distant fournit souvent un périmètre plus adapté aux appareils individuels. Rien ne justifie de rendre tout le réseau privé accessible sans le vouloir.

Quand chaque approche me paraît pertinente

Pour quelques sites fixes équipés de pare-feu, je commencerais par le VPN classique en choisissant consciemment entre étoile et tunnels directs. Pour des sites derrière NAT avec gestion centrale et chemins directs si possible, je comparerais Tailscale et NetBird. Si exploiter soi-même la coordination est indispensable, NetBird entre tôt dans l’évaluation. Là où Cloudflare One existe déjà, j’examinerais Mesh, son statut bêta et le traitement dans le réseau fournisseur. L’accès distant complémentaire constitue un critère séparé.

Headscale est une autre piste : une implémentation auto-hébergée du serveur de coordination Tailscale. C’est un projet distinct avec sa propre couverture fonctionnelle, pas le remplacement complet de toutes les capacités hébergées. WireGuard administré manuellement appartient déjà au modèle classique et convient lorsque quelques tunnels suffisent sans couche de gestion supplémentaire.

Quand on me demande la meilleure solution, je veux recommander celle qui correspond à l’entreprise et à ses prochains changements. Pour une petite installation avec des pare-feu existants, cela peut rester un VPN classique. D’autres conditions d’accès ou besoins d’administration rendent le maillage intéressant. Je choisirais selon la possibilité d’exploiter les connexions nécessaires en sécurité, de les comprendre et de les rétablir après une panne.

À la prochaine,
Joe