Topologies principales de WireGuard
|
Important
|
Traduction d’un article du site Pro Custodibus Le contenu de cette page est la traduction Française de l’article Primary WireGuard Topologies de Justin Ludwig |
Topologies principales de WireGuard
Ces sont les quatre topologies principales à considérer lors du choix de la manière de connecter deux points finaux sur un réseau WireGuard :
Toutes fonctionnent pour toutes les raisons habituelles de connexion entre deux points finaux, comme permettre aux points finaux de communiquer via SSH, ou que l’un des points finaux se connecte à un serveur HTTP sur l’autre, ou que l’un des points finaux accède aux dossiers partagés de l’autre, etc.
Contrairement à certaines technologies VPN, WireGuard n’a pas de rôles stricts “client” ou “serveur”. Tous les pairs WireGuard sont également capables de réaliser ce qui est généralement considéré comme un rôle “client” ou “serveur”.
Mais pour simplifier cet article, je vais utiliser constamment des exemples avec un “Point A”, représentant un point final “client” (comme une tablette d’un utilisateur final), se connectant via un tunnel WireGuard à un “Point B”, représentant un point final “serveur” (comme un serveur exécutant une application web que l’utilisateur final veut utiliser). Et je vais utiliser le port 51821 pour représenter le pair WireGuard en cours d’exécution sur la partie “client” du tunnel, et le port 51822 pour représenter le pair WireGuard sur la partie “serveur” (et le port 51823 dans le cas où il y a un pair WireGuard intermédiaire entre les deux).
Point à Point
La topologie la plus simple est simplement Point à Point — un point final exécutant WireGuard connecté directement à un autre point final exécutant WireGuard. C’est aussi la seule topologie qui produit une chiffrage E2E (End-to-End) — toutes les autres topologies impliquent que des paquets WireGuard soient déchiffrés par un intermédiaire à certains moments entre les points finaux.
Pour que le Point à Point fonctionne, le port WireGuard d’un des points de terminaison doit être ouvert pour de nouvelles connexions à travers tous les pare-feux entre les deux points de terminaison.
Dans le scénario le plus simple du Point à Point, les deux points de terminaison seraient sur le même LAN (Réseau local), avec tout pare-feu entre les deux points de terminaison configuré pour permettre que l’un des points de terminaison puisse se connecter au port WireGuard de l’autre. Dans ce cas, l’un des points de terminaison peut initier une connexion à l’autre à tout moment.
Figure 1.1 : Point à Point simple de Endpoint A vers Endpoint B
Dans un scénario plus complexe, mais courant, les deux points de terminaison seraient derrière des pare-feux et NAT (Traduction automatique), avec l’Internet entre eux. Ici, les pare-feux devant Endpoint A permettent uniquement les connexions établies à travers Endpoint A. Les pare-feux devant Endpoint B permettent de nouvelles connexions à travers le port 51822, et le NAT devant Endpoint B transmet le port 51822 à Endpoint B.
Figure 1.2 : Point à Point derrière des pare-feux et NAT de Endpoint A vers Endpoint B
Dans ce scénario, Endpoint A peut initier une nouvelle connexion à tout moment à Endpoint B. Mais car Endpoint A est derrière un pare-feu qui permet uniquement les connexions établies, si vous voulez activer Endpoint B pour initier des connexions à Endpoint A, vous devez configurer le paramètre PersistentKeepalive sur Endpoint A (une valeur de 25, ce qui signifie envoyer un paquet keepalive toutes les 25 secondes, fonctionnera bien la plupart du temps).
Un Mesh topologie est effectivement simplement une série de connexions individuelles entre tous les pairs.
iduelles Point à Point parmi un groupe de points de terminaison.
Consultez l’article Configuration du Point à Point WireGuard pour voir un exemple de la façon de configurer les points de terminaison avec cette configuration.
Hub et Spoke
La prochaine topologie de base est la Topologie Hub et Spoke (également connue sous le nom de la Topologie Étoile), où deux points de terminaison exécutant WireGuard sont connectés à travers un troisième hôte, également exécutant WireGuard. Ce troisième hôte opère comme un routeur parmi les points de terminaison WireGuard connectés à lui, transférant les paquets qu’il reçoit via un tunnel WireGuard d’un point de terminaison à un autre point de terminaison via un autre tunnel WireGuard.
Vous pourriez souvent connecter plus que simplement deux points de terminaison de cette manière — cette topologie est une bonne façon d’activer la gestion de l’accès à distance parmi un ensemble divers de points de terminaison à distance ; ou pour créer un réseau virtuel LAN à partir de plusieurs hôtes à distance disparates, avec des règles de routage, du contrôle d’accès et de l’examen du trafic centralisés dans un seul endroit (le hub).
La topologie Hub and Spoke peut également être une outil utile pour connecter deux points de terminaison qui se trouvent tous les deux derrière des pare-feux ne permettant pas de nouvelles connexions entrantes, ou derrière NAT ne permettant pas le transfert de ports (où vous utiliseriez simplement le hub comme un “serveur rebond”).
Dans la topologie Hub and Spoke la plus simple, tous les hôtes sont sur le même réseau local, avec tout pare-feu entre les deux points de terminaison “spoke” (Endpoint A et Endpoint B) et l’hôte “hub” (Host C) configuré pour permettre aux spokes de se connecter au hub sur le port WireGuard du hub (51823), et de manière similaire, permettant au hub de se connecter aux spokes sur chaque port WireGuard du spoke (51821 pour Endpoint A et 51822 pour Endpoint B).
Une fois que le tunnel WireGuard entre Endpoint A et Host C est en place, et que le séparé tunnel WireGuard entre Endpoint B et Host C est en place, Host C peut router les paquets envoyés de Endpoint A à Endpoint B, et vice versa.
Figure 2.1 : Hub and Spoke simple de Endpoint A à Endpoint B via Host C
Dans un scénario plus complexe, le hub et les spokes sont derrière des pare-feux et des NAT, avec l’Internet au milieu. Les pare-feux devant Endpoint A et Endpoint B permettent uniquement les connexions établies à Endpoint A et Endpoint B. Les pare-feux devant Host C permettent de nouvelles connexions à travers le port 51823, et le NAT devant Host C transmet le port 51823 à Host C.
Figure 2.2 : Hub et Spoke derrière des pare-feux et des NAT de Endpoint A à Endpoint B via Host C
Dans ce scénario, bien que Endpoint A et Endpoint B puissent chacun initier indépendamment de nouvelles connexions avec Host C, en raison des règles de pare-feu pour Endpoint A et B, Host C ne peut pas initier de nouvelles connexions avec eux. Par conséquent, afin d’autoriser Endpoint A à initier des connexions via WireGuard à Endpoint B, vous devez configurer le paramètre PersistentKeepalive sur Endpoint B. Et si vous voulez également permettre à Endpoint B d’initier des connexions via WireGuard à Endpoint A, vous devez configurer le paramètre PersistentKeepalive sur Endpoint A.
Consultez l’article Configuration d’un hub et de spokes WireGuard pour un exemple de la façon de configurer trois pairs WireGuard avec cette configuration.
Point to Site
Avec une topologie Point to Site, un endpoint distant est connecté à un hub central. Cette topologie est souvent utilisée pour permettre aux utilisateurs de se connecter à partir d’un réseau local à un réseau distant en utilisant WireGuard.
Figure 2.3 : Topologie Point to Site
Dans cette configuration, l’endpoint distant (Endpoint A) est connecté au hub central (Host C) via un tunnel WireGuard. Le hub central peut ensuite router les paquets entre Endpoint A et d’autres points de terminaison dans le réseau distant.
Consultez l’article Configuration d’une topologie Point to Site WireGuard pour voir un exemple de la façon de configurer cette topologie.
Voici le texte corrigé :
Établir une connexion via WireGuard à un autre hôte dans un autre réseau, où ce hôte peut transmettre des paquets de l’endpoint distant vers divers autres endpoints locaux au sein de son réseau. Point to Site est similaire à un Hub and Spoke, sauf que certains des spokes (ceux sur le même LAN que le hub) ne utilisent pas d’établissement WireGuard.
Point to Site est agréable pour de nombreux cas d’utilisation où vous souhaitez permettre l’accès à distance depuis un endpoint discret à divers serveurs sur le même LAN, sans avoir à configurer et à gérer WireGuard séparément sur chacun de ces serveurs. Vous pourriez avoir des cas comme :
- Un ordinateur distant se connectant à divers serveurs sur un réseau local d’entreprise (appelé Road Warrior)
- Une station de travail dans un réseau local d’entreprise se connectant à plusieurs serveurs dans un réseau cloud (appelé Point to Cloud)
- Une machine virtuelle du cloud se connectant à divers serveurs sur votre réseau local d’entreprise
- Un serveur du cloud se connectant à d’autres serveurs dans un autre réseau cloud
Dans le scénario Point to Site le plus simple, vous avez un point de terminaison avec WireGuard en cours d’exécution (le “point de terminaison distant”, Endpoint A) connecté directement à un autre hôte exécutant WireGuard (Host β); et cet autre hôte peut servir de routeur aux autres points de terminaison au sein du site local (Site B), y compris Endpoint B (le “point de terminaison local”).
Figure 3.1 : Point to Site simple de Endpoint A à Endpoint B dans Site B
Tout pare-feu entre Endpoint A et Site B dans ce scénario serait configuré pour permettre à Endpoint A de se connecter à Host β, et vice versa. Cela permet au point de terminaison distant (Endpoint A) d’initier une connexion à tout autre point de terminaison local, et tout autre point de terminaison local (comme Endpoint B) d’initier une connexion au point de terminaison distant.
Dans un scénario plus complexe (et celui que vous êtes plus susceptible de voir), les deux points de terminaison distants (Endpoint A) et le site local (Site B) sont derrière des pare-feux et NAT, avec Internet en milieu. Les pare-feux devant Endpoint A permettent uniquement les connexions établies à travers Endpoint A. Le pare-feu devant Site B permet les nouvelles connexions à travers le port 51822, où un hôte exécutant WireGuard (Host β) accepte les connexions WireGuard sur le port 51822 et route le trafic autorisé de ses tunnels WireGuard vers les points de terminaison au sein du site (comme Endpoint B).
Figure 3.2 : Point to Site derrière des pare-feux et NAT de Endpoint A à Endpoint B dans Site B
Le trafic au sein du site local (Site B) n’est pas tunnelé via WireGuard et est donc soumis à toute restriction de pare-feu ou d’autres restrictions de routage auxquelles le trafic local est soumis. Dans ce scénario, une requête HTTP entre les points de terminaison A et B parcourt le tunnel WireGuard du point de terminaison A vers Site B, puis est ensuite routée localement comme tout autre trafic local à partir du tunnel WireGuard jusqu’au point de terminaison B. Ainsi, pour que le trafic HTTP du point de terminaison A atteigne enfin le port 80 sur le point de terminaison B, tout pare-feu situé entre l’hôte β et le point de terminaison B doit autoriser le port 80 à partir de l’hôte β vers le point de terminaison B.
Comme dans le scénario Point to Point, le point de terminaison A peut initier une nouvelle connexion à tout moment au point de terminaison B. Cependant, car le point de terminaison A est derrière un pare-feu qui permet uniquement les connexions déjà établies, si vous souhaitez autoriser le point de terminaison B à initier des connexions au point de terminaison A, vous devrez configurer la paramètre PersistentKeepalive sur le point de terminaison A.
Consultez l’article Configuration de WireGuard pour plus d’informations.
Point to Site
Une topologie Point to Site implique un site complet aux deux extrémités du tunnel WireGuard. C’est une façon simple de construire une connexion virtuelle LAN to LAN (ou Cloud to Cloud, ou LAN to Cloud, etc.).
Sur une des extrémités, vous avez un hôte exécutant WireGuard, et cet hôte peut router vers divers points de terminaison au sein de son propre site. À l’autre extrémité de la connexion, vous avez également un autre hôte exécutant WireGuard dans un autre site, et ce hôte peut également router vers les points de terminaison au sein de son propre site.
Dans sa forme la plus simple, vous avez deux sous-réseaux adjacents, Site A et Site B, connectés par un tunnel WireGuard. Le trafic dans Site A (comme Endpoint A) destiné à un point de terminaison dans Site B (comme Endpoint B) est routé vers le hôte WireGuard (Host α) dans Site A, via le tunnel WireGuard jusqu’à Site B, et sort du hôte WireGuard (Host β) dans Site B vers le point de terminaison dans Site B.
Figure 4.1 : Connexion simple entre deux sites depuis Endpoint A dans Site A vers Endpoint B dans Site B
Tout pare-feu situé entre Site A et Site B devrait être configuré pour permettre à Site A de se connecter au port WireGuard de Site B, et vice versa. Cela permet à tout point de terminaison dans Site A d’initier une connexion avec tout point de terminaison dans Site B, et vice versa.
Dans un scénario plus complexe, les deux sites seraient derrière des pare-feux et des NAT, avec l’Internet situé entre eux. Le pare-feu devant Site A permet de nouvelles connexions à travers le port 51821, où Host α accepte les connexions WireGuard sur le port 51821 et route le trafic autorisé à partir de son tunnel WireGuard vers les points de terminaison au sein du site. De manière similaire, le pare-feu devant Site B permet de nouvelles connexions à travers le port 51822, où Host β accepte le trafic WireGuard pour lui et route le trafic autorisé à partir de son tunnel WireGuard vers les points de terminaison au sein de Site B.
Dans ce scénario, les hôtes WireGuard pour Site A et Site B vivent tous deux dans une zone démilitarisée (DMZ) de leurs sites respectifs, où ils sont accessibles publiquement à partir de l’Internet, mais peuvent également router vers l’espace d’adressage privé utilisé par leur propre site (ainsi que l’espace d’adressage privé utilisé par les réseaux WireGuard auxquels ils appartiennent).
Figure 4.2 : Connexion entre deux sites derrière des pare-feux et des NAT depuis Endpoint A dans Site A vers Endpoint B dans Site B
Le trafic du Point de terminaison A au Point de terminaison B dans ce scénario est routé en premier lieu vers l’Hôte α, via le tunnel WireGuard entre le Site A et le Site B, sortant de l’Hôte β, et enfin sur le Point de terminaison B. Le pare-feu entre le Point de terminaison A et l’Hôte α permet le trafic sortant du Point de terminaison A (et le trafic des connexions établies rentrant); et le pare-feu entre l’Hôte β et le Point de terminaison B permet le trafic entrant HTTP (port 80) au Point de terminaison B (et le trafic correspondant sortant).
Les pare-feux entre l’Hôte α et l’Hôte β permettent à l’un des hôtes WireGuard d’initier une connexion avec l’autre — et donc, généralement, établissent une communication sécurisée entre les deux sites.
En utilisant le tunnel WireGuard, n’importe quel point de terminaison du Site A pourrait initier une connexion avec n’importe quel point de terminaison du Site B, et vice versa. Cependant, le pare-feu entre le Point de terminaison A et l’Hôte α permet uniquement les connexions établies au Point de terminaison A, en protégeant celui-ci des nouvelles connexions venant du Site B.
Si nous voulons permettre aux points de terminaison du Site B d’être capables d’initier de nouvelles connexions au Point de terminaison A, il n’y a rien spécifique à WireGuard que nous devrions faire pour y parvenir. Nous changerions simplement nos règles de pare-feu pour le pare-feu entre le Point de terminaison A et l’Hôte α afin d’autoriser les nouvelles connexions entrantes (comme nous l’avons fait pour le Point de terminaison B, qui permet des nouvelles connexions HTTP sur le port 80 de l’Hôte β).
Consultez l’article Configuration du Site à Site WireGuard pour voir un exemple de la façon de configurer les hôtes WireGuard avec cette configuration.
Autres Topologies
Pretty much all other topologies you’d use with WireGuard you can build by composing these four basic patterns. For example, for a WireGuard network consisting of several discrete remote endpoints (for your road warriors) connected to a LAN (at your office HQ), you might combine Hub and Spoke with Point to Site, where the remote endpoints would be the spokes of Hub and Spoke, and the hub of Hub and Spoke would also be the site’s WireGuard host from Point to Site.
Voici la traduction en français :
En tant qu’autre exemple, pour un réseau WireGuard reliant trois réseaux LAN d’entreprise plus deux sites cloud, vous pourriez utiliser la topologie Site à Site entre chaque site individuel, créant un tunnel WireGuard séparé du hôte WireGuard dans chaque site vers chacun des quatre autres sites. Ou vous pourriez décider d’utiliser une combinaison Hub et Spoke avec Site à Site, ce qui vous permet de centraliser votre routage et contrôle d’accès inter-site dans un seul endroit, et de connecter le hôte WireGuard à chaque site uniquement à un seul hôte hub, auquel tous les autres sites se connectent également.
10/30/2020
(mis à jour 12/15/2020)
par Justin Ludwig
by Justin Ludwig translated by: Patrice Le Guyader