LINUX:WireGuard

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche

→ retour au menu de VPN

But

Wireguard est un VPN plus simple à mettre en oeuvre et offrant une sécurité jugée suffisante. Il a été intégré au noyau de Linux. Il existe aussi pour diverses plateformes (Microsoft Windows, Android, Apple,...). Nous aborderons celle de Microsoft Windows.


Nous commencerons par une configuration interne à notre réseau local avec une orientation principalement Linux. Ensuite nous l'étendrons à Internet, notre but final, avec l'intégration de MS Windows.


Concept

L'implémentation de WireGuard est basée sur plusieurs couches, toutes intégrées au logiciel.

La première étape consiste à créer un nouvel interface réseau qui sera virtuel. Il est souvent nommé "wg0" pour le premier, "wg1" pour le suivant s'il est nécessaire de disposer de deux VPN distincts.

Ensuite un port UDP à l'écoute est mis en place par lequel transiteront les paquets de la couche VPN. Il faut choisir un n° de port assez haut non utilisé par les machines concernées. Habituellement la tranche non attribuée s'étend de 49,152 à 65,535. Dans les exemples trouvés, on utilise le port 51820.

Ces paquets seront cryptés au préalable. Ce cryptage est de type asymétrique sur base d'un couple de clés privée/publique. Ces clés sont basées sur le même principe rencontré dans des protocoles tels pour les connexions SSH ou HTTPS mais plus basic.

Sur les deux machines qui vont correspondre, on crée ce couple de clés. Elles sont donc différentes de part et d'autre. Chaque machine garde précieusement sans la divulguer sa propre clé privée. Par contre, leurs clés publiques respectives sont échangées avec la machine partenaire. La machine A a sa propre clé privée et reçoit la clé publique de la machine B.

Le mécanisme est le suivant. La machine A va crypter le paquet d'informations grâce à le clé publique de la machine B et l'envoie à la machine B qui va décrypter le paquet avec sa clé privée que lui seul détient. Seule cette clé privée peut effectuer ce décryptage. La machine B fait de même mais de façon inverse pour envoyer un paquet à la machine A partenaire.

Ce paquet est envoyé via le port UDP créé plus haut.

A ce moment le paquet est pris en charge par l'interface virtuel créé plus haut.

C'est une liaison de type PEER TO PEER. Pour établir une relation entre cette paire de machines, il faut définir un serveur et un client. Le client est chargé d'entrer en relation avec le serveur. La validation de cette liaison se fait sur base des clés. Si le client n'a pas la bonne clé publique du serveur et inversement, la liaison est en échec. Un serveur peut aussi être un client et inversement. On peut étendre ce concept à plusieurs machines sous forme d'une étoile de liaisons et même d'un graphe, à charge de bien le concevoir.

Il ne faudra pas oublier d'adapter nos FireWalls s'ils sont activés.


Installation

Sur le site de WireGuard (URL: https://www.wireguard.com/install/), vous trouverez le logiciel à télécharger pour diverses plateformes.

Cette installation doit être faite sur toutes les machines qui vont participer à ce VPN, au moins deux machines. Elles vont être sur un pied d'égalité à la base.

Dans le cadre de Linux, il est intégré aux distributions. On lance la commande de ligne suivante pour effectuer cette installation, Linux Fedora dans notre cas: 

dnf install wireguard-tools


Projet d'implantation en réseau local

Nous travaillerons sous Linux Fedora.


Schéma

Ce projet est présenté dans le schéma ci-dessous.

Nous avons un réseau local ("192.168.1.0/24" ou "192.168.1.0/255.255.255.0"). Laissons la machine C de côté pour le moment. Les machines A et B ont respectivement les adresses IP "192.168.1.21" et "192.168.1.22". Entre parenthèses est noté le nom de l'interface réseau physique.

Sur ces machines, nous avons installé le logiciel WireGuard. Sur chacune, un interface virtuel WireGuard nommé "wg0". La machine A a l'adresse IP virtuelle "192.168.20.1" et sera élevé au niveau de serveur VPN. La machine B a l'adresse IP virtuelle "192.168.20.2" et sera élevé au niveau de client VPN.

Nous utiliserons le port UDP/53025 comme moyen de transport.



Système

Ce protocole VPN doit transférer les paquets entrants et sortants entre deux interfaces réseaux. Et sous Linux, il faut activer cette fonctionnalité au niveau du système.

Dans le fichier "/etc/sysctl.conf" ou, de préférence, dans un fichier créé dans le sous-répertoire "/etc/sysctl.d" ayant l'extension ".conf", par exemple "forward.conf", on ajoute la ligne suivante: 

net.ipv4.ip_forward=1

Ensuite on redémarre la machine ou on exécute la commande: 

sysctl -p <nom du fichier de paramètres>

ou selon notre exemple: 

sysctl -p /etc/sysctl.d/forward.conf

pour que le système intégre ce nouveau paramètre.


Création de la paire de clés

Le logiciel vient avec les commandes de ligne pour créer ce couple de clés.

La commande suivante crée la clé privée dans le fichier "private-key": 

wg genkey > private-key

La seconde crée la clé publique sur base de cette clé privée dans le fichier "public-key": 

wg pubkey < private-key > public-key

Une commande groupée permet d'effectuer les deux en une fois: 

wg genkey | tee private-key | wg pubkey > public-key

Ces clés sont composées de 32 bytes et ensuite codées en Base64 comme dans les fichiers attachés à un mail.

Pour information, les commandes suivantes permettent de les décoder: 

cat private-key | base64 --decode > private-key.decode
cat public-key  | base64 --decode > public-key.decode

Par exemple, sur la machine A, nous avons la paire suivante, clé privée en premier, ensuite la clé publique: 

4FQDUeTKfqOVtqrxwk7DQYRdeHV3rH6prPdDtkMTNXI=
UvfwuwkCx96eCQmNgXw3b8el9Z65y4JXgZLfWuFGjzM=

De même pour la machine B: 

8LppKvOr1+rh+X5pUzio0M2cDerxClmnWnJx9cgwsEc=
7qHaTkaBWeHUPDc3k9Mq1OV+Rdij2T0awXWdySgyc0c=


Fichiers de configuration

Sous Linux, le fichier de configuration est placé dans le répertoire "/etc/wireguard". Il porte de nom de l'interface réseau virtuel suivi de l'extension ".conf". Dans notre cas, les deux interfaces se nomment "wg0" et donc les fichiers se nommeront "/etc/wireguard/wg0.conf".

Voici la configuration de la machine A de type serveur: 

# machine A
[Interface]
Address = 192.168.20.1/24
SaveConfig = false
ListenPort = 53025
PrivateKey = 4FQDUeTKfqOVtqrxwk7DQYRdeHV3rH6prPdDtkMTNXI=
PostUp   = /etc/wireguard/fw/fw.add.bat
PostDown = /etc/wireguard/fw/fw.del.bat
 
# machine B
[Peer]
PublicKey = 7qHaTkaBWeHUPDc3k9Mq1OV+Rdij2T0awXWdySgyc0c=
AllowedIPs = 192.168.20.2/32
PersistentKeepalive = 25

Et voici la configuration de la machine B de type client: 

# machine B
[Interface]
Address = 192.168.20.2/32
SaveConfig = false
ListenPort = 53025
PrivateKey = 8LppKvOr1+rh+X5pUzio0M2cDerxClmnWnJx9cgwsEc=
PostUp   = /etc/wireguard/fw/fw.add.bat
PostDown = /etc/wireguard/fw/fw.del.bat
 
# machine A
[Peer]
PublicKey = UvfwuwkCx96eCQmNgXw3b8el9Z65y4JXgZLfWuFGjzM=
AllowedIPs = 192.168.20.1/32
PersistentKeepalive = 25
EndPoint = 192.168.1.21:53025

La première section "[Interface]" décrit l'interface de la machine hôte. Nous retrouvons l'adresse IP virtuelle du schéma ("Address"). Nous trouvons le n° du port UDP ("ListenPort") et la clé privée ("PrivateKey"). Le contenu du fichier "private-key" est recopié ici. Dans la première configuration, c'est celle de la machine A. L'option "SaveConfig" est accessoire. Elle permet que la configuration en mémoire n'écrase pas celle dans le fichier de configuration lors de l'arrêt du service.

Les options "PostUp" et "PostDown" permettent respectivement d'exécuter une commande au démarrage de l'interface et à son arrêt. Elles vont être utilisées pour configurer dynamiquement le FireWall. Nous expliciterons cet aspect plus bas.

La seconde section "[Peer]" reprend quelques caractéristiques du partenaire. Si la première section concerne la machine A, la seconde concerne la machine B. Nous retrouvons la clé publique ("PublicKey"). Le contenu du fichier "public-key" est recopié ici. Dans la première configuration, c'est celle de la machine B. La machine hôte accepte l'adresse IP virtuelle ("AllowedIPs") du partenaire ayant cette clé publique. Toutes les 25 secondes ("PersistentKeepalive"), un paquet est envoyé au partenaire pour signaler qu'il est bien présent.

Enfin sur la configuration du client (machine B), l'option "EndPoint" définit qu'elle est le client VPN qui cherche à atteindre la machine A serveur VPN. On y note l'adresse IP physique du serveur et le n° du port UDP sur lequel le serveur écoute. Si au moins un des deux n'a pas cette option, la liaison ne peut s'établir.

On peut remarquer que les clés sont croisées.


Activation

Il existe divers moyens.

Sous Linux Fedora, qui utilise le service NetworkManager pour la couche réseau, il est possible d'ajouter le nouvel interface "wg0" à la configuration. Elle y restera jusqu'à sa suppression.

La commande suivante permet de l'ajouter: 

nmcli connection import type wireguard file /etc/wireguard/wg0.conf

Nous verrons apparaitre le fichier de configuration "/etc/NetworkManager/system-connections/wg0.nmconnection".

De même pour l'éliminer, on utilise la commande suivante: 

nmcli connection delete wg0


Mais plus classiquement, on utilise le service "wg-quick@.service" en spécifiant le nom de l'interface.

Pour l'activer au démarrage, on exécute la commande suivante: 

systemctl enable wg-quick@wg0.service

et pour le lancer: 

systemctl start wg-quick@wg0.service

Ces procédures sont à exécuter sur les deux machines.


Vérifications

Après lancement, il existe divers moyens pour vérifier plusieurs aspects de cette nouvelle liaison.


Wg

La commande "wg" permet d'avoir un état de la configuration: 

wg

qui donne sur la machine A: 

interface: wg0
 public key: UvfwuwkCx96eCQmNgXw3b8el9Z65y4JXgZLfWuFGjzM=
 private key: (hidden)
 listening port: 53025
 
peer: 7qHaTkaBWeHUPDc3k9Mq1OV+Rdij2T0awXWdySgyc0c=
 endpoint: 192.168.1.22:53025
 allowed ips: 192.168.20.2/32
 latest handshake: 51 seconds ago
 transfer: 50.14 KiB received, 1.09 MiB sent  
 persistent keepalive: every 25 seconds

On remarque aussi qu'il y a du transfert. On peut faire de même sur la machine B.


Handshakes

Une autre commande permet de vérifier que la liaison est établie: 

wg show wg0 latest-handshakes

qui donne un n° de liaison en correspondance de la clé publique du partenaire: 

7qHaTkaBWeHUPDc3k9Mq1OV+Rdij2T0awXWdySgyc0c=    1781031370

Si le n° est nul, la liaison n'est pas effectuée. Attendez une minute après l'activation. On peut faire de même sur la machine B.


Ifconfig

On peut afficher la configuration réseau avec la commande: 

ifconfig

qui donne sur la machine A: 

enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.1.21  netmask 255.255.255.0  broadcast 192.168.1.255
       ether 00:1c:d2:a3:90:c2  txqueuelen 1000  (Ethernet)
       RX packets 962301  bytes 780030070 (743.8 MiB)
       RX errors 0  dropped 3791  overruns 0  frame 0
       TX packets 486911  bytes 121503394 (115.8 MiB)
       TX errors 0  dropped 10 overruns 0  carrier 0  collisions 0
       device interrupt 20  memory 0xd3200000-d3220000
 
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
       inet 127.0.0.1  netmask 255.0.0.0
       loop  txqueuelen 1000  (Boucle locale)
       RX packets 230018  bytes 25628572 (24.4 MiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 230018  bytes 25628572 (24.4 MiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 
wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
       inet 192.168.20.1  netmask 255.255.255.0  destination 192.168.20.1
       unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
       RX packets 1243  bytes 65748 (64.2 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 19947  bytes 2931064 (2.7 MiB)
       TX errors 0  dropped 2245 overruns 0  carrier 0  collisions 0

L'interface "wg0" est apparu. On peut faire de même sur la machine B.


Netstat

On vérifie que le port UDP est bien à l'écoute: 

netstat -nlu

qui donne après filtrage: 

udp        0      0 0.0.0.0:53025           0.0.0.0:*
udp6       0      0 :::53025                :::*

On remarque qu'il écoute aussi sur IPV6.


Ping

A partir de la machine B client, on peut faire maintenant un Ping sur l'adresse IP virtuelle du serveur: 

ping 192.168.20.1

Dans l'autre sens, ça ne va pas.


Iptables

Si on a mis dans notre FireWall Iptables, les commandes de traçage du port UDP en tête de script: 

-A INPUT  -p udp -m udp --sport 53025 -j LOG --log-level debug --log-prefix "I-53025: "
-A INPUT  -p udp -m udp --dport 53025 -j LOG --log-level debug --log-prefix "I-53025: "
-A OUTPUT -p udp -m udp --sport 53025 -j LOG --log-level debug --log-prefix "O-53025: "
-A OUTPUT -p udp -m udp --dport 53025 -j LOG --log-level debug --log-prefix "O-53025: "

On retrouve dans le journal les lignes suivantes répétées à intervalle régulier (25s): 

Jun  8 12:06:22 server kernel: O-53025: IN= OUT=enp0s25 SRC=192.168.1.21 DST=192.168.1.22 LEN=120 TOS=0x08 PREC=0x80 TTL=64 ID=25035 PROTO=UDP SPT=53025 DPT=53025 LEN=100
Jun  8 12:06:22 server kernel: O-53025: IN= OUT=enp0s25 SRC=192.168.1.21 DST=192.168.1.22 LEN=120 TOS=0x08 PREC=0x80 TTL=64 ID=25035 PROTO=UDP SPT=53025 DPT=53025 LEN=100
Jun  8 12:06:22 server kernel: I-53025: IN=enp0s25 OUT= MAC=00:1c:d2:a3:90:c2:00:1c:c0:92:a2:08:08:00 SRC=192.168.1.22 DST=192.168.1.21 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48676 PROTO=UDP SPT=53025 DPT=53025 LEN=40
Jun  8 12:06:22 server kernel: I-53025: IN=enp0s25 OUT= MAC=00:1c:d2:a3:90:c2:00:1c:c0:92:a2:08:08:00 SRC=192.168.1.22 DST=192.168.1.21 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48676 PROTO=UDP SPT=53025 DPT=53025 LEN=40

On remarque que ceci se passe sur l'interface réseau physique et non virtuel.

Note: Les commandes sont doublées car nous avons pris par facilité les mêmes ports UDP sur les deux machines.


Problème

Si la liaison ne se fait pas, en premier lieu désactivez le FireWall sur les deux machines. Puis vérifiez bien la configuration. Les clés sont-elles bien croisées. L'option "EndPoint" est-elle bien présente sur le client...


FireWall

Si on a activé le FireWall sous Linux, il faut ajouter des règles d'accès. Nous utilisons Iptables.

Souvenez-vous. Dans le fichier de configuration "/etc/wireguard/wg0.conf", on a les deux lignes suivantes: 

PostUp   = /etc/wireguard/fw/fw.add.bat
PostDown = /etc/wireguard/fw/fw.del.bat

La première permet l'ajout de règles dans le FireWall; la seconde les élimine.

On crée le sous-répertoire "fw": 

mkdir /etc/wireguard/fw

On y ajoute le fichier "fw.add.bat" ayant les droits d'exécution dont voici le contenu: 

#!/bin/bash
/etc/wireguard/fw/fw.rule.bat I

De même pour le fichier "fw.del.bat": 

#!/bin/bash
/etc/wireguard/fw/fw.rule.bat D

Il fait appel au script "fw.rule.bat" qui contient les règles. L'argument "I" est là pour insérer les règles et "D" pour les détruire.

Voici son contenu: 

#!/bin/bash
IPT="/sbin/iptables"
 
# $1 : sens I=install D=delete
IN_FACE="enp0s25"                # NIC connected to the internet
WG_FACE="wg0"                    # WG NIC
SUB_NET_DEBUT="192.168.20"       # WG IPv4 sub/net - début
SUB_NET="${SUB_NET_DEBUT}.0/24"  # WG IPv4 sub/net - Network
WG_PORT="53025"                  # WG udp port
 
## IPv4 ##
$IPT -t nat -$1 POSTROUTING -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -t nat -$1 PREROUTING  -s ${SUB_NET} -i $WG_FACE -p tcp --dport 9091 -j DNAT --to-destination 192.168.1.23:9090
$IPT -t nat -$1 POSTROUTING -s $SUB_NET -o $IN_FACE -j LOG --log-level debug --log-prefix "WGN1: "
$IPT -t nat -$1 PREROUTING  -s $SUB_NET -i $WG_FACE -j LOG --log-level debug --log-prefix "WGN2: "
 
$IPT -$1 wgforward -i $IN_FACE -o $WG_FACE -d $SUB_NET -j ACCEPT
$IPT -$1 wgforward -i $WG_FACE -o $IN_FACE -s $SUB_NET -j ACCEPT
$IPT -$1 wgforward -i $WG_FACE -j LOG --log-level debug --log-prefix "WGF1: "
$IPT -$1 wgforward -o $WG_FACE -j LOG --log-level debug --log-prefix "WGF2: "
 
$IPT -$1 wgoutput  -o $IN_FACE -p udp -m udp --sport $WG_PORT -j ACCEPT
$IPT -$1 wgoutput  -o $WG_FACE -j LOG --log-level debug --log-prefix "WGO1: "
$IPT -$1 wgoutput  -i $WG_FACE -j LOG --log-level debug --log-prefix "WGO2: "
 
$IPT -$1 wginput   -i $IN_FACE -p udp -m udp --dport $WG_PORT -j ACCEPT
$IPT -$1 wginput   -i $WG_FACE -p tcp -m tcp --dport 9090 -s ${SUB_NET} -j ACCEPT
$IPT -$1 wginput   -i $WG_FACE -j LOG --log-level debug --log-prefix "WGI1: "
$IPT -$1 wginput   -o $WG_FACE -j LOG --log-level debug --log-prefix "WGI2: "

Cet exemple est adapté au serveur VPN; il doit être adapté du côté client VPN. Du côté serveur VPN, il doit donner accès à quelques services en fonction du client VPN. On y a inclus deux exemples de services auquel le serveur VPN donne accès (port TCP/9090).

Ces scripts sont automatiquement exécutés lors du lancement et de l'arrêt du service. Notons que le service NetworkManager n'exécute pas ces scripts. Il faut les intégrer au fichier de configuration d'Iptables.


Explications de quelques règles:

  • les variables en début sont à adapter selon la machine.
  • les lignes en gras sont nécessaires
  • action LOG: lignes accessoires, utiles pour tracer dans le journal les requêtes refusées.
  • NAT
    • action MASQUERADE de la chaîne POSTROUTING: notre serveur VPN a un rôle analogue à un router des ISP; il permet d'isoler l'intérieur du réseau des accès d'internet au travers des clients surtout quand ils sont situés en dehors du réseau local père.
    • action DNAT de la chaîne PREROUTING: une règle qui donne accès au service Cockpit (port TCP/9090) (site de gestion de la machine Linux) de la machine D tierce. La requête se fait sur le port TCP/9091 (URL: HTTPS://192.168.20.1:9091) qui arrive sur le serveur VPN et cette règle redirige la requête vers la machine D (IP: 192.168.1.23) et le port TCP/9090.
  • FORWARDING
    • Le serveur VPN doit transférer les requêtes entre deux réseaux: le réseau local (192.168.1.0/24) et le réseau virtuel WireGuard (192.168.20.0/24) dans les deux sens.
  • OUTPUT
    • la règle en gras sert à accepter la sortie de trafic UDP du tunnel
    • sur le client VPN, on doit ajouter des règles de requêtes en sortie qui font le pendant des règles d'entrée des requêtes au niveau du serveur VPN. On doit le faire sauf si aucun filtrage en sortie n'est effectué, ce qui est courant.
  • INPUT
    • la règle en gras sert à accepter l'entrée de trafic UDP du tunnel
    • la règle suivante, donne accès au service Cockpit (port TCP/9090) (site de gestion de la machine Linux) de la machine A serveur. La requête se fait sur le port TCP/9090 (URL: HTTPS://192.168.20.1:9090) qui arrive sur le serveur VPN.
    • on ajoute des règles équivalentes pour d'autres services, par exemple, le service SSH interne , les services de messageries internes (Postfix et Dovecot), le site Web interne HTTPS non accessible normalement via Internet par tous.


On y remarque des chaînes personnalisées (ou "custom chain") ("wgforward", "wgoutput" et "wginput"). Par cette approche, on peut cibler l'endroit précis où ces règles s'appliqueront. On doit donc amender le script "/etc/sysconfig/iptables.

On ajoute la définition de ces chaînes en début de script en dessous des chaînes de filtrage standard ainsi que l'action RETURN qui redonne la main à la suite des règles si aucune n'est acceptée ou rejetée: 

:wginput - [0:0]
:wgoutput - [0:0]
:wgforward - [0:0]
 
-A wginput   -j RETURN
-A wgoutput  -j RETURN
-A wgforward -j RETURN

Les règles du script "fw.rule.bat" viendront s'insérer au dessus de la chaîne correspondante ayant l'action "RETURN" ("-j RETURN") qui redonne la main aux règles suivantes.

Ensuite on place à l'endroit désiré l'appel de ces chaînes: 

...
-A FORWARD -j wgforward
...
-A OUTPUT -j wgoutput
...
-A INPUT -j wginput
...


Configuration sous MS Windows en réseau local

Sous MS Windows, on procède à l'installation "wireguard-installer.exe". Ce programme a été téléchargé sur le site de WireGard comme expliqué en début d'article. Il doit être installé et configuré sous un utilisateur ayant les droits du groupe administrateurs.


Après installation, l'écran de configuration se présente vide comme suit.



En bas, divers boutons permettent sa gestion:

  • l'ajout d'un interface réseau vide; la création d'une paire de clés est automatiquement générée; le reste de la configuration est à introduire manuellement selon le format expliqué sous Linux ci-dessus.
  • l'ajout d'un interface réseau à partir d'un fichier de configuration analogue à celui expliqué sous Linux ci-dessus.
  • l'élimination d'un interface réseau.
  • la sauvegarde d'un interface réseau dans un fichier sous format ZIP.

Nous avons opté pour l'importation d'un fichier déjà créé.



On enregistre et l'écran s'est amendé et présente le nouvel interface réseau. On clique sur le bouton "Activer". En bas, le bouton "Modifier" permet l'action mentionnée. Si on ajoute un second interface réseau, un seul ne peut être actif à la fois.



Sur la machine A serveur, on ajoute la partie suivante au fichier "/etc/wireguard/wg0.conf" pour qu'elle reconnaisse ce nouveau client VPN et on relance le service: 

# PC MS Windows local
[Peer]
PublicKey = 52xn0q3ACnAx4rsa7zof+7RtDbJLl6F6E8lq/rAD4Wc=
AllowedIPs = 192.168.20.6/32
PersistentKeepalive = 25


Projet d'implantation en réseau Internet

Nous travaillerons sous Linux Fedora et MS Windows.


Schéma

Ce projet est présenté dans le schéma ci-dessous.

Il est semblable au précédent à part qu'ici, la machine C client VPN est en dehors du réseau local, quelque part dans Internet ou un autre réseau local, tout deux ayant accès à Internet. Dans ce cas, nous avons utilisé une machine client VPN équipée d'MS Windows.

Du côté de la machine serveur VPN, il suffira d'ajouter la section "[Peer]" de ce nouveau client, la machine C.

Comme la machine C est hors du réseau local, seule l'adresse IP publique du router/modem de l'ISP est connue. Donc au niveau de la machine C, le serveur VPN correspondant sera cette adresse IP publique ou son DNS. Dans mon cas, ce DNS est "www.adbweb.gslb.eu" comme décrit dans l'article sur la Configuration du serveur DNS via GSLB.

Ensuite cette requête doit être redirigée vers la machine A à l'intérieur du réseau local (PAT) comme décrit dans l'article sur la Configuration du modem.

Nous ne reviendrons pas sur la création de la paire de clés, ni sur le détail des fichiers de configuration.



Configuration de la machine client VPN

Cette machine est équipée de MS Windows et sa couche WireGuard est la suivante. Le seul point spécial est l'option "EndPoint". On y met l'adresse IP publique de notre router/modem de l'ISP. Mais comme elle est succeptible de changer, on l'a liée à un nom de domaine (DNS). Un changement dynamique de son adresse IP dans la zone DNS est implémentée soit à partir d'une machine du réseau local, soit via une fonctionnalité du Router/modem de l'ISP.



On valide et on active la couche VPN.



Configuration du router/modem de l'ISP

Je suis équipé d'une BBOX de chez Proximus. Elle a l'adresse IP 192.168.1.1 en interne. On y accède par son interface WEB (URL: http://192.168.1.1). On clique sur le bouton en haut au centre "Access Control" et ensuite on prend l'onglet "Port Mapping". Dans l'écran qui s'ouvre, on ajoute la ligne suivant selon l'image ci-dessous. On précise le protocol: UDP, les ports d'entrée et de sortie: 53025 et la machine cible, l'adresse IP de l'interface physique de notre serveur VPN "192.168.1.21" et on valide.



Configuration de la machine serveur VPN

Enfin on ajoute la section "[Peer]" dans la configuration de la machine A serveur VPN pour qu'elle reconnaisse ce nouveau client: 

# PC MS Windows internet
[Peer]
PublicKey = +J0vw7tcJBbpL/HJwAFQO7+2JSlhBhWnwGcsLPP4cWY=
AllowedIPs = 192.168.20.3/32
PersistentKeepalive = 25

Et on relance le service VPN.

Il reste à tester cette configuration hors de notre réseau local.




→ retour au menu de VPN

Récupérée de "https://linux.adbweb.gslb.eu/index.php?title=LINUX:WireGuard&oldid=10972"