Serveur WireGuard ou VPN maillé pour les appareils derrière un CGNAT

Choisissez un VPN maillé lorsque le serveur domestique et les appareils distants sont derrière un CGNAT et que vous ne contrôlez aucun point de terminaison accessible publiquement ; la traversée du NAT et l’infrastructure de relais sont précisément les éléments manquants. Choisissez un serveur WireGuard classique lorsque vous pouvez fournir un point de terminaison public stable — à domicile, via IPv6 ou sur un VPS — et que vous préférez gérer directement les clés des pairs, les routes, les règles de pare-feu et la topologie du hub. Le CGNAT ne rend pas WireGuard inutilisable, mais il modifie l’infrastructure que vous devez fournir autour de celui-ci.

Le CGNAT supprime l’hypothèse selon laquelle votre routeur domestique possède une adresse IPv4 publique

Un serveur WireGuard domestique classique s’attend à ce que les pairs distants envoient des paquets vers un point de terminaison accessible depuis Internet. Avec le NAT ordinaire d’un routeur et une adresse WAN publique, la redirection de port peut associer ce point de terminaison à l’hôte WireGuard. Avec le NAT de niveau opérateur, le FAI effectue une traduction supplémentaire en amont ; le routeur domestique ne contrôle donc pas forcément le mappage public dont les pairs externes ont besoin.

La RFC 6598 définit 100.64.0.0/10 comme un espace d’adresses partagé destiné au NAT de niveau opérateur. La présence d’une adresse WAN dans cette plage indique fortement qu’une traduction effectuée par le FAI existe entre le domicile et l’Internet public. En pratique, une règle de redirection de port sur le routeur domestique peut donc ne pas créer de point de terminaison IPv4 accessible à l’échelle mondiale.

C’est le premier critère de décision. Si le FAI fournit une adresse IPv4 publique, un chemin IPv6 public utilisable ou un service permettant de créer le mappage entrant requis, un serveur WireGuard auto-hébergé reste simple à mettre en place. Si aucune voie publique n’existe, la comparaison ne porte plus sur « quel protocole VPN est le meilleur », mais sur « qui fournit la traversée ou le relais ».

Un serveur WireGuard est préférable lorsque vous pouvez fournir un hub accessible

WireGuard classique est volontairement minimaliste. Chaque pair connaît sa clé privée, ses plages d’adresses autorisées, ainsi que la clé publique et le point de terminaison du pair qu’il doit contacter. Un hub installé sur un serveur domestique est facile à comprendre lorsque le hub dispose d’une adresse stable et accessible et que les appareils distants peuvent initier une connexion vers lui.

La documentation de démarrage rapide de WireGuard sur les points de terminaison et les keepalives persistants explique comment un pair situé derrière un NAT peut maintenir son mappage actif en envoyant périodiquement du trafic. Cela aide un client à rester accessible via son mappage NAT existant, mais ne fournit pas à un serveur domestique derrière un CGNAT un point de terminaison IPv4 public que l’abonné ne contrôle pas.

La solution basée sur un serveur WireGuard convient donc à trois architectures courantes de laboratoire domestique : le FAI attribue au domicile un point de terminaison public ; le domicile expose le service via un IPv6 utilisable ; ou un petit VPS devient le hub WireGuard accessible et le domicile établit vers lui un tunnel sortant. Dans les trois cas, vous contrôlez le modèle de routage et ne dépendez pas d’un service de coordination maillé pour découvrir les pairs.

Les VPN maillés sont préférables lorsque la traversée et la découverte des points de terminaison sont le vrai problème

Un VPN maillé associe des tunnels chiffrés à une couche de coordination. Les appareils s’inscrivent dans le réseau virtuel, se découvrent, échangent des informations de connexion et tentent de traverser le NAT sans obliger le propriétaire à saisir manuellement un point de terminaison public pour chaque réseau changeant. Cela est particulièrement utile lorsque les ordinateurs portables, les téléphones et le serveur domestique passent tous par des types de NAT que le propriétaire ne contrôle pas.

Le modèle de connexion actuel de Tailscale commence par un chemin relayé, échange les informations nécessaires à une connexion directe, tente de traverser le NAT, puis passe à une connexion UDP directe de pair à pair lorsque cela est possible. Si la traversée directe échoue, la connexion peut rester relayée. L’intérêt ne réside pas dans une promesse de chiffrement différente, mais dans un système automatisé de connectivité autour de liaisons basées sur WireGuard.

Choisissez la solution maillée lorsque vous voulez connecter des appareils situés derrière des CGNAT distincts, le Wi-Fi d’un hôtel, des réseaux mobiles ou des routeurs domestiques restrictifs sans devoir d’abord construire un hub public. Ce choix est moins pertinent lorsque vous ne voulez dépendre d’aucun service de coordination externe ou lorsque le routage direct et prévisible via votre propre infrastructure compte davantage que la simplicité de l’inscription.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Le repli par relais résout l’accessibilité, mais peut devenir la limite de performances

Un VPN relayé peut rester fonctionnellement connecté lorsque la traversée directe de pair à pair échoue, mais le chemin des données passe alors par un intermédiaire. La latence augmente selon l’emplacement du relais et le chemin réseau, et le débit peut être inférieur à celui d’un tunnel direct. Cette différence compte davantage pour SMB, les sauvegardes distantes, les grandes bibliothèques de photos ou les contenus multimédias à haut débit que pour SSH et les tableaux de bord.

Les recommandations de ZeroTier sur le NAT et les relais indiquent qu’un NAT strict et le CGNAT peuvent forcer les connexions à passer par des serveurs relais, avec une latence plus élevée et un débit limité par rapport aux chemins directs. Les différents produits VPN maillés implémentent les relais de manière différente, mais le compromis architectural reste le même : la facilité de traversée peut déplacer le goulot d’étranglement vers la localisation et la capacité des relais.

Cela peut inverser le choix pour un usage intensif de stockage distant. Une connexion domestique qui ne peut pas accepter directement WireGuard peut tout de même bénéficier d’un hub VPS contrôlé par l’utilisateur et situé près du domicile ou de l’utilisateur, car celui-ci fournit un relais prévisible dont vous pouvez dimensionner et surveiller les ressources. Pour un simple accès administratif, le repli géré d’un VPN maillé peut être plus simple et parfaitement suffisant.

Les VPN maillés ajoutent une identité et des politiques que WireGuard brut vous laisse gérer

Le modèle de pairs de WireGuard est axé sur la cryptographie et le routage. Si vous voulez une connexion utilisateur, l’inscription des appareils, des groupes nommés, des politiques d’accès centralisées, des procédures de rotation des clés ou un inventaire consultable des appareils, ces fonctions doivent être construites autour du protocole. Une plateforme maillée fournit normalement tout ou partie de ce plan de contrôle.

L’architecture de NetBird décrit une plateforme qui associe les tunnels WireGuard à la traversée du NAT, à l’authentification, aux ACL et à la gestion du réseau. Cela illustre le véritable axe de comparaison : un VPN maillé n’est pas simplement « WireGuard avec une autre interface » ; il ajoute des services de coordination et de politique que WireGuard brut ne définit volontairement pas.

Pour un seul administrateur et trois appareils stables, des pairs WireGuard configurés manuellement peuvent être plus simples que l’exploitation ou la gestion d’un plan de contrôle plus vaste. Pour une famille utilisant des téléphones changeants, plusieurs ordinateurs portables, des routeurs de sous-réseau et un accès basé sur les rôles, l’inscription maillée et les politiques centralisées peuvent réduire le nombre de fichiers de pairs et d’exceptions de pare-feu que le propriétaire doit gérer manuellement.

Auto-héberger le plan de contrôle maillé remplace la dépendance à un fournisseur par la responsabilité de l’infrastructure

Le choix ne se limite pas à un fournisseur de VPN maillé hébergé ou à WireGuard brut. Un plan de contrôle auto-hébergé peut conserver le modèle de connexion maillé tout en plaçant la coordination sous votre administration. Cela réduit la dépendance à un fournisseur, mais ajoute un service public, une base de données ou un état persistant, des sauvegardes, des mises à niveau, des certificats et des tâches de récupération.

Headscale se présente comme une implémentation auto-hébergée du serveur de contrôle Tailscale. Sa documentation prend également en charge les options DERP auto-hébergées, ce qui montre clairement le compromis de propriété : vous pouvez contrôler davantage la coordination et le chemin de relais, mais vous devez alors maintenir ce chemin accessible et récupérable.

Ne choisissez pas un VPN maillé auto-hébergé uniquement parce que le terme « auto-hébergé » correspond au reste de votre laboratoire. Utilisez cette solution lorsque la propriété du plan de contrôle, le stockage des politiques, l’indépendance vis-à-vis d’un fournisseur ou l’emplacement personnalisé des relais justifient suffisamment l’ajout d’un autre service exposé à Internet. Sinon, un VPN maillé hébergé peut supprimer précisément le problème de disponibilité que le CGNAT a rendu difficile.

Choisissez selon l’accessibilité, le chemin des données et la propriété du plan de contrôle

Choisissez un serveur WireGuard lorsqu’un point de terminaison public fiable existe et que vous voulez une architecture transparente en étoile, avec des clés et des routes explicites. Cette solution est particulièrement adaptée à un petit nombre de pairs stables, aux propriétaires à l’aise avec la configuration du pare-feu et du DNS, ou à une architecture assistée par un VPS dont vous contrôlez l’emplacement et la capacité du relais.

Choisissez un VPN maillé lorsque les appareils sont derrière un CGNAT ou des NAT changeants, que l’inscription doit être simple et que la découverte automatique des chemins ou le repli par relais justifie l’ajout d’une couche de coordination. Pour un accès intensif aux fichiers, vérifiez si la session est directe ou relayée, car cette réponse peut modifier suffisamment le débit pour avoir un impact réel.

La comparaison de ZimaSpace entre reverse proxy, WireGuard et Tailscale pour les services familiaux distants couvre le choix plus large de l’accès distant. Dans la branche des VPN privés, la règle de décision est plus précise : si vous pouvez fournir le point de terminaison accessible et que vous préférez tout contrôler manuellement, WireGuard suffit ; si l’accessibilité elle-même est le problème récurrent, un VPN maillé mérite sa couche de contrôle supplémentaire.