2021-01-06
md
Installation et configuration de WireGuard sur Raspberry Pi OS (janvier 2021)
<-Installing and Configuring WireGuard on a Raspberry Pi

Une deuxième version du système d'exploitation pour le Raspberry Pi, RaspberryPi OS, est disponible depuis décembre 2019. Des tests préliminaires ont montré que, tout comme son prédécesseur, cette mise à jour de Raspbian par la Fondation Raspberry Pi n'apporte rien de nouveau en ce qui concerne l'installation et l'utilisation d'un réseau privé virtuel Wireguard. Autant que je sache, il n'y a que deux changements pertinents.

Par conséquent, il y a une étape de moins dans le processus d'installation. La configuration du «serveur» sur le Raspberry Pi et l'installation et la configuration des «clients» sur les tablettes ou des «pairs» sur les autres ordinateurs restent inchangées. Cet article montre comment ajouter le serveur sur un Raspberry Pi Model B Rev 2. Cet ancien Pi, circa 2012, est basé sur le système sur puce (SoC) Broadcom BCM2825 qui dispose d'un processeur ARM à un seul cœur avec une architecture ARMv6. Bien qu'il s'agisse d'un ancien modèle 1 du Pi, il ressemble aux modèles Pi Zero actuels, sauf pour une cadence plus lente. L'expérience a montré qu'il peut y avoir des différences si l'on utilise un modèle plus récent du Raspberry Pi. Puisqu'elles sont limitées à un nombre légèrement différent de paquets mis à jour ou installés et a des variations mineures de la taille des paquets modifiés, elles sont sans conséquence.

Table des matières

  1. Installation de WireGuard
    1. Système d'exploitation Raspberry Pi OS
    2. Installation de WireGuard depuis le référentiel Raspian Testing
    3. Vérification de l'installation
  2. Accès à distance au réseau local
    1. Adresse IP locale et statique de l'hôte
    2. Adresse IP publique et dynamique de l'hôte
    3. Réacheminement d'un port UDP
    4. Activation du transfert IP
  3. Configuration de WireGuard
    1. Installation du script de gestion des utilisateurs de Adrian Mihalko
    2. Création des clés publiques et privées du serveur
    3. Création et modification du fichier de configuration du serveur
    4. Modification du modèle de la configuration des clients
    5. Modification du modèle de la configuration du serveur
    6. Création d'une configuration initiale du serveur WireGuard
    7. Gestion du service WireGuard
  4. Gestion des utilisateurs
    1. Ajout d'utilisateurs
    2. Installation d'un client WireGuard sur Android
    3. Installation d'un client WireGuard sur Windows 10
    4. Installation d'un client WireGuard sur Linux
    5. Suppression d'utilisateurs
  5. Utilisation des clients WireGuard
  6. Quelques observations finales

Installation de WireGuard toc

WireGuard est une application gratuite et open-source et un protocole de communication qui implémente un réseau privé virtuel (RPV même si l'acronyme VPN d'après virtual private network est souvent utilisée). Ce logiciel gagne rapidement en popularité. Linus Torvalds a donné suite à ses premiers commentaires positifs et a intégré le RPV WireGuard dans l'arborescence des sources du noyau Linux 5.6. Alors qu'Ubuntu 20.04 utilise encore le noyau 5.4, il est livré avec WireGuard installé. En revanche, toujours fidèle à son approche prudente, Debian n'a pas encore intégré le paquet, mais il devrait être inclus dans Bullseye destiné à remplacer Buster. Le système d'exploitation Raspberry Pi est basé sur la distribution Debian, utilisant également le noyau 5.4 et n'inclut pas encore WireGuard. Cette lacune pouvant être comblée dans un proche avenir, il est logique de vérifier que WireGuard n'est pas déjà présent. Essayez les commandes suivantes.

pi@oldpi:~$ which wg pi@oldpi:~$ which wg-quick

Si les deux programmes sont trouvés (probablement dans /usr/bin/), WireGuard est installé. Vérifiez qu'il est correctement en place, puis configurez WireGuard.

Système d'exploitation Raspberry Pi OS toc

La version actuelle du système d'exploitation du Raspberry Pi

  Raspberry Pi OS Lite
  Release date: December 2nd 2020
  Kernel version: 5.4
  Size: 438MB

peut être téléchargée à partir de la page intitulée a href="https://www.raspberrypi.org/software/operating-systems/" target="_blank">Operating system images. Il existe trois versions du système d'exploitation, la version Lite est généralement choisie si le Raspberry Pi est utilisé comme serveur, tandis que l'une des versions « bureau » est typiquement obtenue si un clavier et un moniteur sont connectés au Pi et si l'on veut une interface utilisateur graphique (GUI). Même si une version GUI est installée, il sera probablement nécessaire d'ouvrir un terminal pour installer WireGuard.

Si vous utilisez une image nouvellement copiée du système d'exploitation, n'oubliez pas d'utiliser l'utilitaire raspi-config pour modifier, au minimum, le mot de passe du système, le nom d'hôte et le fuseau horaire. Sur un serveur, il est probablement préférable de s'assurer que SSH est activé et d'allouer au processeur graphique le moins de mémoire possible (16 Mo). Il existe de nombreuses descriptions sur ces démarches sur le Web ou même sur mon site, il est donc inutile de décrire à nouveau ce processus.

Dans ce qui suit, le nom d'hôte du modèle 1 Raspberry Pi est oldpi.

Avant d'ajouter un composant majeur, il est préférable de mettre à jour et à niveau le système.

pi@oldpi:~ $ uname -a Linux oldpi 5.4.79+ #1373 Mon Nov 23 13:18:15 GMT 2020 armv6l GNU/Linux pi@oldpi:~ $ sudo apt update; sudo apt upgrade -y Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB] ... The following packages will be upgraded: apt apt-utils base-files distro-info-data libapt-inst2.0 libapt-pkg5.0 libjpeg62-turbo libp11-kit0 libpam-systemd libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 libsqlite3-0 libssl1.1 libsystemd0 libudev1 libxml2 openssl python-apt-common python3-apt raspberrypi-bootloader raspberrypi-kernel rpi-eeprom systemd systemd-sysv tzdata udev 28 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 125 MB of archives. After this operation, 1,067 kB of additional disk space will be used. ... pi@oldpi:~ $ uname -a Linux oldpi 5.4.79+ #1373 Mon Nov 23 13:18:15 GMT 2020 armv6l GNU/Linux

La langue d'affichage du système pourrait être le français puisque Linux> est polyglotte. Ce choix est facilement réalisé avec l'utilitaire raspi-config sur le Raspberry Pi par exemple. J'ai opté pour ne pas ajouter cette fonctionnalité aux serveurs monocarte peu puissants comme le Pi qui fonctionnent sans interaction la plupart du temps. En revanche, le français est installé sur mon système de bureau, dont le nom est hp. Voilà qui explique l'étrange mélange d'anglais provenant de oldpi et de français venant de hpci-dessous.

Les paquets qui seront mis à niveau et l'espace disque libéré ou utilisé dépendront du temps écoulé depuis la dernière mise à niveau. Notez que contrairement à la mise à jour de la première version de Raspberry Pi OS, la version du noyau est restée inchangée à 5.4.79. J'ai vérifié et WireGuard n'avait réussi à s'installer pendant la mise à jour.

pi@oldpi:~$ which wg wg-quick pi@oldpi:~$

Cependant, les en-têtes du noyau étaient en place. Cette fois, j'ai vérifié en utilisant le gestionnaire de paquets et je me suis également assuré que les versions du noyau et les en-têtes du noyau correspondaient.

pi@oldpi:~ $ dpkg-query -l | grep raspberrypi-kernel* ii raspberrypi-kernel 1.20201201-1 armhf Raspberry Pi bootloader ii raspberrypi-kernel-headers 1.20201201-1 armhf Header files for the Raspberry Pi Linux kernel

Il est donc maintenant possible de procéder à l'installation de WireGuard directement.

Si une version plus ancienne du système d'exploitation est utilisée, le prérequis doit être ajouté.
pi@oldpi:~ $ sudo apt-get install raspberrypi-kernel-headers Reading package lists... Done ... The following NEW packages will be installed: raspberrypi-kernel-headers 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 26.2 MB of archives. After this operation, 171 MB of additional disk space will be used. ... Setting up raspberrypi-kernel-headers (1.20200723-1) ...

Cette étape prend un temps considérable surtout avec les modèles du PI basé sur la puce de système BCM2835. On devrait vérifier la correspondance des versions du noyau et des fichiers d'en-têtes du noyeau comme ci-dessus ou avec apt-cache.

pi@newpi:~ $ apt-cache policy raspberrypi-kernel* raspberrypi-kernel: Installed: 1.20201201-1 Candidate: 1.20201201-1 Version table: *** 1.20201201-1 100 50 http://archive.raspberrypi.org/debian buster/main armhf Packages 100 /var/lib/dpkg/status raspberrypi-kernel-headers: Installed: 1.20201201-1 Candidate: 1.20201201-1 Version table: *** 1.20201201-1 100 50 http://archive.raspberrypi.org/debian buster/main armhf Packages 100 /var/lib/dpkg/status

Installation de WireGuard depuis le référentiel Raspian Testing toc

Pour les impatients, voici les quatre commandes qui ajouteront avec le moins d'impact le référentiel Rasbian testing et qui installeront WireGuard.

pi@oldpi:~ $ echo "deb http://archive.raspbian.org/raspbian testing main" | sudo tee --append /etc/apt/sources.list.d/testing.list pi@oldpi:~ $ printf 'Package: *\nPin: release a=testing\nPin-Priority: 50\n' | sudo tee --append /etc/apt/preferences.d/limit-testing pi@oldpi:~ $ sudo apt update pi@oldpi:~ $ sudo apt install wireguard -y

Si vous voulez en savoir un peu plus au sujet de ces commandes, lisez le reste de cette section.

Il ne fait aucun doute que WireGuard n'est pas présent dans le système d'exploitation mis à jour et que le paquet n'est pas disponible dans les référentiels Raspbian stables.

pi@oldpi:~ $ apt-cache policy wireguard* N: Unable to locate package wireguard* N: Couldn't find any package by glob 'wireguard*' N: Couldn't find any package by regex 'wireguard*

Voici tous les référentiels fouillés sans succès par l'utilitaire apt à la recherche du paquet wireguard.

pi@oldi:~ $ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 500 http://archive.raspberrypi.org/debian buster/main armhf Packages release o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation,c=main,b=armhf origin archive.raspberrypi.org 500 http://raspbian.raspberrypi.org/raspbian buster/rpi armhf Packages release o=Raspbian,a=stable,n=buster,l=Raspbian,c=rpi,b=armhf origin raspbian.raspberrypi.org 500 http://raspbian.raspberrypi.org/raspbian buster/non-free armhf Packages release o=Raspbian,a=stable,n=buster,l=Raspbian,c=non-free,b=armhf origin raspbian.raspberrypi.org 500 http://raspbian.raspberrypi.org/raspbian buster/contrib armhf Packages release o=Raspbian,a=stable,n=buster,l=Raspbian,c=contrib,b=armhf origin raspbian.raspberrypi.org 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages release o=Raspbian,a=stable,n=buster,l=Raspbian,c=main,b=armhf origin raspbian.raspberrypi.org Pinned packages:

Heureusement, les paquets souhaités sont disponibles dans le référentiel Raspbian testing. Un grand merci à Daniel T. Wagner pour avoir signalé cela et fourni les instructions pour installer le paquet dans un courriel privé datant du 27 juillet 2019. Merci également à Aravind Reddy pour ses commentaires et corrections utiles.

pi@oldpi:~ $ echo "deb http://archive.raspbian.org/raspbian testing main" | sudo tee --append /etc/apt/sources.list.d/testing.list deb http://archive.raspbian.org/raspbian testing main pi@oldpi:~ $ sudo apt update Hit:1 http://archive.raspberrypi.org/debian buster InRelease Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease ... Reading package lists... Done Building dependency tree Reading state information... Done 383 packages can be upgraded. Run 'apt list --upgradable' to see them.

Comme je ne voulais pas que les 383 paquets de la distribution stable actuelle soient remplacés par des versions du référentiel testing, j'ai abaissé la priorité de ce dépôt, puis vérifié la priorité de tous les dépôts utilisés et vérifié qu'aucun paquet stable ne serait remplacé depuis testing lors de mise à jour futures.

pi@oldpi:~ $ printf 'Package: *\nPin: release a=testing\nPin-Priority: 50\n' | sudo tee --append /etc/apt/preferences.d/limit-testing Package: * Pin: release a=testing Pin-Priority: 50 pi@oldpi:~ $ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 50 http://archive.raspbian.org/raspbian testing/main armhf Packages release o=Raspbian,a=testing,n=bullseye,l=Raspbian,c=main,b=armhf origin archive.raspbian.org 50 http://archive.raspberrypi.org/debian buster/main armhf Packages release o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation,c=main,b=armhf origin archive.raspberrypi.org 500 http://raspbian.raspberrypi.org/raspbian buster/rpi armhf Packages release o=Raspbian,a=stable,n=buster,l=Raspbian,c=rpi,b=armhf origin raspbian.raspberrypi.org 500 http://raspbian.raspberrypi.org/raspbian buster/non-free armhf Packages release o=Raspbian,a=stable,n=buster,l=Raspbian,c=non-free,b=armhf origin raspbian.raspberrypi.org 500 http://raspbian.raspberrypi.org/raspbian buster/contrib armhf Packages release o=Raspbian,a=stable,n=buster,l=Raspbian,c=contrib,b=armhf origin raspbian.raspberrypi.org 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages release o=Raspbian,a=stable,n=buster,l=Raspbian,c=main,b=armhf origin raspbian.raspberrypi.org Pinned packages: pi@oldpi:~ $ sudo apt update Hit:1 http://archive.raspberrypi.org/debian buster InRelease Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease Hit:3 http://archive.raspbian.org/raspbian testing InRelease Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date.

Ce qui suit montre que les paquets souhaités demeurent disponibles dans le référentiel testing.

pi@oldpi:~ $ apt-cache policy wireguard* wireguard-dkms: Installed: (none) Candidate: 1.0.20201221-1 Version table: 1.0.20201221-1 500 500 http://archive.raspbian.org/raspbian testing/main armhf Packages wireguard-modules: Installed: (none) Candidate: (none) Version table: wireguard-tools: Installed: (none) Candidate: 1.0.20200827-1 Version table: 1.0.20200827-1 500 500 http://archive.raspbian.org/raspbian testing/main armhf Packages wireguard: Installed: (none) Candidate: 1.0.20200827-1 Version table: 1.0.20200827-1 500 500 http://archive.raspbian.org/raspbian testing/main armhf Packages

Le paquet wireguard est un « métapaquet » dont le but est d'installer wireguard-dkms et wireguard-tools.

pi@oldpi:~ $ sudo apt install wireguard -y Reading package lists... Done ... The following NEW packages will be installed: dkms raspberrypi-kernel-headers wireguard wireguard-dkms wireguard-tools 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded. Need to get 26.7 MB of archives. After this operation, 173 MB of additional disk space will be used. ... DKMS: install completed. Module build for kernel 5.4.79-v8+ was skipped since the kernel headers for this kernel does not seem to be installed. Setting up wireguard-tools (1.0.20200827-1) ... wg-quick.target is a disabled or a static unit, not starting it. Setting up wireguard (1.0.20200827-1) ... Processing triggers for man-db (2.8.5-2) ...

Avec les nouveaux modèles du Raspberry Pi, la sortie sera légèrement différente, mais le résultat final sera le même.

Il est maintenant possible de vérifier que les utilitaires de WireGuard ont été installés.

pi@oldpi:~ $ which wg wg-quick /usr/bin/wg /usr/bin/wg-quick

Vérification de l'installation toc

Pour tester davantage l'installation, créons un fichier de configuration d'interface vide et activons celle-ci.

pi@oldpi:~ $ sudo touch /etc/wireguard/wg0.conf pi@oldpi:~ $ sudo wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip link set mtu 1420 up dev wg0

Le module wireguard devrait être chargé, l'interface réseau wg0 devrait être en place et le serveur wg devrait être opérationnel et en attente des datagram de type UDP entrants sur un port qui est choisi au hasard pour autant que je sache et qui est 40213 ci-dessous.

pi@oldpi:~ $ lsmod | grep wire wireguard 143360 0 ip6_udp_tunnel 16384 1 wireguard udp_tunnel 16384 1 wireguard ipv6 454656 29 wireguard pi@oldpi:~ $ ifconfig wg0 wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 pi@oldpi:~ $ sudo wg interface: wg0 listening port: 40213

Cependant, il est plutôt inutile de faire apparaître l'interface, car elle ne fera rien sans une configuration appropriée. Désactiver l'interface et arrêter le serveur est tout aussi simple, mais le module wireguard reste chargé.

pi@oldpi:~ $ sudo wg-quick down wg0 [#] ip link delete dev wg0 pi@oldpi:~ $ sudo wg pi@oldpi:~ $ ifconfig wg0 wg0: error fetching interface information: Device not found pi@oldpi:~ $ lsmod | grep wire wireguard 143360 0 ip6_udp_tunnel 16384 1 wireguard udp_tunnel 16384 1 wireguard ipv6 454656 27 wireguard pi@oldpi:~ $ sudo modprobe -r wireguard pi@oldpi:~ $ lsmod | grep wire pi@oldpi:~ $

Accès à distance au réseau local toc

Espérons que le réseau local domestique ne soit pas facilement accessible depuis l'extérieur, car cela signifierait qu'il est vulnérable aux attaques de tout script kiddie désoeuvré. Cependant, un accès facile, mais sécurisé au réseau local de n'importe où sur Internet est possible si WireGuard (ou d'un autre serveur de réseau privé virtuel) est hébergé sur le réseau domestique. Le serveur n'étant pas le seul élément qui doit être en place pour l'accès à distance, cette section examine d'autres prérequis.

Si vous avez déjà accès à une caméra IP, à un système domotique ou à un « cloud » ou un NAS autohébergé, vous êtes probablement assez familier avec les noms d'hôtes dynamiques et la redirection de port décrit dans les trois sous-sections suivantes, mais lisez attentivement la section sur l'activation du transfert IP.

Adresse IP locale et statique de l'hôte toc

Comment pourrait-on même espérer mettre en place un réseau privé virtuel si le serveur n'a pas d'adresse fixe? Ceci est particulièrement vrai pour WireGuard qui est "très silencieux" comme expliqué plus loin. Ainsi, le Raspberry Pi hébergeant le serveur WireGuard doit avoir une adresse IP fixe sur le réseau local. Beaucoup recommandent d'ajouter une «réservation DHCP» pour le Pi dans la table d'adresses IP statiques du routeur. Chaque routeur est différent, mais l'adresse IP souhaitée est essentiellement affectée au Raspberry Pi par le serveur DHCP du routeur selon l'adresse MAC du Pi. On devrait alors choisir une adresse IP statique en dehors de la plage d'adresses dynamiques du serveur DHCP. La plupart des routeurs permettent à l'utilisateur de spécifier cette plage.

L'utilitaire ifconfig affiche l'adresse MAC des interfaces réseau.

pi@newpi:~ $ ifconfig eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether b8:27:eb:cc:12:a8 txqueuelen 1000 (Ethernet) ... wlan0: flags=4163 mtu 1500 ... ether b8:27:eb:cb:21:8b txqueuelen 1000 (Ethernet) ...

L'adresse MAC est identifiée par le terme ether dans la description de chaque interface. Par défaut, l'interface Ethernet est nommée eth0 et l'interface Wi-Fi est nommée wlan0. Les informations sont également enfouies dans le répertoire système.

pi@oldpi:~ $ cat /sys/class/net/eth0/address b8:27:eb:cc:12:a8 pi@newpi:~ $ cat /sys/class/net/wlan0/address b8:27:eb:cb:21:8b

Bien sûr, sur les anciens modèles Pi, il n'y aura pas d'interface Wi-Fi à moins que du matériel tel qu'un dongle USB Wi-Fi ait été ajouté.

La table d'adresses IP statiques de mon routeur contient un nombre d'entrées plutôt limité. Et parfois je pense que sa mémoire non volatile est moins fiable que les cartes SD que j'utilise avec le Raspberry Pi. Par conséquent, je laisse le client DHCP du Raspberry Pi configurer une adresse IP statique pour les interfaces Wi-Fi et Ethernet au lieu d'obtenir une adresse dynamique (mais fixe - je sais c'est pas très logique) du routeur. Cela se fait en ajoutant les informations nécessaires à la fin du fichier de configuration.

pi@newpi:~ $ sudo nano /etc/dhcpcd.conf

... # static IP interface eth0 static ip_address=192.168.1.21/24 static routers=192.168.1.1 static domain_name_servers=192.168.1.1 interface wlan0 static ip_address=192.168.1.22/24 static routers=192.168.1.1 static domain_name_servers=192.168.1.1

Bien sûr, ce sont les paramètres d'un Pi plus récent avec Wi-Fi intégré. Sur un Pi sans Wi-Fi, il n'y a pas d'interface wlan0.

Sur mon routeur, le Raspberry Pi apparaît comme un appareil connecté avec une adresse IP « autoassignée ». Encore une fois, l'adresse IP statique attribuée au Pi doit être en dehors de la plage d'adresses DHCP dynamiques contrôlées par le serveur DHCP sur le routeur. Pour certains appareils importants tels que le Raspberry Pi qui héberge mon système domotique, j'ai choisi de définir une adresse IP statique avec une réservation DHCP sur le routeur et de demander au Raspberry Pi de configurer une adresse IP statique, juste pour être sûr.

Adresse IP publique et dynamique de l'hôte toc

Tous les ordinateurs et périphériques connectés à un réseau domestique (souvent appelé LAN pour Local Area Network) se voient attribuer une adresse IP par le serveur DHCP qui est probablement le routeur provenant du fournisseur d'accès Internet (FAI). Sur mon système, l'adresse IP fixe du routeur est 192.168.1.1 et l'adresse IP fixe du Raspberry Pi hôte du serveur RPV est 192.168.1.22. Sans doute, il y a des milliers d'appareils dans le monde entier avec ces adresses particulières. Il n'y a aucun espoir que mon Raspberry Pi puisse être atteint de l'extérieur du LAN en utilisant 192.168.1.22 comme adresse de destination. Ce problème a été résolu avec des algorithmes de routage intelligents. Étant donné sa topologie, toutes les données reçues ou envoyées par un appareil connecté au réseau local transitent par le routeur à 192.168.1.1 découpés en paquets appelés datagramme. Le routeur transmet chaque datagramme à sa destination. En outre, tous les datagrammes du Raspberry Pi destinés vers l'extérieur sont transmis au FAI. Lors de ces transmissions, le routeur change l'adresse IP source des datagrammes du Pi, 192.168.1.22, à une adresse IP publique attribuée au réseau domestique par le FAI. Cette adresse IP publique est unique sur l'ensemble de l'Internet, de sorte que les sites qui reçoivent des paquets d'appareils sur mon réseau local peuvent répondre de manière fiable en utilisant comme IP de destination cette adresse IP publique attribuée par mon FAI. Lorsque le routeur reçoit ces datagrammes, il les achemine vers l'appareil approprié sur le LAN. Il y a évidemment un peu de magie pour savoir quel appareil reçoit quels paquets de données à mesure qu'ils arrivent qui ne sera pas examinée ici. Le fait important à souligner est que pour parler à mon Raspberry Pi de l'extérieur du LAN, l'adresse IP publique attribuée par le FAI doit être connue. Ce n'est pas difficile à trouver. Habituellement, le routeur avec la connexion extérieure à Internet affiche ces informations.

Si on ne trouve pas cette information depuis le routeur, il existe de nombreux sites sur le Web qui afficheront l'adresse IP publique d'un réseau domestique. Je ne vais pas donner d'URL spécifique, ne voulant plus de messages proposant un autre site bien meilleur. Une recherche sur le Web avec comme critère quelque chose d'aussi simple que « mon ip » devrait donner de bons résultats.

Si seulement c'était si simple. Malheureusement, l'adresse IP publique ne peut pas être utilisée, car elle est attribuée dynamiquement par le FAI et peut changer de temps en temps. Tout serveur DHCP peut forcer un client à se reconnecter à tout moment et peut modifier l'adresse IP attribuée à ce stade. Typiquement, le serveur DHCP réserve l'adresse IP attribuée à un client pour un certain «bail» pour lui attribuée de nouveau s'il se déconnecte pour une courte période. Une fois qu'un client est déconnecté et que le bail expire, le serveur DHCP peut attribuer l'adresse IP à tout client se connectant. Je n'ai aucune idée de la durée du bail, mais il y des indications qu'avec certains FAI il peut être très court. En ce qui me concerne, j'ai observé que je pouvais avoir la même adresse IP publique pendant de nombreuses journées. Cela s'explique peut-être par la présence d'appareils tels que des assistants vocaux et des téléphones intelligents qui semblent appeler le « vaisseau mère » assez souvent pour sans cesse renouveler le bail. Ainsi, pendant tout le temps que j'ai mis à écrire ce billet, l'adresse publique (et fictive) du réseau était 168.102.82.120 et j'aurai pu utiliser celle-ci directement pour tester la configuration WireGuard plus tard. D'autres n'auront pas cette chance.

En pratique cependant, il faut éviter d'utiliser une adresse IP dynamique. Au lieu de cela, le réseau local doit être atteint via un nom d'hôte dynamique. DNS est le système de nom de domaine qui traduit le nom d'un site Web, par exemple www.google.com en une adresse IP comme 172.217.6.4 quelques fois. Certains sites proposent un service, souvent gratuit, qui associe un nom de domaine à une adresse IP. Ces sites mettent à jour les adresses IP de leur base de données à intervalles réguliers. Nous allons donc mettre dans la requête HTML le nom de domaine obtenu auprès du service DNS. Le DNS traduira ce nom en une adresse IP qui sera mise à jour chaque fois que le FAI attribue une adresse IP différente au serveur domestique. Il existe de nombreux sites sur le Web qui décrivent comment configurer un nom de domaine dynamique avec l'un des nombreux fournisseurs DDNS et parmi eux il y a ma propre description de l'utilisation de freedns.afraid.org qui date de 2018. En conclusion, procurez-vous un nom d'hôte dynamique et apprenez à signaler tout changement dans l'adresse IP publique attribuée à votre réseau au service DDNS choisi.

Dans ce qui suit, mon nom d'hôte dynamique est supposément modomo.twilightparadox.com qui est, je l'espère, un nom fictif.

Réacheminement d'un port UDP toc

Une partie de la magie derrière le routage des datagrammes par le routeur est que chaque paquet de données provient d'un «port» spécifique et est adressé à un «port» spécifique. Les ports ne sont pas des entités physiques, ils ressemblent plus à un numéro d'appartement ajouté à une adresse postale pour s'assurer qu'une lettre parvient à la bonne boîte aux lettres. Dans le jargon, ce sont des "points d'extrémité" d'une liaison de communication et doivent être attachés à la fin d'une adresse IP ou d'un nom d'hôte. Par exemple, les datagrammes de contrôle FTP envoyés de l'ordinateur de bureau au Raspberry Pi ont comme adresse de destination 192.168.1.22:21 où 21 est le port attribué justement au protocole FTP. Certains numéros de port sont implicites. Tout le trafic HTTP est généralement envoyé au port 80, tandis que le trafic HTTPS est envoyé au port 443. Essayez https://www.google.com:9090 dans un navigateur. La requête sera bien envoyée à google.com, mais le moteur de recherche "n'écoute" pas au port 9090, donc rien ne sera affiché à moins que vous ne soyez très patient et alors une sorte de message d'erreur peut apparaître. Essayez https://www.google.com:443 et vous verrez la page de recherche familière très rapidement, mais vous n'avez pas à écrire le numéro de port, c'est implicite le protocole HTTPS.

Pour des raisons de sécurité, les routeurs grand public tels que celui fourni par un FAI ont un pare-feu intégré qui contrôle le trafic réseau entrant et sortant. En règle générale, le trafic sortant ne peut être envoyé que si le point d'extrémité (c'est-à-dire le port) est destiné à une utilisation "bien connue". De même, le trafic entrant est bloqué purement et simplement à moins qu'il ne fasse partie d'un échange initié par un appareil sur le LAN. C'est pourquoi vous pouvez utiliser un navigateur Web depuis votre ordinateur personnel pour lire cet article! Il y a un problème évident pour nous. Comment atteindre le Raspberry Pi si le pare-feu ne laisse pas passer les paquets IP destinés au Pi. Donc, un "trou" doit être percé à travers le pare-feu. En termes techniques, une règle de redirection de port doit être établie. Cette règle demandera au pare-feu d'expédier tout datagramme adressé au bon port vers le Pi.

OpenVPN , qui est un RPV très populaire, utilise un port de destination par défaut, 1194 pour être précis, bien que cela puisse être modifié. En outre, quel que soit le port utilisé par OpenVPN , il s'identifiera lorsqu'il sera interrogé avec un scanneur de port. WireGuard n'a pas de port par défaut et ne répondra pas si le port qu'il utilise est testé. Cela signifie que lors de la configuration ultérieure de WireGuard, vous devrez choisir un numéro de port. Ces derniers sont des entiers de 16 bits, ce qui signifie qu'ils ont une plage de 0 à 65435. Cependant, choisir un nombre entre 0 et 1023 est généralement une mauvaise idée. En règle générale, les tutoriels sur l'installation de WireGuard utilisent des nombres relativement importants tels que 53133 qui sont dans la la gamme d'adresses dynamiques, privées ou éphémères.

Il est difficile de donner des instructions sur la mise en œuvre de la redirection de port car chaque modèle de routeur est différent. Sur le mien, il y a un onglet pour le Réacheminement de port dans le menu de base et un bouton Ajouter une règle qui activé affiche la fenêtre ci-dessous.

Comme on peut le voir, le routeur veut transmettre une plage de ports, j'ai donc spécifié une plage ne contenant qu'un port. J'ai utilisé le même numéro de port pour le port public (face à Internet) et pour le port privé (sur le réseau local). Ce dernier sera ajouté à l'adresse IP locale, 192.168.1.22. Dans mon cas, tous les datagrammes envoyés de l'extérieur à modomo.twilightparadox.com:53133 seront envoyés à 168.102.82.120:53133. Le routeur transféra ces datagrammes vers sa destination locale: 192.168.1.22:53133. Si tout est correctement configuré , WireGuard saura quoi en faire.

Si vous ne parvenez pas à configurer les règles de transfert de port sur votre routeur, il existe des sites tels que PF Network Utilities qui contiennent des informations sur de nombreux modèles de routeur. Ils proposent également des utilitaires qui effectuent diverses fonctions y compris la redirection de port. Sachez que ceci n'est pas une recommandation, car je suis beaucoup trop paranoïaque pour installer un tel logiciel et surtout beaucoup trop radin pour payer pour ce genre d'application. Cependant, il me faut avouer que le site a fourni des informations précises sur mon routeur, mais elles étaient cachées derrière beaucoup de publicité.

Activation du transfert IP toc

Si l'accès à d'autres ressources du LAN telles qu'une caméra IP ou un serveur Web est nécessaire, le transfert IP doit être activé sur l'ordinateur hébergeant le serveur WireGuard. Si vous n'activez pas le transfert IP, vous ne profiterez pas pleinement du réseau privé virtuel. Je le répète, sauter le transfert IP n'a de sens que si le seul périphérique qui doit être atteint de l'extérieur avec le RPV est la machine hôte WireGuard.

pi@oldpi:~ $ cd /etc pi@oldpi:/etc $ ls -l sysctl* -rw-r--r-- 1 root root 2683 Apr 8 06:56 sysctl.conf sysctl.d: total 8 -rw-r--r-- 1 root root 51 Nov 26 2018 98-rpi.conf lrwxrwxrwx 1 root root 14 Apr 8 07:51 99-sysctl.conf -> ../sysctl.conf -rw-r--r-- 1 root root 639 May 17 2018 README.sysctl

Le fichier /etc/sysctl.d/99-sysctl.conf est un lien symbolique vers le véritable fichier de configuration /etc/sysctl.conf. Il suffira de modifier ce dernier pour activer le transfert des databrammes IP.

pi@oldpi:/etc $ sudo nano sysctl.conf

Changer

... # Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1 ...

à

# Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1

comme indiqué dans le fichier de configuration. Le transfert sera activé au prochain redémarrage du Raspeberry Pi. La dernière commande ci-dessous montre comment le vérifier.

pi@oldpi:~ $ sudo reboot Connection to oldpi.local closed by remote host. Connection to oldpi.local closed. ... michel@hp:~$ ssh pi@oldpi.local ... ... pi@oldpi:~ $ sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1

Configuration de WireGuard toc

La configuration de WireGuard est probablement la partie la plus compliquée de la configuration du RPV. Il existe de nombreux didacticiels expliquant comment procéder, à commencer par le guide de démarrage rapide de WireGuard. Franchement, je ne pouvais pas en tirer grand-chose, car mes connaissances au sujet de la configuration des interfaces réseau, le routage IP et ainsi de suite étaient et demeurent insuffisantes. J'ai trouvé d'autres ressources sur le Web qui m'ont aidé, mais en fin de compte, j'ai trouvé qu'Adrian Mihalko, qui a fourni les instructions pour installer WireGuard sur le Raspberry Pi, a également créé un script de gestion des utilisateurs parfaitement adapté à mes besoins et à mon niveau de compréhension. Je voulais un serveur RPV sur le réseau domestique et des clients RPV sur les appareils Android (peut-être iOS) et c'est précisément ce que le script facilite.

Les instructions ci-dessous sont très détaillées, peut-être trop. Si vous vous débrouillez en anglais, Je vous suggère de lire User management with Wireguard User Management Script de Adian Milhalkola et de revenir ici pour plus d'informations si nécessaire.

Il peut être utile de soulever un petit point ici. WireGuard exploite un réseau d'égal à égal (peer-to-peer). Cependant, il est parfois utile de le voir comme un réseau client-serveur, où le serveur qui s'exécute sur le Raspberry Pi est exactement le même programme qui s'exécute sur un portable Linux même si ce dernier n'est utilisé que comme client. En fin de compte, pair, serveur, client et utilisateur sont souvent la même chose. Espérons que cela ne sera pas source de confusion.

Installation du script de gestion des utilisateurs de Adrian Mihalko toc

Il y a un prérequis utilisé pour générer des images de code QR qui faciliteront la configuration d'un client WireGuard sur un appareil Android ou iOS.

pi@oldpi:~ $ $ sudo apt install qrencode -y Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libqrencode4 The following NEW packages will be installed: libqrencode4 qrencode 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 71.8 kB of archives. After this operation, 145 kB of additional disk space will be used. ... Setting up libqrencode4:armhf (4.0.2-1) ... Setting up qrencode (4.0.2-1) ...

Ensuite, il faut télécharger une archive contenant le script et les fichiers de support et extraire son contenu dans un répertoire qui sera appelé ~/wp_config.

pi@oldpi:~ $ wget https://github.com/adrianmihalko/wg_config/archive/master.zip --2020-07-02 19:00:52-- https://github.com/adrianmihalko/wg_config/archive/master.zip Resolving github.com (github.com)... 140.82.112.4 ... 2020-07-02 19:00:53 (2.60 MB/s) - ‘master.zip’ saved [3688/3688] pi@oldpi:~ $ unzip -j master.zip -d wg_config Archive: master.zip 3e27f97b45b201603d9522d41959b356e787260b inflating: wg_config/README.md inflating: wg_config/client.conf.tpl inflating: wg_config/server.conf.tpl inflating: wg_config/user.sh inflating: wg_config/wg.def.sample pi@oldpi:~ $ mkdir downloads pi@oldpi:~ $ mv master.zip downloads/wg_config_script.zip

J'ai choisi de créer un répertoire nommé ~/downloads et d'y déplacer l'archive de script avec un nom plus significatif, mais l'archive pouvait être simplement supprimée.

Il est possible d'installer le prérequis, qrencode et le programme de contrôle de version git puis de faire le clonage du script depuis son référentiel quitte à utiliser plus d'espace de stockage.
pi@oldpi:~ $ sudo apt install git qrencode -y ... pi@oldpi:~ $ git clone https://github.com/adrianmihalko/wg_config.git Cloning into 'wg_config'...

La liste d'étapes suivante peut sembler décourageante; il est en fait assez facile de configurer le serveur WireGuard et d'ajouter des clients ou des pairs avec le script.

Création des clés privées et publiques du serveur toc

WireGuard crypte le flux de données transféré sur le réseau virtuel à la façon de SSH. Le serveur et le client (ou les pairs en fait) échangent des clés d'authenfications publiques lorsqu'une connexion est établie. Ces clés publiques doivent correspondre à des clés privées qui, à l'instar de SSH encore une fois, ont été partagées « hors bande » préalablement. Dans ce cas, cela signifie que les clés privées doivent être copiées manuellement dans les fichiers de configuration de chaque pair. C'est l'une des différences importantes avec OpenVPN qui authentifie les connexions à l'aide de certificats SSL dont la validité est assurée par une «autorité de certification» tierce comme pour le protocole HTTPS. Bien que des certificats SSL gratuits sont disponibles, et que leur renouvellement régulier peut être automatisé, j'aime bien qu'on évite toute cette gestion avec WireGuard.

Donc la première étape de la configuration du RPV, étape n'est effectuée qu'une seule fois, est la création des clés privées et publiques du serveur WireGuard sur le Raspberry Pi.

pi@oldpi:~ $ cd wg_config pi@oldpi:~/wg_config $ wg genkey | tee server_private.key | wg pubkey > server_public.key

Puisque j'ai trouvé la commande difficile à déchiffrer, je l'ai décomposée pour confirmer qu'elle correspond aux deux commandes suivantes.

pi@oldpi:~ $ wg genkey > server_private.key pi@oldpi:~ $ wg pubkey > server_public.key < server_private.key

Ces deux clés sont nécessaires dans les étapes suivantes. Copiez-les dans un éditeur de texte sur le bureau ou ouvrez une deuxième session SSH sur le Raspberry Pi pour un accès facile aux clés plus tard.

pi@oldpi:~/wg_config $ cat server_public.key 5lFoBBjeLcJWC9xqS/Kj9HVwd0tRUBX/EQWW2ZglbDs= pi@oldpi:~/wg_config $ cat server_private.key aA+iKGr4y/j604LtNT+MQJ76Pvz5Q5E+qQBLW40wXnY=

Il ne faut jamais rendre publique une clé privée. Ainsi, les clés affichées ci-dessus le sont uniquement à des fins de démonstration, et vous devez remplacer ces valeurs par celle réellement générée.

Création et modification du fichier de définition de serveur toc

Cette étape, effectuée une seule fois, crée le fichier wg.def contenant les données que le script utilisera pour créer les fichiers de configuration du serveur et des clients.

pi@oldpi:~/wg_config $ cp wg.def.sample wg.def pi@oldpi:~/wg_config $ nano wg.def

Voici le contenu du modèle.

_INTERFACE=wg0 _VPN_NET=192.168.99.0/24 _SERVER_PORT=51820 _SERVER_LISTEN=wg.example.com:$_SERVER_PORT _SERVER_PUBLIC_KEY= _SERVER_PRIVATE_KEY=

Et voici la version modifiée selon les paramètres locaux.

_INTERFACE=wg0 _VPN_NET=192.168.99.0/24 _SERVER_PORT=53133 _SERVER_LISTEN=modomo.twilightparadox.com:$_SERVER_PORT _SERVER_PUBLIC_KEY=5lFoBBjeLcJWC9xqS/Kj9HVwd0tRUBX/EQWW2ZglbDs= _SERVER_PRIVATE_KEY=aA+iKGr4y/j604LtNT+MQJ76Pvz5Q5E+qQBLW40wXnY=

Je n'ai pas modifié le nom de l'interface réseau qui sera créée par WireGuard. Je suggère d'en faire autant au début. Si le sous-réseau 192.168.99.0 est déjà utilisé sur le réseau local, la valeur de _VPN_NET devra être modifiée. Typiquement, cela implique une autre valeur xxx dans 192.168.99.xxx. Le port UDP qu'utilisera le RPV est affecté au paramètre _SERVER_PORT. J'ai décidé d'utiliser un autre port que celui suggéré, mais il n'en sera pas question ici. Rappelons toutefois que c'est vers ce port que le routeur redirigera le flux de données externes transitant à travers le RPV et qu'il faut donc que _SERVER_PORT corresponde au port redirigé. Bien sûr, il était nécessaire de remplacer wg.example.com dans _SERVER_LISTEN par le nom d'hôte du Raspberry Pi qui, dans mon cas (fictif), est: modomo.twilightparadox.com comme expliqué dans 2.2 Adresse IP publique et dynamique de l'hôte. Ne mettez pas le préfixe de protocole tel que https://, seulement le nom de domaine. Comme je l'ai expliqué ci-dessus, l'adresse IP publique qui m'a été attribuée par mon FAI change si rarement que je pourrais m'en tirer avec l'adresse IP publique au lieu d'un nom d'hôte à des fins de test.

Si la notation CIDR telle 192.168.99.0/24 n'est pas familière, pensez simplement à l'entier de fin après la barre oblique comme le nombre de bits 1 les plus significatifs fixes dans le masque de sous-réseau. Voilà qui est bien clair! L'élaboration de l'exemple vous aidera peut-être. Le masque de sous-réseau est de 32 bits (ou 4 octets) dont les 24 les plus significatifs sont des 1 et les 8 bits les moins significatifs sont de 0. Par conséquent, le masque est 255.255.255.0

. Ainsi, les pairs du réseau virtuel auront des adresses IP dans le bloc 192.168.99.xxx. Le serveur sera à 192.168.99.1, le premier client à 192.168.99.2, le second à 192.168.99.3 et ainsi de suite. Le script gérera automatiquement cette allocation séquentielle d'adresses IP.

Modification du modèle de la configuration des clients toc

Le modèle de configuration client client.conf.tpl, utilisé par le script pour créer chaque fichier de configuration utilisateur (ou client) est assez court.

[Interface] Address = $_VPN_IP PrivateKey = $_PRIVATE_KEY [Peer] PublicKey = $_SERVER_PUBLIC_KEY AllowedIPs = 0.0.0.0/0 Endpoint = $_SERVER_LISTEN

J'ai modifié la valeur du paramètre AllowdIPs qui spécifie les adresses IP des datagrammes peuvant transiter sur le RPV.

pi@oldpi:~/wg_config $ nano client.conf.tpl

[Interface] Address = $_VPN_IP PrivateKey = $_PRIVATE_KEY [Peer] PublicKey = $_SERVER_PUBLIC_KEY AllowedIPs = 192.168.99.1/32, 192.168.1.0/24 Endpoint = $_SERVER_LISTEN

Notez que la première address admissibles dans AllowedIPs soit 192.168.99.1/32 est l'adresse du serveur WireGuard sur le réseau virtuel créé par ce dernier et le masque de 32 bits signifie que les clients/utilisateurs ne pourront pas atteindre une autre adresse IP sur le sous-réseau 192.168.99.xxx. La deuxième adresse IP autorisée 192.168.1.0/24, soit le bloc d'adresses 192.168.1.xxx, est mon réseau local domestique. Le Raspberry Pi a une adresse IP statique sur ce réseau 192.168.1.22, le modem-câble/routeur fourni par le FAI est à 192.168.1.1 et son serveur DHCP intégré alloue des adresses IP dans la plage 192.168.1.100-200 où la plupart des dispositif IoT se trouvent. Vous devrez bien sûr ajuster AllowedIPs pour faire référence aux adresses IP correctes dans votre situation particulière. Il se peut que votre LAN soit sur le sous-réseau 192.168.1.xxx comme ci-dessus, ou 192.168.0.xxx, mais certains réseaux locaux utilisent d'autres blocs d'adresses IPv4 privéestels que 10.0.3.xxx.

Modification du modèle de la configuration du serveur toc

Dans le modèle de configuration du serveur, il est supposé que le nom de l'interface réseau utilisée par l'hôte du serveur WireGuard est eth0. Dans mon cas, ce n'est pas correct, le Raspberry Pi est connecté au réseau local par Wi-Fi, il était donc nécessaire de modifier le modèle de configuration du serveur.

pi@oldpi:~/wg_config $ nano server.conf.tpl
[Interface] Address = $_SERVER_IP ListenPort = $_SERVER_PORT PrivateKey = $_SERVER_PRIVATE_KEY PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o wlan0 -j MASQUERADE

L'interface eth0 est remplacée par wlan0 dans les lignes PostUp et PostDown qui définissent les modifications apportées à iptables, définissant le routage des datagrammes, lors de l'activation ou de la désactivation du RPV. Heureusement, il n'est pas nécessaire de comprendre les détails de tout ceci.

Encore une fois, ce changement ne doit être effectué qu'une seule fois, voire pas du tout.

Création d'une configuration initiale du serveur WireGuard toc

Si le fichier de configuration (vide) wg0.conf n'a pas été créé lors du test de l'installation de WireGuard dans la section intitulée Verification de l'installation , il est maintenant temps de le faire.

pi@oldpi:~/wg_config $ cd .. pi@oldpi:~ $ sudo touch /etc/wireguard/wg0.conf

Cela se fait une seule fois. Le script de gestion des utilisateurs met à jour ce fichier chaque fois qu'il est utilisé pour ajouter ou supprimer un utilisateur. Par conséquent, le fichier ne doit pas être modifié manuellement.

Gestion du service WireGuard toc

Lors de la première installation de WireGuard et lors du test de l'installation du serveur, il est utile de démarrer et d'arrêter manuellement le service. Ceci est fait avec l'utilitaire wg-quick.

démarrer le service : pi@oldpi:~ $ sudo wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip link set mtu 1420 up dev wg0 arrêter le service : pi@oldpi:~ $ sudo wg-quick down wg0 [#] ip link delete dev wg0

Notez que la sortie sera plus volumineuse lorsque le fichier de configuration du serveur sera finalement créé plus tard.

Encore une fois, lors des tests, il peut être utile de vérifier l'état du serveur RPV. Cela peut être fait avec l'utilitaire de contrôle de systemd et avec l'utilitaire wg.

pi@oldpi:~ $ sudo systemctl status wg-quick@wg0 ● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0 Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled) Active: active (exited) since Fri 2019-03-05 16:50:49 ADT; 20min ago Docs: man:wg-quick(8) man:wg(8) https://www.wireguard.com/ https://www.wireguard.com/quickstart/ https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8 https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8 Process: 378 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS) Main PID: 378 (code=exited, status=0/SUCCESS) Jul 03 16:48:58 domo systemd[1]: Starting WireGuard via wg-quick(8) for wg0... Jul 03 16:50:46 domo wg-quick[378]: [#] ip link add wg0 type wireguard Jul 03 16:50:46 domo wg-quick[378]: [#] wg setconf wg0 /dev/fd/63 Jul 03 16:50:47 domo wg-quick[378]: [#] ip address add 192.168.99.1/24 dev wg0 Jul 03 16:50:47 domo wg-quick[378]: [#] ip link set mtu 1420 up dev wg0 Jul 03 16:50:49 domo systemd[1]: Started WireGuard via wg-quick(8) for wg0. pi@oldpi:~ $ sudo wg interface: wg0 listening port: 54130

Ce qui précède n'est qu'une indication des informations qui peuvent être affichées. Cela dépendra du nombre de pairs/clients qui ont été mis en place. Encore plus d'informations seront affichées y compris le nombre d'octets transmis et reçus si un client ou un pair a créé un tunnel (c'est-à-dire ouvert une connexion RPV).

Une fois WireGuard correctement installé, on peut s'assurer que le serveur soit démarré automatiquement avec la commande systemctl habituelle.

pi@oldpi:~ $ sudo systemctl enable wg-quick@wg0 Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.

Cela n'est généralement fait qu'une seule fois. Dès lors, chaque fois que le Raspberry Pi est démarré systemd active le serveur RPV. Si, pour une raison quelconque, le serveur WireGuard ne doit plus être démarré automatiquement, utilisez la commande disable.

pi@oldpi:~ $ sudo systemctl disable wg-quick@wg0 Removed /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service.

Il sera possible de réactiver le service ultérieurement. Si on y réfléchit, un serveur RPV devrait être actif à tout moment.

Gestion des utilisateurs toc

Adrian Mihalko discute de la configuration d'un client mobile sur IOS à l'aide de son script. Ci-dessous, je montre comment utiliser le même script pour configurer des clients sous Android, Windows 10 et Linux. Comme on le verra, une fois la configuration décrite ci-dessus terminée, l'ajout d'utilisateurs avec le script est assez simple.

Ajout d'utilisateurs toc

Lorsqu'il est utilisé pour créer un nouvel utilisateur, le script user.sh crée un fichier de configuration pour l'instance de WireGuard exécutée sur la machine de l'utilisateur et met à jour le fichier de configuration du serveur pour accepter une connexion RPV (ou tunnel si l'on préfère) du nouveau client. La création d'un utilisateur est très simple, démarrez WireGuard(le fichier de configuration wg0.conf doit exister même s'il est vide), puis exécutez le script user.sh avec l'option -a suivie d'un nom unique identifiant l'utilisateur (ou client) à créer.

pi@oldpi:~ $ sudo wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip link set mtu 1420 up dev wg0 pi@oldpi:~ $ cd wg_config pi@oldpi:~/wg_config $ sudo ./user.sh -a nexus7
█████████████████████████████████████████████████████████████
████ ▄▄▄▄▄ █ ▄▄▄█  ▄ ██▀  █▄█▀▀▄▄██▄ █▀█  ▄ █▄ ▀██ ▄▄▄▄▄ ████
████ █   █ █  ▀▄▀█ ██ █▄▀▀▀▄▀▄  ▄▀▄ █ █▄▀▄▄█▀ ▀▄▀█ █   █ ████
████ █▄▄▄█ █▀▄▀█ ▀▀▀▄▄▀▄▀▄ ▀ ▄▄▄ ▄▄  ▄▄▀█▀▀█▀▀ ███ █▄▄▄█ ████
████▄▄▄▄▄▄▄█▄▀ █▄▀▄█ ▀▄▀ ▀▄▀ █▄█ █ █ █ █▄█ ▀ █▄█▄█▄▄▄▄▄▄▄████
████ ▄█▀ ▄▄▀▀▀   ▄ ▄█▀ ▄▀▄ ▀ ▄  ▄█▄  ▄▀██  ▀█▄ █ ▀█▄▀  ▄ ████
█████▀▀▄█ ▄ ▄ █▀▀▄▄▀  ▀██▄▄▄▀▄█▀█ ▄▄▀ █▀   ▀▄▀ ▀▄ ██▀▄█▀ ████
████▄▄▄▀▀▀▄▀█▀▄██▄▀█ ▀█ ▀█▀█ ▀█▀█▀ ▀ █▀▄█▄█▄██ ▀██▀█ █▀▄▀████
████▄▄▀▄▀ ▄█▀▄ █▄▄ ▀ ▀█ █  ▀ ▀█▄ ██▄ ▀ █▄▄▀█▄▀▄▄ ▄▀▀  █▄ ████
█████▄▄▄▄█▄ ▄▀▄▄▄▀▀▀▀█ █▀ ▄▄ ▄▄▀▄██ ██ █ ▀ █▀▀█ ▄▀█  █▀▀▀████
████▀▀▀   ▄▄  ▄▄███▄█ ▀█▄▄ █ ▄█▀██ ▀▄▀ ▄█▄ ▄ ▀ ██▀█▄▀▄█▀▄████
█████▀▄▄█ ▄▄▀██▀█▄ ▄ ▀█  █ ██▀▀▄ ▀▀▀ █ ▄▀▄▄▀██▀▀▀▄▀█▀▀▀▄ ████
████▀▀▀██ ▄█▄█ █▄▀█▄ ▀  █ ▀ ▄▀█▄ ▄▄▀▀▄▀▄▄▀████▀▄ ▀ ▀▄▀▄▄█████
██████▄▄ ▄▄▄  █▄▀▄ ▄█▄▀▄▀▄▄▀ ▄▄▄ ▄▄  ▄▀█▀ ▄▄ ▄▄▄ ▄▄▄  ▀▄▀████
█████▀█▀ █▄█ ▄███▄ ▀ ▄▄█ ▀▄  █▄█ ▀█▄▀ ▀█▄ ▄ ▄ ██ █▄█ █ █ ████
█████▄▀  ▄▄ ▄█▀▄█▄▀▄▄█▄ ▄▀▄█▄▄▄▄▄█ ▀ ▀▀▄▀ ▄█▄█ ▀▄▄   ▄▀▀ ████
████▄ ▄▀▄▄▄▀█▀▀██▄ ▄▀▄█▀  █▀▀█ █▄▀▀▄ ▄█▄ █▀▀▀▄  █▀▄  ▀▄▄▄████
████▀██ ▄▄▄▄█▄▀██▀▀▀▀▀ ▄▀ █ ▀ ▄███▀▄▄████▀▀ ██▄ ▄ ▀▄▄▄▀██████
████▄█▀ ▀▀▄█▀█▀▄▀██▄█▀ ▀█▄▀▀▀█  ███▀▄█ ▄█▄  ▄▄▀▀▄ █▀██▄█▄████
█████▀ █▄ ▄ ██▀██▄ ▄▄█▀▀▄▀▀▄█▀  ██▄▀ ▀▄▄█▄▄▀▀▀▀   ██ ▀▀█ ████
████ ▄▄▀█▀▄ █▀▄  ▀█▀ ▀ █▀▀▀▄▀ █▄█ ▀▀█ ▄▄▀█▄ █  ▀██▄█▀ █ ▄████
████▄▀▄▄▀█▄▀▄▄▄▀ ▄ ▄█▄▀█▀▄▄  ▄▄█▀█▄▄▄█▄▀▀ ▄█▀ ▀▀▄ ███ ▀ █████
████▄ ▀▄▄▄▄ ▀ ██ █▄▀ ███ ▄█▀ ██▀█  ▄▀ ▀▀█ ▄███  █▄█▀ ▄▀█ ████
███████▄██▄█▀ ▀▄▄  ▄ █▄ ██▀█ ▄▄▄ ▀█▀ ▀██▀▄▀▀▀██▄ ▄▄▄  ▀ ▀████
████ ▄▄▄▄▄ █▀▀█  ▀  █▄██▀▀▄▄ █▄█ ▀██▀▀█▀▀▄ ██▄▄▄ █▄█  ▄ █████
████ █   █ █▄  ██▄ ▀▀▀ █▄ ▄▄▄▄▄ ▄██ ▀▄███ ▀ ▀██▄ ▄▄  ▄▀▀▄████
████ █▄▄▄█ █▀█▀ ▀▀▀▄█ ▄▀ ▀▄█▄▀▄ ▀█ ▄█▀█▄█▄   ▀▄▀██▀██▄█  ████
████▄▄▄▄▄▄▄█▄▄▄▄▄▄▄▄▄█▄█▄█▄██▄█▄▄█▄█▄█▄█▄▄███▄▄█▄▄▄▄▄▄█▄█████
█████████████████████████████████████████████████████████████

Le message suivant

Unable to modify interface: No such device wg set failed

sera imprimé juste en dessous des codes QR si le service WireGuard ne fonctionne pas sur le Pi. Dans ce cas, réexécutez les deux commandes ci-dessus. Ne vous inquiétez pas du code QR, il peut être affiché plus tard si nécessaire pour configurer le client WireGuard sur l'appareil Android ou iOS. Le script s'exécute très rapidement mais il a fait néanmoins pas mal de travail.

Voici le contenu du répertoire utilisateur qui vient d'être créé.

pi@oldpi:~/wg_config $ ls -l users/nexus7 total 24 -rw-r--r-- 1 root root 216 Jul 5 17:49 client.all.conf -rw-r--r-- 1 root root 216 Jul 5 17:49 client.conf -rw-r--r-- 1 root root 913 Jul 5 17:49 nexus7.all.png -rw-r--r-- 1 root root 913 Jul 5 17:49 nexus7.png -rw-r--r-- 1 root root 45 Jul 5 17:49 privatekey -rw-r--r-- 1 root root 45 Jul 5 17:49 publickey

Il y a deux fichiers de configuration du client, client.conf et client.all.conf et deux images de code QR qui correspondent à ces configurations. Un ou les deux seront utilisés pour configurer le client Android ou iOS plus loin. Enfin, comme avec le serveur WireGuard, le client dispose d'une clé de chiffrement privée et d'une clé publique.

Voici le contenu de l'un des fichiers de configuration du client et du fichier de configuration du serveur.

pi@oldpi:~/wg_config $ cat users/nexus7/client.conf [Interface] Address = 192.168.99.2/24 PrivateKey = gH5xInhP2NZw0t8hVgJPhTRDUh3Bir7FEynRcW8IHlg= [Peer] PublicKey = 5lFoBBjeLcJWC9xqS/Kj9HVwd0tRUBX/EQWW2ZglbDs= AllowedIPs = 192.168.99.1/32, 192.168.1.0/24 Endpoint = modomo.twilightparadox.com:53133 pi@oldpi:~/wg_config $ sudo cat /etc/wireguard/wg0.conf [Interface] Address = 192.168.99.1/24 ListenPort = 53133 PrivateKey = aA+iKGr4y/j604LtNT+MQJ76Pvz5Q5E+qQBLW40wXnY= PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o wlan0 -j MASQUERADE [Peer] PublicKey = BEnqBZ6rWcDO6lKhb6oXM7aRvE7fuIWCZw1PxgyMMyE= AllowedIPs = 192.168.99.2/32

Un fichier de configuration WireGuard comporte deux sections. La première, [Interface], définit l'adresse IP du client ou du serveur sur le réseau virtuel. Comme déjà mentionné, le script attribuera la première adresse IP valide sur le réseau virtuel, 192.168.99.1 au Raspberry Pi hébergeant le serveur. Le script a donc attribué l'adresse valide suivante, 192.168.99.2 au client Nexus 7. Le script a également généré des clés publiques et privées pour le client et le serveur et inclut la clé privée de chacun dans sa définition d'interface. La deuxième partie du fichier de configuration répertorie tous les pairs avec lesquels un tunnel peut être établi. Pour créer la connexion virtuelle, le client doit savoir comment atteindre le serveur (le Endpoint de son homologue) et sa clé publique. De même, le serveur doit connaître sa propre adresse, sur quel port UDP il écoute, ainsi que l'adresse IP et la clé publique de tout client (pair) qui sera autorisé à créer un tunnel. Peut-être que voir les deux fichiers de configuration côte à côte rend ces liens plus évidents.

Il existe un deuxième fichier de configuration utilisateur.

pi@oldpi:~/wg_config $ cat users/nexus7/client.all.conf [Interface] Address = 192.168.99.2/24 PrivateKey = gH5xInhP2NZw0t8hVgJPhTRDUh3Bir7FEynRcW8IHlg= [Peer] PublicKey = 5lFoBBjeLcJWC9xqS/Kj9HVwd0tRUBX/EQWW2ZglbDs= AllowedIPs = 0.0.0.0/0 Endpoint = modomo.twilightparadox.com:53133

Il est identique au premier sauf pour le champ AllowdIPs. J'utilise les deux fichiers de configuration comme expliqué ci-dessous.

Pour ajouter un utilisateur supplémentaire, répétez simplement les étapes. N'oubliez pas de démarrer le serveur WireGuard s'il n'est pas déjà en cours d'exécution.

pi@oldpi:~ $ cd wg_config pi@oldpi:~/wg_config $ sudo ./user.sh -a zenfone pi@oldpi:~/wg_config $ ls users nexus7 zenfone

Un nouveau répertoire, contenant les nouveaux fichiers de configuration utilisateur, est créé à côté des répertoires des utilisateurs déjà définis. Le script met à jour sa propre liste d'adresses IP attribuées aux clients et leurs clés publiques.

pi@oldpi:~/wg_config $ cat .saved nexus7 192.168.99.2/24 BEnqBZ6rWcDO6lKhb6oXM7aRvE7fuIWCZw1PxgyMMyE= zenfone 192.168.99.3/24 dVq8SvBwcKrFnBBQL2F7JcsVNB4jSf6f3kbtfnsYGCA=

Il supprime également ces adresses IP attribuées de la liste des adresses IP disponibles.

pi@oldpi:~/wg_config $ cat .available_ip 192.168.99.4/24 192.168.99.5/24 ... 192.168.99.253/24 192.168.99.254/24

Un nouveau fichier de configuration /etc/wireguard/wg0.conf est créé par le script.

[Interface] Address = 192.168.99.1/24 ListenPort = 53133 PrivateKey = aA+iKGr4y/j604LtNT+MQJ76Pvz5Q5E+qQBLW40wXnY= PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o wlan0 -j MASQUERADE [Peer] PublicKey = BEnqBZ6rWcDO6lKhb6oXM7aRvE7fuIWCZw1PxgyMMyE= AllowedIPs = 192.168.99.2/32 [Peer] PublicKey = dVq8SvBwcKrFnBBQL2F7JcsVNB4jSf6f3kbtfnsYGCA= AllowedIPs = 192.168.99.3/32

Le nouveau client apparaît en tant que client supplémentaire dans la section Peer du fichier de configuration du serveur. C'est tout ce qui doit être fait sur le serveur pour chaque client supplémentaire. L'édition des modèles et ainsi de suite n'a pas à être répété.

Installation d'un client WireGuard sur Android toc

La première étape de l'installation d'un client WireGuard sur un appareil Android consiste à installer l'WireGuard à partir de Google Play. Une fois cela fait, lancez l'application.

start screen

Cliquez sur le bouton bleu comme indiqué..

start screen

Cliquez sur Create from QR code pour obtenir les paramètres de configuration depuis un des codes QR engendré par le script d'Adrian Mihalko.

Les images ci-dessus ont été affichées sur une tablette avec un écran plus grand. Les mêmes étapes doivent être effectuées sur un téléphone intelligent, mais l'apparence sera probablement différente, comme indiqué ci-dessous.

Encore une fois, cliquez sur le bouton + pour « Ajouter un tunnel à l'aide du bouton bleu » comme affiché dans la fenêtre de l'application, puis sélectionnez SCAN FROM QR CODE dans le menu qui s'affiche en bas de l'écran.

Il est maintenant temps d'afficher l'image du code QR sur le Raspberry Pi hébergeant le serveur WireGuard .

pi@oldpi:~/wg_config $ sudo ./user.sh -v nexus7

Cette fois, les deux fichiers de configuration et les images des codes QR correspondants seront affichés, mais il sera nécessaire de faire défiler en arrière pour les voir. Dirigez la caméra de l'appareil Android vers le code QR affiché sur le moniteur de bureau. J'ai commencé avec le code QR du fichier client.conf (avec AllowedIPs = 192.168.99.1/32, 192.168.1.0/24). Une fois les informations acquises, la boîte de dialogue suivante apparaît.

start screen

J'ai nommé le tunnel Rpi3-split puis j'ai appuyé sur le bouton CREATE TUNNEL. J'ai répété les étapes pour ajouter le deuxième tunnel, nommé RPi-all, à partir du deuxième code QR.

start screen

Encore une fois, la disposition sera différente sur le petit écran d'un téléphone, mais fonctionnellement, c'est la même chose.

Dans le plus grand écran, la liste des tunnels est toujours affichée dans le panneau gauche de l'écran et les informations "publiques" sur chaque tunnel sont affichées sur le panneau droit lorsque celui-ci est sélectionné. Dans le petit écran, soit la liste des tunnels est affichée, soit les informations publiques pour un tunnel unique s'affichent lorsqu'il est sélectionné. Dans le dernier cas, il y a une flèche pointant vers l'arrière pour revenir à la liste des tunnels.

Installation de WireGuard sur Windows 10 toc

La sortie d'un client WireGuard officiel fonctionnant dans Windows 10 a été un développement bienvenu pour beaucoup. Il est tout aussi facile d'ajouter des tunnels WireGuard et de les activer qu'avec l' application Android illustrée ci-dessus. Téléchargez d'abord la version 32 ou 64 bits correcte à partir de la page d'installation de WireGuard. Puisque ce sont des fichiers (.msi), un clic avec souris sur l'un de ceux-ci démarre. Et c'est essentiellement tout ce qu'il y a faire pour ce qui est de l'installation. Quand celle-ci est terminée, l' icône rouge de WireGuard apparaît dans la barre d'état de Windows.

La première fois que le client est démarré en cliquant sur l'icône, une liste vide de tunnels est visible et il y a une option, Import tunnel(s) from file, pour importer la définition d'un tunnel ou de plus d'un tunnel ou connexion.

C'est exactement ce que j'ai fait et j'ai été récompensé par ce qui suit.

Bien sûr, cela soulève la question de savoir d'où vient le fichier importé? C'est assez simple. J'ai créé une archive de type zip contenant les deux fichiers de configuration client générés par le script user.sh dont j'avais préalablement changé les noms. Il y a sans doute de nombreuses façons de faire cela, voici comment j'ai procédé.

J'ai téléchargé et installé la dernière version de PuTTY sur une machine Windows 10 que j'ai trouvée ici : Download PuTTY: latest release. Ensuite, j'ai démarré son client SFTP nommé PSFTP à partir du menu et je l' ai utilisé pour télécharger les deux fichiers de configuration client dans le répertoire ~/wg_config/users/winnner du Raspberry Pi crée avec le script user.sh.

psftp: no hostname specified; use "open host.name" to connect psftp> open 192.168.1.129 login as: pi pi@192.168.1.129's password: my_password not echoed to screen Remote working directory is /home/pi psftp> cd wg_config/users/winner Remote directory is now /home/pi/wg_config/users/winner psftp> lcd C:\Users\michel\Documents New local directory is C:\Users\michel\Documents psftp> get client.conf remote:/home/pi/wg_config/users/winner/client.conf => local:client.conf psftp> get client.all.conf remote:/home/pi/wg_config/users/winner/client.all.conf => local:client.all.conf psftp> exit

Après cela, j'ai renommé les fichiers de configuration en quelque chose de plus significatif :

  client.conf      -->  oldpi-split.conf 
  client.all.conf  -->  oldpi-all.conf

J'ai ensuite simplement créé une archive zip nommée oldpi.zip contenant les deux fichiers de configuration renommés. Cela se fait dans l'explorateur des fichiers en sélectionnant les fichiers, puis en cliquant sur l'icône Zip dans le ruban et en ajustant le nom de l'archive. C'est le fichier que j'ai ensuite sélectionné pour importer dans le client WireGuard pour Windows.

Installation de WireGuard sur Linux toc

À ma connaissance, il n'existe pas de client WireGuard pour Linux car le RPV est en fait un réseau de pairs. Ce que nous allons faire, c'est installer WireGuard un hôte Linux comme cela a été fait sur le Raspberry Pi ci-dessus. La seule différence significative sera dans la configuration.

La machine Linux sur laquelle j'ai installé WireGuard est un ordinateur portable déjà vieux sur lequel fonctione Linux Mint 19.2

Xfce que je souhaite utiliser pour me connecter à mon réseau domestique depuis des sites distants. Ma première action a été de mettre à jour le système, puis de vérifier que WireGuard n'était pas déjà installé.

michel@tosh:~$ sudo apt update && sudo apt upgrade -y ... then after a reboot ... michel@tosh:~$ sudo apt-cache policy wireguard* wireguard-dkms: Installé : (aucun) Candidat : 1.0.20200611-1ubuntu1~18.04.1 Table de version : 1.0.20200611-1ubuntu1~18.04.1 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages 500 http://archive.ubuntu.com/ubuntu bionic-updates/universe i386 Packages wireguard-modules: Installé : (aucun) Candidat : (aucun) Table de version : wireguard-tools: Installé : (aucun) Candidat : 1.0.20200513-1~18.04.1 Table de version : 1.0.20200513-1~18.04.1 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages wireguard: Installé : (aucun) Candidat : 1.0.20200513-1~18.04.1 Table de version : 1.0.20200513-1~18.04.1 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages 500 http://archive.ubuntu.com/ubuntu bionic-updates/universe i386 Packages

Même si ce n'est pas la version la plus à jour selon les instructions de WireGuard, je l'ai néanmoins installée depuis le référentiel.

michel@tosh:~$ sudo apt install wireguard ...

Les mêmes tests effectués sur le Raspberry Pi peuvent être utilisés pour vérifier que les modules et outils ont été installés.

michel@tosh:~$ which wg wg-quick /usr/bin/wg /usr/bin/wg-quick michel@tosh:~ $ sudo touch /etc/wireguard/wg0.conf michel@tosh:~ $ sudo wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip link set mtu 1420 up dev wg0 michel@tosh:~$ lsmod | grep wire wireguard 221184 0 ip6_udp_tunnel 16384 1 wireguard udp_tunnel 16384 1 wireguard michel@tosh:~$ ifconfig wg0 ... wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ... michel@tosh:~$ sudo wg interface: wg0 listening port: 53133

La configuration de cette instance de WireGuard tant que « client » ne peut être plus simple. J'ai utilisé FileZila pour copier les fichiers de configuration client.conf et client.all.con depuis le répertoire /home/pi/wg_config/users/tosh du Raspberry Pi. Ces fichiers ont été créés par le script users.sh comme expliqué ci-dessus. Après cela, j'ai renommé les fichiers de configuration en quelque chose de plus significatif 

  client.conf      -->  oldpi-split.conf 
  client.all.conf  -->  oldpi-all.conf

J'ai ensuite déplacé les fichiers de configuration vers le répertoire /etc/wireguard en y effaçan le fichier de configuration vide wg0.conf créé pour tester l'installation mais qui ne sera pas utilisé. Je me suis également assuré que le compte root est le propriétaire des fichiers de configuration, ce qui est une mesure de sécurité supplémentaire.

michel@tosh:~$ sudo mv oldpi-split.conf /etc/wiregard/ michel@tosh:~$ sudo mv oldpi-all.conf /etc/wiregard/ michel@tosh:~$ rm /etc/wiregard/wg0.conf michel@tosh:~$ sudo chown -R root: /etc/wireguard

C'est tout ce qu'il faut pour configurer un client Linux qui est fondamentalement le même que ce qui a été fait pour configurer un client Windows. Il existe trois différences principales avec la configuration du serveur.

Suppression d'utilisateurs toc

Le script user.sh peut être utilisé pour supprimer un seul utilisateur

pi@oldpi:~ $ cd wg_config pi@oldpi:~/wg_config $ sudo ./user.sh -d nexus7

ou tous les utilisateurs à la fois.

pi@oldpi:~ $ cd wg_config pi@oldpi:~/wg_config $ sudo ./user.sh -c

Bien entendu, le fichier de configuration du serveur sera également mis à jour.

Utilisation des clients WireGuard toc

Imaginez le scénario suivant. Je suis assis dans un café et je souhaite voir le flux vidéo d'une caméra IP à la maison. Sur le réseau local, je commencerais VLC pour visionner le flux à l'adresse suivante : rtsp://192.168.1.95/11. Sur ma tablette, je peux faire exactement la même chose si l'application WireGuard est utilisée pour ouvrir l'un des tunnels vers le serveur RPV chez moi et si le serveur RPV WireGuard fonctionne sur le réseau local à la maison.

start screen

Je fais simplement glisser le bouton du tunnel souhaité vers la droite, comme indiqué ci-dessus. Sur mon téléphone Android, les détails de connexion sont affichés en cliquant sur le nom du tunnel, mais l'ouverture d'un tunnel se fait de la même manière, en faisant glisser vers la droite le bouton à côté du tunnel souhaité. Dès que cela est fait, j'ai accès à toutes les ressources de mon réseau domestique 192.168.1.xxx comme si mon appareil Android était connecté directement au réseau local. Je peux donc regarder le flux vidéo rtsp://192.168.1.95/11flux vidéo comme si j'étais à la maison. C'est si simple et pourtant sécurisé. Toute personne épiant le réseau Wi-Fi dans le café ou n'importe où le long de l'itinéraire entre ma tablette et mon routeur domestique verrait des paquets IP avec un contenu crypté. Au lieu de voir l'adresse 192.168.1.95:554 à partir de laquelle on pourrait supposer qu'il y a une caméra IP sur mon réseau domestique (554 est le port implicite du protocole RTSP), l'adresse visible sera 168.102.82.120:53133 qui est l'adresse IP publique du routeur et le port obscur utilisé par l'interface WireGuard qui encode tout le reste de bout en bout, y compris l'adresse de destination finale.

Notez que le client Android donne très peu de retours lors de l'ouverture d'un tunnel. Une petite icône de clé indiquant que le RPV est actif sera affichée en haut de l'écran de l'appareil. Mais cette icône est présente même si les paramètres sont incorrects ou si le serveur WireGuard à la maison n'est pas en ligne. Le seul « symptôme » que quelque chose ne va pas est que tous les périphériques sur le sous-réseau 192.168.1.xxx sont inaccessibles et que l'application WireGuard montrera probablement que le nombre d'octets reçus est zéro.

Et si je décide de consulter les derniers indices boursiers ? Je peux aller à Yahoo! Finance au Canada https://ca.finance.yahoo.com/. Puisque son adresse IP, disons 66.218.84.42, n'est pas sur le sous-reseau 192.168.1.xxx, les datagrammes de cette communication ne passeront donc pas par le tunnel WireGuard. Au lieu de cela, les paquets IP seront acheminés directement vers Yahoo! comme si WireGuard ne fonctionnait même pas. Toute personne qui écoute sur le réseau Wi-Fi peut être en mesure de suivre les données envoyées et reçues par l'appareil Android. En fait, c'est exagéré: les adresses peuvent être tracées, mais les données réelles sont codées et devraient être presque impossibles à déchiffrer.

Si je souhaite ensuite vérifier mon solde bancaire, je peux soit démarrer un navigateur Web et établir une connexion HTTPS sécurisée avec le serveur Web de la banque, soit utiliser l'application Google Play Store fournie par la banque. Quoi qu'il en soit, je compte sur le cryptage intégré des données échangées pour garder mon mot de passe et les détails de mes finances privées. Cependant, étant paranoïaque, avant de vérifier l'équilibre, je commence généralement l'autre tunnel que j'ai nommé rpi3-all dont la valeur du paramètre AllowedIPs est 0.0.0.0/0. Cela signifie que tout le trafic entrant et sortant de mon appareil client est envoyé vers mon réseau domestique et de là, il est acheminé vers sa destination finale. Ainsi, mes données financières sortantes sont cryptées deux fois lors de la première étape de leur trajet hors du café et les données entrantes sont également cryptées deux fois sur la dernière étape depuis mon réseau domestique. Peut-être que je devrais aussi porter un casque en métal pour me protéger du réseau infâme 5G en même temps, car les données transitent par toutes sortes de réseaux, ponts, routeurs, etc. sans plus ni moins de cryptage que lorsque je consulte mon solde bancaire depuis mon ordinateur de bureau à la maison. Pourtant je trouve rassurant d'utiliser le tunnel WireGuard « universel » à tout moment lors de l'utilisation d'un point public. Cela n'a pas de conséquence négative même pas de ralentissement perceptible même avec le saut supplémentaire impliqué.

Bien sûr, si vous utilisez un point de connexion public à la recherche de l'anonymat, n'utilisez pas le tunnel WireGuard vers le réseau domestique puisque cela revient à utiliser votre propre compte avec votre FAI. D'autre part, il serait naïf de supposer qu'un point de connexion public offre un véritable anonymat. Le serveur du café sait quelle adresse IP a été attribuée à votre ordinateur et l'adresse MAC de la carte réseau de votre ordinateur et il se peut très bien que cette information soit enregistrée.

L'utilisation du client Windows est tout aussi simple. Démarrez WireGuard en cliquant sur son icône dans la barre d'état du système, puis sélectionnez le tunnel souhaité dans la liste de gauche.

Cliquez sur le bouton Activate (Activer en français ?) et si tout se passe bien, le RPV sera en place.

Comme on pourrait le supposer, le bouton Deactivate ferme un tunnel ouvert.

Puisqu'il n'y a pas d'application graphique pour le client WireGuard dans Linux, l'utilitaire wg-quick est utilisé pour démarrer et arrêter les tunnels vers le réseau local depuis un emplacement distant avec le portable Linux Mint. Parfois, plusieurs serveurs RPV sont activés à la maison à des fins de test, donc je liste souvent tous les fichiers de configuration installés pour me rappeler leur nom exact. Ensuite, démarrer un tunnel est assez facile. Il faut se rappelé de la syntaxe du commandement et se souvenir également de ne pas inclure l'extension .conf quand on spécifie le tunnel.

michel@tosh:~$ sudo ls /etc/wireguard oldpi-all.conf oldpi-split.conf oldpi-all.conf oldpi-split.conf michel@tosh:~$ sudo wg-quick up oldpi-all #] ip link add oldpi-all type wireguard [#] wg setconf oldpi-all /dev/fd/63 [#] ip -4 address add 192.168.99.5/24 dev oldpi-all [#] ip link set mtu 1420 up dev oldpi-all [#] wg set oldpi-all fwmark 51820 [#] ip -4 route add 0.0.0.0/0 dev oldpi-all table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 [#] iptables-restore -n

Fermer le tunnel est tout aussi simple, mais vous devez utiliser le nom du tunnel correct que, encore une fois, j'oublie souvent. Heureusement, wg affiche le nom du tunnel actuellement utilisé.

michel@tosh:~$ sudo wg interface: oldpi-all ... michel@tosh:~$ sudo wg-quick down oldpi-all [#] ip -4 rule delete table 51820 [#] ip -4 rule delete table main suppress_prefixlength 0 [#] ip link delete dev oldpi-all [#] iptables-restore -n

Quelques observations finales toc

Une fois que vous avez tout testé de manière satisfaisante, je suggère qu'il est temps de regarder tous les ports acheminés vers le réseau local par le pare-feu. J'ai pu supprimer tous ceux ajoutés pour le système domotique, pour les caméras IP, etc., et les remplacer par un seul port UDP transmis au service WireGuard. Il y a maintenant un seul petit trou noir dans le pare-feu. Essayez-le et vous pourriez aussi ressentir une chaleureuse sensation de sécurité. J'espère que je ne le regretterai pas à l'avenir.

Une approche prudente serait peut-être justifiée dans certaines circonstances, ce qui signifie qu'il peut être préférable d'attendre que WireGuard soit enfin intégré au système d'exploitation. Cela ne devrait pas prendre trop de temps avant que WireGuard soit incorporé dans l' image du système d'exploitation Raspberry Pi (comme c'est actuellement le cas avec Armbian et Ubuntu) ou facilement installé avec une simple installation avec apt depuis le référentiel stable. Cependant, l'expérience montre que même les versions stables d'une nouvelle version du système d'exploitation peuvent casser les choses, donc si je devais installer WireGuard sur un Raspberry Pi, quel que soit le modèle, je n'effacerais pas une image du système d'exploitation qui fonctionne correctement, mais je m'assurerais d'installer le système d'exploitation Raspberry Pi sur une nouvelle carte SD, en gardant ma carte SD d'origine comme sauvegarde sûre.

Certains peuvent s'interroger sur le débit du RPV. J'ai été surpris que le RPV fonctionne correctement même lors du routage de tout le trafic Internet à travers lui. Cela était vrai lorsque le service RPV fonctionnait sur un Raspberry Pi 1 avec un seul cœur (similaire à un Pi Zero). Il est vrai que mes demandes de bande passante sont généralement relativement faibles lorsque je suis dans un café. Néanmoins, des vidéos YouTube pouvaient être diffusées simultanément sur une tablette et un portable sans dégradation notable. Bien sûr, ceux-ci n'étaient pas en haute définition, mais je ne prévois pas un besoin urgent de visionner des vidéos 4K dans les cafés dans un avenir prévisible.

L'inclusion de WireGuard dans le noyau Linux accélérera son adoption par un nombre toujours croissant d'utilisateurs. À mon avis, c'est une bonne chose, car j'ai trouvé le RPV très fiable et son utilisation étonnamment transparente. Ceci étant dit, j'ai rencontré un problème dans l'utilisation de WireGuard. De nombreux points d'accès publics bloquent l'acheminent des datagrammes UDP vers la plupart des ports et WireGuard n'utilise que ce protocole seulement. Trois chaînes de café avec des points de vente partout en Amérique du Nord et même au-delà n'ont pas encore cette politique, mais il semble que ce soit le cas pour ce qui est d'une grande chaîne d'alimentation rapide américaine bien connue. Je voulais examiner de plus près cette question avant que l'accès physique à ces restaurants soit suspendu en raison des risques de propagation du coronavirus. Ce sera une expérimentation à faire si jamais la situation retourne à la normale.

<-Installing and Configuring WireGuard on a Raspberry Pi