Routing WireGuard Point to Site
{< admonitionblock style=“important” >} Traduction d’un article du site Pro Custodibus
Le contenu de cette page est la traduction Française de l’article WireGuard Point to Site Routing de Justin Ludwig
{< /admonitionblock >}
WireGuard Point à Site Routing
Cet article décrit vos options pour configurer le routage avec une topologie de type “Point à Site” en utilisant WireGuard. Vous utiliseriez cette topologie lorsque vous souhaitez connecter un point distant à un site local via un VPN WireGuard (Réseau Privé Virtuel).
Il existe trois stratégies distinctes que vous pouvez utiliser pour router les paquets du VPN vers le site :
Nous utiliserons le diagramme de réseau suivant pour illustrer les différences entre ces stratégies :
Figure 1. Exemple de réseau point à site
Le “Point” dans le réseau point à site ci-dessus est Endpoint A, avec une adresse IP de 10.0.0.1 dans le VPN WireGuard. Le “Site” est Site B, qui exécute un hôte WireGuard, Host β. Alors que l’adresse IP de Host β dans le VPN WireGuard est 10.0.0.2, dans Site B, son adresse IP est 192.168.200.2. Endpoint B est également dans Site B, mais il n’est pas faisant partie du VPN WireGuard ; sa adresse IP dans Site B est 192.168.200.22.
L’idée derrière toutes ces stratégies est d’autoriser Endpoint B, qui ne fait pas partie du VPN WireGuard, mais fait partie du site local, à communiquer avec Endpoint A (connecté au site via le tunnel WireGuard avec Host β).
Masquerading
La stratégie la plus couramment utilisée est le masquage de paquets, également connu sous le nom d’SNAT (Source Network Address Translation). Avec cette stratégie, l’Hôte β ci-dessus transmettrait les paquets de l’Endpoint A à l’Endpoint B après avoir réécrit l’adresse source de ces paquets pour utiliser son propre adresse IP, au lieu de celle de l’Endpoint A. À partir du point de vue de l’Endpoint B sur le site local, les paquets distants provenant de l’Endpoint A apparaîtraient comme venant directement de l’Hôte β (avec une adresse IP de 192.168.200.2), et non de l’Endpoint A (avec une adresse IP de 10.0.0.1).
Le masquage de paquets est la stratégie la plus couramment utilisée pour les connexions point à site car elle est facile à mettre en place et correspond généralement à la “direction” d’accès que le VPN vise à permettre. Il ne nécessite aucune modification de routage sur le côté “Site” — il suffit simplement de quelques règles de pare-feu simples sur l’hôte effectuant le masquage (l’Hôte β dans l’exemple ci-dessus). Et il permet aux endpoints WireGuard du côté “Point” d’établir des connexions avec les endpoints non-WireGuard du côté “Site” :
Figure 2. Établissement d’une connexion point à site avec masquaging
Pour configurer un réseau WireGuard point à site avec le masquage de paquets, suivez les instructions dans la Configuration du Point à Site avec Masquaging guide.
Les deux inconvénients du masquaging sont :
- Les endpoints non-WireGuard sur le côté “Site” ne peuvent pas établir de connexions avec le côté “Point”.
- Les endpoints non-WireGuard sur le côté “Site” ne peuvent pas distinguer les différents endpoints sur le côté “Point”.
Parce que tous les hôtes de Site B verront les paquets provenant du Point de terminaison A comme s’ils venaient plutôt d’Hôte β, ils ne peuvent pas distinguer les paquets réellement originaux d’Hôte β des ceux venant d’Endpoint A (ou de tout autre Point de terminaison WireGuard connecté à Hôte β). C’est l’adresse IP d’Hôte β qui apparaîtra dans leurs journaux ; et si ils utilisent les adresses IP pour prendre des décisions d’authentification ou d’autorisation, c’est l’adresse IP d’Hôte β qu’ils utiliseront, pas celle d’Endpoint A.
De plus, les hôtes de Site B (sauf Hôt
e β lui-même) ne seront pas en mesure d’établir aucune connexion à Endpoint A. Si vous avez besoin que les hôtes du site local puissent établir des connexions à un point de terminaison distant (par exemple, parce que le point de terminaison exécute un serveur web ou une base de données que les hôtes du site local doivent accéder), vous pouvez combiner la masquerade avec le transfert de ports — ou, en alternatif, vous pouvez utiliser une passerelle de site au lieu de la masquerade des paquets.
Transfert de ports
Le transfert de ports, également connu sous le nom de DNAT (Destination Network Address Translation), est utilisé avec WireGuard lorsque vous avez un service, comme une application web ou une base de données, en cours d’exécution sur un point de terminaison distant que vous souhaitez exposer à un site local. Avec cette stratégie, Hôte β ci-dessus transférera les paquets envoyés à lui par Endpoint B via sa connexion WireGuard vers Endpoint A — après avoir réécrit l’adresse de destination de ces paquets pour utiliser l’adresse d’Endpoint A au lieu de la sienne. À partir du point de vue d’Endpoint B dans le site local, il se connecte directement à Hôte β (en utilisant l’adresse IP d’Hôte β 192.168.200.2), et pas à Endpoint A en aucun cas (il ne verra pas l’adresse IP d’Endpoint A 10.0.0.1).
Le transfert de ports est utilisé lorsque la “direction” d’accès que le VPN doit permettre est sortante (vous pourriez dire “Site à Point” au lieu de “Point à Site”) :
Figure 3. Établissement d’une connexion site-to-point avec le transfert de ports
Pour configurer un réseau WireGuard point-à-site avec le transfert de ports, suivez les instructions dans le guide Configuration du Point à Site avec Transfert de Ports.
Le désavantage du transfert de ports est que les points WireGuard sur le côté “Point” ne peuvent pas établir des connexions réussies au côté “Site”. Contrairement à la masquerade, l’hôte β ne réécrit pas l’adresse source de tout paquet que l’Endpoint A envoie à l’Endpoint B (sauf pour les réponses aux paquets à laquelle il a récemment appliqué le transfert de ports) — donc, ces paquets contiendront l’adresse source originale d’Endpoint A (10.0.0.1), et Endpoint B ne saura pas qu’il doit envoyer les paquets à travers l’hôte β pour répondre aux connexions de 10.0.0.1.
Vous pouvez combiner le transfert de ports avec la masquerade ; mais généralement, si vous avez besoin d’une initiation bidirectionnelle des connexions entre un endpoint WireGuard distant et les endpoints non-WireGuard sur un site local, le meilleur choix est d’utiliser un hôte WireGuard sur le site local comme une Passerelle Site.
Passerelle Site
Une passerelle WireGuard est utilisée pour éviter complètement la traduction d’adresses réseau (NAT). Avec cette stratégie, les hôtes de Site B ci-dessus (ou au moins la passerelle par défaut de Site B) doivent être configurés pour savoir que tous les paquets destinés à l’Endpoint A doivent être transférés via l’hôte β — donc, le pare-feu sur l’hôte β n’a pas besoin de réécrire tout paquet pour s’assurer que les paquets sont routés correctement. Lorsque Endpoint B souhaite envoyer un paquet à Endpoint A, il utilise simplement l’adresse IP WireGuard d’Endpoint A (10.0.0.1) comme destination ; et lorsque Endpoint B reçoit un paquet de Endpoint A, il verra l’adresse d’Endpoint A (10.0.0.1) comme l’adresse source du paquet.
Si vous êtes capable de configurer les tables de routage utilisées par Site B facilement, une passerelle site est généralement la meilleure option pour activer le WireGuard point-à-site — en particulier si vous avez besoin d’établir des connexions bidirectionnelles (both “Point to Site” et “Site to Point”) :
Way Outline](images/point-to-site-gateway.svg)
Figure 4. Établir des connexions bidirectionnelles avec une passerelle de site
Pour configurer un réseau WireGuard point-to-site avec une passerelle de site, suivez les instructions dans le guide Point to Site With a Site Gateway Configuration.
Le désavantage de l’utilisation d’une passerelle de site est que vous devez être en mesure de configurer les tables de routage utilisées par Site B — soit manuellement sur les hôtes individuels de Site B, soit via DHCP, ou sur la passerelle par défaut du site lui-même (pour les petits sites, c’est souvent le routeur Internet).
23/04/2021
par Justin Ludwig
by Justin Ludwig translated by: Patrice Le Guyader