Waypipe via WireGuard
|
Important
|
Traduction d’un article du site PRO CUSTODIBUS Le contenu de cette page est la traduction Française de l’article Waypipe over WireGuard de Justin Ludwig |
Waypipe via WireGuard
La méthode la plus directe de lancer des applications Wayland natives à distance est avec Waypipe. La façon la plus simple de faire ça est par le biais d’une connexion SSH ; vous pouvez cependant utiliser WireGuard, grâce à un outil comme Socat ou Netcat.
Dans ce cas, WireGuard assure la sécurité du transport, tandis que Socat ou Netcat transmettent les flux Waypipe entre l’ordinateur sur lequel s’exécute l’application et celui où elle est affichée. J’appelerez celui qui exécute l’application le “serveur” et celui qui l’affiche le “client”. Notez que cela est contraire à la traditionnelle architecture X Windows, où le client démarre l’application et le serveur affiche, où le client est considéré comme le client et le displayer est le serveur. C’est aussi reflété par Waypipe (et Wayland lui-même), où ce que je désigne de “client” crée un nouveau socket pour écouter, et le serveur se connecte à ce socket existant (le comportement inverse du client-serveur normal).
WireGuard
D’abord, nous configurons simplement WireGuard comme dans l’article WireGuard Configuration Point à Point (consultez-le pour une explication détaillée de chaque paramètre de configuration). L’Endpoint A de cet article sera notre client (l’ordinateur qui affiche l’application Wayland), et Endpoint B de cet article sera notre serveur (l’ordinateur qui exécute l’application Wayland).
Sur le client, nous utilisons la suivante configuration WireGuard :
# /etc/wireguard/wg0.conf
# paramètres locaux pour Endpoint A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821
# paramètres distants pour le point d'accès B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 10.0.0.2/32
Sur le serveur, nous utiliserons la configuration suivante de WireGuard :
# /etc/wireguard/wg0.conf
# paramètres locaux pour le point d'accès B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822
# paramètres distants pour le point d'accès A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
Étant donné que la configuration de WireGuard sur le serveur utilise 10.0.0.2 comme adresse IP pour son interface wg0, c’est cette adresse que nous utiliserons plus tard pour vous connecter au serveur Waypipe à partir du client Waypipe. Cette adresse IP privée est accessible uniquement via le tunnel de WireGuard depuis le point d’accès A dans notre exemple.
Wayland
Sur le client, démarrez un composant Wayland (comme GNOME Shell ou votre gestionnaire de fenêtres préféré avec le support de Wayland).
À la fois sur le client et le serveur, installez Waypipe (son nom de paquet sera généralement waypipe sur la plupart des distributions Linux).
Sur le serveur, installez l’application Wayland (vous n’avez pas besoin d’exécuter un composant Wayland ou un gestionnaire de fenêtres sur le serveur). Dans cet exemple, nous utiliserons le programme weston-flower du projet Weston. Vous pouvez l’installer via le paquet weston-demo la plupart des distributions (ou si la distribution n’a pas un paquet weston-demo, il est probablement inclus dans le paquet principal weston). Ce programme exemple affiche une fenêtre avec un rendu simple d’une “flore” et change la fleur chaque fois que votre curseur de souris entre ou quitte la fenêtre.
Socat
Le client et le serveur Waypipe communiquent via un socket de domaine UNIX (crée par le client). Ainsi, sauf s’ils exécutent sur la même machine, vous devez exécuter un autre programme sur le client et le serveur pour acheminer le socket UNIX à travers un socket réseau reliant les machines cliente et serveur. C’est exactement ce que Socat est conçu pour faire.
Figure 1. Waypipe tunneled through Socat and WireGuard
Sur le client et le serveur, installez Socat (le nom du paquet sera simplement socat sur la plupart des distributions).
Sur le serveur, exécutez la commande suivante pour démarrer Socat (en utilisant l’option -dd pour un journalisation de débogage de base) :
$ socat -dd UNIX-LISTEN:$HOME/.cache/flower.sock TCP-LISTEN:5999,bind=10.0.0.2
2023/10/07 12:52:56 socat[1150492] N listening on AF=1 "/home/guiuser/.cache/flower.sock"
Cela démarrera Socat qui écoutera sur un socket UNIX à $HOME/.cache/flower.sock, et un socket TCP à 10.0.0.2:5999. Il dirigea l’entrée standard vers l’entrée standard, et chaque sortie sera redirigée vers la sortie de l’autre côté. Le socket TCP écoutera sur l’adresse IP privée WireGuard du serveur 10.0.0.2, donc seuls les membres du réseau WireGuard (dans ce cas Endpoint A) seront en mesure d’y accéder. Port 5999 est un port arbitraire choisi dans cet exemple (vous pouvez utiliser n’importe quel port que vous souhaitez).
Dans cet exemple, nous utilisons l’identifiant de fichier $HOME/.cache/flower.sock pour identifier le socket UNIX, qui est un chemin de fichier arbitraire (vous pouvez utiliser n’importe quel chemin de fichier que vous souhaitez — assurez-vous simplement que votre utilisateur et seulement votre utilisateur ait accès au répertoire contenant ce fichier).
Ensuite, dans une autre session terminal sur le serveur, exécutez la commande suivante avec le même identifiant de fichier pour démarrer Waypipe :
$ waypipe --socket $HOME/.cache/flower.sock server -- weston-flower
Incluez la commande complète et les arguments de l’application à exécuter après l’indicateur -- ; dans cet exemple, le programme weston-flower, un exemple. Cela démarrera l’application qui sera exécutée et connectée à Waypipe (via une nouvelle socket de sessionWayland gérée automatiquement par Waypipe), et Waypipe commencera à transmettre les commandes et données Wayland via la socket $HOME/.cache/flower.sock. Ces données seront tamponnées (à un certain point) par Socat en attente d’une connexion du client.
Si vous retournez à l’interface terminale Socat sur le serveur, vous devriez voir qu’elle a imprimé quelques lignes supplémentaires de journalisation indiquant que elle a accepté la connexion sur le socket UNIX et est prête à accepter une connexion sur le socket TCP :
2025/10/07 12:53:05 socat[1150492] N accepting connection from AF=1 "<anon>" on AF=1 "/home/guiuser/.cache/flower.sock"
2025/10/07 12:53:05 socat[1150492] N listening on AF=2 10.0.0.2:5999
Maintenant, sur le client, exécutez la commande suivante pour démarrer Waypipe (et notez sur le serveur, nous devons d’abord démarrer Socat, puis Waypipe ; mais sur le client, nous devons démarrer Waypipe en premier) :
$ waypipe --socket $HOME/.cache/flower.sock client
Cela lancera Waypipe à l’écoute sur un socket UNIX avec le descripteur de fichier $HOME/.cache/flower.sock du client. C’est un chemin de fichier arbitraire qui n’a pas besoin de correspondre au chemin du socket sur le serveur — il doit simplement correspondre au chemin de fichier de la commande Socat que nous exécutons ensuite.
Enfin, dans une nouvelle interface terminal sur le client, exécutez la commande suivante pour démarrer Socat et terminer la connexion entre le client et le serveur :
$ socat -dd UNIX-CONNECT:$HOME/.cache/flower.sock TCP-CONNECT:10.0.0.2:5999
2025/10/07 12:53:10 socat[1443349] N opening connection to AF=1 "/home/justin/.cache/flower.sock"
2025/10/07 12:53:10 socat[1443349] N successfully connected from local address AF=1 "\xAEh"
2025/10/07 12:53:10 socat[1443349] N opening connection to AF=2 10.0.0.2:5999
2025/10/07 12:53:10 socat[1443349] N successfully connected from local address AF=2 10.0.0.1:48838
2025/10/07 12:53:10 socat[1443349] N starting data transfer loop with FDs [5,5] and [6,6]
2025/10/07 12:53:10 socat[1443349] N write(5, 0x59731af30000, 44) completed
...
Cette commande va démarrer Socat et le connecter au socket UNIX à l’emplacement $HOME/.cache/flower.sock, qui a été lancé par Waypipe dans l’autre terminal ; et au socket TCP du serveur sur le port 5999. Comme il utilise l’adresse IP privée WireGuard du serveur de 10.0.0.2, toutes les données transférées seront chiffrées et envoyées à travers le tunnel WireGuard que nous avons précédemment établi entre le client et le serveur.
Lorsque Socat sur le client se connecte à Socat sur le serveur, le serveur va commencer à envoyer des commandes et des données Wayland vers l’instance Waypipe sur le client –ce qui devrait entraîner l’ouverture d’une nouvelle fenêtre sur le client et l’affichage du programme weston-flower en cours d’exécution sur le serveur.
Dans le terminal sur le serveur exécutant Socat, vous devriez voir beaucoup plus de sortie de journal, commençant par les lignes suivantes pour montrer qu’il a accepté une connexion sur son propre adresse IP privée WireGuard (10.0.0.2) depuis l’adresse IP privée WireGuard du client (10.0.0.1) :
2025/10/07 12:53:11 socat[1150492] N acceptant connection from AF=2 10.0.0.1:48838 on AF=2 10.0.0.2:5999
2025/10/07 12:53:11 socat[1150492] N starting data transfer loop with FDs [6,6] and [7,7]
2025/10/07 12:53:11 socat[1150492] N write(7, 0x62d0757e4000, 44) completed
...
Vous pouvez arrêter le programme weston-flower en fermant sa fenêtre sur votre client ; ou en arrêtant l’un des autres 5 processus que nous avons démarrés entre le client et le serveur :
- Socat sur le serveur
- Waypipe sur le serveur
- Weston-flower sur le serveur
- Waypipe sur le client
- Socat sur le client
Le seul processus qui survivra à l’arrêt des autres sera #4, Waypipe sur le client –vous devrez donc le fermer explicitement pour le nettoyer.
Voici un script shell générique que vous pouvez utiliser pour démarrer les 3 processus sur le serveur :
#!/bin/sh -eu
# démarre l'écouteur de serveur Waypipe et la application Wayland
# Adresse IP WireGuard du serveur
adresse=10.0.0.2
# Port Waypipe du serveur
port=5999
# Commande pour lancer l'application
cmd=weston-flower
# Crée un répertoire temporaire dans lequel créer la socket Waypipe
sock_dir=$(mktemp -d)
sock=$sock_dir/waypipe.sock
# Nettoie le répertoire temporaire de la socket et les tâches en arrière-plan à l'exit
trap "exit" INT TERM
trap "rm -rf $sock_dir; kill 0" EXIT
# Lance l'écouteur du serveur en tant que tâche en arrière-plan
socat UNIX-LISTEN:$sock TCP-LISTEN:$port,bind=$address &
sleep 0.1
# Lance l'application Wayland
waypipe --socket $sock server -- $cmd
Et un script shell générique que vous pouvez utiliser pour démarrer les deux autres processus sur le client :
```bash
#!/bin/sh -eu
# Démarre le client Waypipe et se connecte à une application Wayland distante
# Adresse IP WireGuard du serveur
adresse=10.0.0.2
# Port Waypipe du serveur
port=5999
# Crée un répertoire temporaire dans lequel créer la socket Waypipe
sock_dir=$(mktemp -d)
sock=$sock_dir/waypipe.sock
# Nettoie le répertoire temporaire de la socket et les tâches en arrière-plan à l'exit
trap "exit" INT TERM
trap "rm -rf $sock_dir; kill 0" EXIT
# Démarre le client Waypipe en tant que tâche en arrière-plan
waypipe --socket $sock client &
sleep 0.1
# Se connecte à l'application Wayland
socat UNIX-CONNECT:$sock TCP-CONNECT:$adresse:$port
Netcat
Si Socat n’est pas installé sur le client ou sur le serveur, vous pouvez faire doxa avec Netcat. Vous aurez besoin d’une version de Netcat qui prend en charge l’option -U (pour les sockets UNIX) ; généralement ce est la valeur par défaut lorsque vous installez le paquet de netcat d’une distribution Linux (mais sur certaines distributions, vous pourriez avoir besoin d’installer un autre paquet comme le netcat-openbsd).
Bien que Socat vous permette de connecter deux sockets bidirectionnellement, Netcat ne vous permet qu’une connexion unidirectionnelle : le flux d’entrée standard de Netcat est envoyé au socket, et la sortie du socket est redirigée dans le flux de sortie standard de Netcat. Ainsi, pour approximer la fonctionnalité de Socat, nous avons besoin de deux instances distinctes de Netcat, chaque une connectée à un socket différent, et d’utiliser une file nommée (aussi appelée FIFO) pour le trafic de retour entre eux.
Avec ce truc, nous pouvons remplacer notre FIFO et nos deux instances de Netcat par la seule instance de Socat sur le client et le serveur, et afficher le programme weston-flower sur le client avec un ensemble similaire d’étapes que celui que nous utilisions avec Socat.
Figure 2. Waypipe tunneled through Netcat and WireGuard
D’abord, sur le serveur, exécutez les commandes suivantes pour créer la file nommée et les deux instances de Netcat (optionnellement en incluant l’option -v de Netcat pour un journal de débogage de base) :
$ mkfifo $HOME/.cache/flower.fifo
$ nc -lv 10.0.0.2 5999 < $HOME/.cache/flower.fifo |
nc -lUv $HOME/.cache/flower.sock > $HOME/.cache/flower.fifo
Bound on home/guiuser/.cache/flower.sock
Listening on home/guiuser/.cache/flower.sock
Listening on 10.0.0.2 5999
Cela configure la file nommée sur le serveur avec un descripteur de fichier $HOME/.cache/flower.fifo (comme le chemin du socket, un chemin arbitrari que j’ai choisi pour cet exemple), et la redirige vers la première instance de Netcat, qui écoute le port TCP 5999 de l’adresse IP privée WireGuard du serveur (10.0.0.2). La sortie de la première instance de Netcat est transférée directement à la deuxième instance de Netcat, qui écoute le socket UNIX avec un descripteur de fichier $HOME/.cache/flower.sock ; et la deuxième instance de Netcat redirige sa propre sortie vers la file nommée.
Ensuite, dans un Terminal différent sur le serveur, exécutez la commande suivante avec le même socket UNIX pour démarrer Waypipe (la même commande exacte que celle que nous utilisions avec Socat) :
$ waypipe --socket $HOME/.cache/flower.sock server -- weston-flower
Si vous revenez au terminal Netcat sur le serveur, vous devriez voir qu’il a imprimé une nouvelle ligne de journalisation, montrant qu’il a accepté la connexion au socket UNIX :
Connection received on /home/guiuser/.cache/flower.sock
Maintenant, sur le client, exécutez la commande suivante pour démarrer Waypipe (avec le même exactement que nous avons utilisé avec Socat) :
$ waypipe --socket $HOME/.cache/flower.sock client
Enfin, dans un autre terminal sur le client, exécutez les commandes suivantes pour créer la pipe nommée et les deux Netcats sur le client afin de compléter sa connexion au serveur :
$ mkfifo $HOME/.cache/flower.fifo
$ nc -v 10.0.0.2 5999 < $HOME/.cache/flower.fifo |
nc -Uv $HOME/.cache/flower.sock > $HOME/.cache/flower.fifo
Connection to 10.0.0.2 5999 port [tcp/*] succeeded!
Cela connectera le premier Netcat au écouteur TCP sur le serveur et le deuxième Netcat au socket créé par le client Waypipe. Le premier Netcat ferra passer sa sortie directement au second, et le second renviera sa sortie via la pipe nommée.
Quand le premier Netcat du client se connecte au premier Netcat du serveur, le serveur commencerait à envoyer des commandes de Wayland et des données par cette connexion qui seront transférées vers l’autre instance Netcat sur le client, jusqu’au Waypipe client - ce qui doit entraîner une nouvelle fenêtre s’ouvrant sur le client et montrant le programme weston-flower.
Dans le terminal du serveur exécutant les deux Netcats, vous devriez voir une autre ligne de journalisation en sortie, indiquant qu’il a accepté la connexion de l’adresse IP privée WireGuard du client (10.0.0.1) :
Connection received on 10.0.0.1 38176
Comme avec Socat, vous pouvez arrêter le programme weston-flower en fermant sa fenêtre sur votre client ; ou bien en arrêtant l’un de nos autres processus lancés à la fois sur le client et le serveur. Comme pour notre exemple Socat, seul le processus qui survivra à l’arrêt des autres sera Waypipe sur le client (il faudra donc le fermer explicitement pour la proprement).
Cependant, contrairement à Socat, Netcat ne va pas nettoyer le fichier de socket UNIX qu’il crée sur le serveur – vous devrez donc le supprimer manuellement (par exemple rm $HOME/.cache/flower.sock) après l’arrêt des Netcats. Vous devrez également supprimer manuellement les tubes nommés sur le client et le serveur (par exemple rm $HOME/.cache/flower.fifo) ; bien que contrairement au fichier de socket, les fichiers FIFO peuvent être réutilisés ultérieurement par d’autres processus si vous decidez de les conserver.
Systemd
Pour un usage plus pratique, vous pouvez configurer une série de services systemd sur le serveur pour écouter un port TCP fixe et démarrer Waypipe et l’application Wayland à la demande, toutes les fois qu’un client tente de se connecter. Cela nécessite 3 fichiers unités :
- Un fichier de socket pour l’écouteur TCP (par exemple
flower-listener.socket) - Un fichier de service pour Socat (par exemple
flower-listener.service) - Un fichier de service pour Waypipe et l’application (par exemple
flower.service)
Figure 3. Waypipe tunnelé via Socat avec Systemd et WireGuard
Pour le programme d’exemple weston-flower, nous créermos un fichier de socket unit comme le fichier /etc/systemd/system/flower-listener.socket :
# /etc/systemd/system/flower-listener.socket
[Unit]
Description=socket for flower-listener service
[Socket]
ListenStream=5999
BindToDevice=wg0
[Install]
WantedBy=sockets.target
Lorsque cette unité est démarrée, systemd créera un écouteur TCP sur le port 5999, écoutant uniquement sur l’interface réseau WireGuard wg0 du serveur. Lorsqu’un client tente de se connecter au port 5999, systemd s’attend à ce qu’une unité de service avec un nom correspondant (flower-listener.service) existe, et il essaie de la démarrer et de lui passer le socket établi.
Voici ensuite le service unit qui doit être créé via le fichier /etc/systemd/system/flower-listener.service :
# /etc/systemd/system/flower-listener.service
[Unit]
Description=listener for connections to forward to weston-flower
BindsTo=flower.service
Before=flower.service
[Service]
ExecStart=socat ACCEPT-FD:3 UNIX-LISTEN:/run/flower/waypipe.sock
User=guiuser
Group=guiuser
RuntimeDirectory=flower
Lorsque cette unité est démarrée, systemd créera un nouveau répertoire /run/flower pour le service (selon la directive RuntimeDirectory=flower), avec l’utilisateur et le groupe du répertoire définis sur guiuser ; puis il lancera Socat en tant qu’utilisateur guiuser, passant à Socat le socket provenant de l’unité socket-listener.socket comme sa file descriptor 3. Nous devons nous assurer que nous créons d’abord cette utilisateur et ce groupe (par exemple : sudo useradd --create-home --shell /bin/bash guiuser) ; cela sera également l’utilisateur sous lequel s’exécute l’application Wayland.
Les directives BindsTo=flower.service et Before=flower.service dans l’unité indiquent à systemd de démarrer le service après avoir réussi à démarrer l’unité flower-listener.service.
Nous devons également créer cette unité de service via le fichier /etc/systemd/system/flower.service :
# /etc/systemd/system/flower.service
[Unit]
Description=waypipe running weston-flower
[Service]
ExecStart=waypipe --socket /run/flower/waypipe.sock server -- weston-flower
Environment=XDG_RUNTIME_DIR=/run/flower
User=guiuser
Group=guiuser
Cette unité exécutera Waypipe avec le programme d’exemple weston-flower, connecté à l’autre bout du socket UNIX /run/flower/waypipe.sock créé par Socat dans le service flower-listener.service. Elle sera lancée en tant que l’utilisateur guiuser, avec sa variable de l’environnement $XDG_RUNTIME_DIR définie sur le même répertoire /run/flower qui a été créé par systemd lors du démarrage du service flower-listener.service (lorsque vous vous connectez en tant qu’utilisateur, $XDG_RUNTIME_DIR est généralement défini sur /run/user/$UID et créé automatiquement en cours de connexion ; cela ne se produit pas lorsque vous exécutez un service systemd, d’où la nécessité de définir explicite $XDG_RUNTIME_DIR à un répertoire dans lequel Waypipe peut créer son propre socket Wayland isolé auquel l’application Wayland se connectera — et /run/flower convient pour ce cas).
Après avoir créé ces trois fichiers d’unité, exécutez les commandes suivantes pour les charger et démarrer le service d’écoute de socket :
$ sudo systemctl daemon-reload
$ sudo systemctl start flower-listener.socket
Cela démarrera l’unité du socket, mais pas les deux unités de service.
| Conseil | Pour configurer le socket pour qu’il démarre l’écoute automatiquement chaque fois que le système redémarre, exécutez également la commande suivante : bash $ sudo systemctl enable flower-listener.socket |
Sur le client, lancez le client Waypipe dans un terminal :
$ waypipe --socket $HOME/.cache/flower.sock client
Et ensuite lancez le client Socat dans un autre terminal :
$ socat UNIX-CONNECT:$HOME/.cache/flower.sock TCP-CONNECT:10.0.0.2:5999
Lorsque le client Socat se connecte au socket défini par l’unité flower-listener.socket sur le serveur, systemd doit automatiquement démarrer l’unité flower-listener.service, suivie de l’unité flower.service. Cette dernière devrait ensuite démarrer le programme weston-flower sur le serveur, le connecter à Waypipe sur le serveur et commencer l’envoi des commandes et données Wayland par le biais du socket TCP tunnelé via WireGuard entre les deux programmes Socat, et à destination du client Waypipe ; le client Waypipe devrait afficher la fenêtre pour le programme weston-flower via son composant Wayland.
Vous pouvez arrêter le programme weston-flower en fermant sa fenêtre sur votre client ; ou en tuant Socat ou Waypipe sur le client ; ou en arrêtant l’une de ses 3 unités sur serveur (mais la meilleure unité à arrêter serait bien sûr flower.service).
Tant que vous ne tuez pas le client Waypipe ou l’unité flower-listener.socket, ils devraient rester en cours d’exécution ; tandis que le processus Socat sur le client s’écrémera et les unités flower-listener.service et flower.service sur le serveur s’arrêteront si vous tuiez l’un de ses processus ou une de ses unités. Ainsi, si vous fermez simplement la fenêtre weston-flower sur le client, vous pouvez redémarrer le programme weston-flower en exécutant à nouveau Socat sur le client :
$ socat UNIX-CONNECT:$HOME/.cache/flower.sock TCP-CONNECT:10.0.0.2:5999
Si vous utilisez l’exemple de script client présenté à la fin de la section Socat ci-dessus, cela permet de démarrer et d’attacher une application Wayland distante sur le serveur tout aussi facilement qu’elle serait en cours d’exécution localement sur le client.
Sécurité
L’élément principal de préoccupation quand on utilise Waypipe est qu’il permet à toute l’application distante à laquelle vous êtes connectée d’accéder libertairement à votre compositeur Wayland local (c’est-à-dire votre gestionnaire de fenêtres), comme s’il s’agissait d’une application locale qui fonctionne sur votre ordinateur local. Ainsi, si le compositeur local permet à toute application de prendre des captures d’écran de votre écran ou de récupérer et de définir le contenu de votre presse-papiers, une application malveillante distante à laquelle vous êtes connecté via Waypipe peut faire la même chose. De plus, si le compositeur local souffre de bugs liés à la sécurité ou d’autres problèmes liés à la sécurité du fait de la mémoire, une application malveillante peut exploiter ces bugs.
Donc en général, vous devriez pas utiliser Waypipe pour se connecter d’un ordinateur local très fiable à un ordinateur distant moins fiable ; vous devriez utiliser Waypipe uniquement pour se connecter entre des ordinateurs ayant le même niveau de confiance. Lorsque vous avez besoin de vous connecter à un ordinateur distant moins fiable pour exécuter une application GUI, il serait probablement mieux d’utiliser VNC (ou un protocole de bureau distant similaire), car cela ajoute une couche supplémentaire d’indirection entre votre compositeur Wayland local et l’application distante (obligeant un adversaire à naviguer par cette couche supplémentaire pour attaquer les vulnérabilités de votre compositeur).
Il est également à noter que pour sa version 0,10.0, Waypipe a été réécrit en Rust, renforçant ainsi sa résistance aux la plupart des problèmes liés à la sécurité de la mémoire ; cependant, la majorité des distributions Linux ne paient toujours pas une ancienne version basée sur C de celui-ci.
Pare-feu
La façon dont nous avons configuré le écouteur TCP sur le serveur avec Socat (#socat), Netcat (#netcat) et Systemd (#systemd) ci-dessus-en le configurant pour écouter seulement sur l’adresse IP privée WireGuard du serveur-assure que la seule façon de se connecter à distance à l’application est via WireGuard, indépendamment des paramètres de pare-feu.
Cependant, si votre réseau WireGuard permet à plusieurs clients WireGuard de se connecter au serveur exécutant l’application distante, vous pourriez souhaiter configurer le pare-feu du serveur afin d’appliquer un contrôle d’accès granulaire et d’autoriser uniquement certains clients WireGuard à se connecter à l’application.
Par exemple, si le serveur avait la configuration suivante de WireGuard, avec plusieurs clients WireGuard pouvant se connecter à celui-ci :
# /etc/wireguard/wg0.conf
# paramètres locaux pour le serveur distant
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822
# paramètres distants pour l'ordinateur portable de Justin
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
# paramètres distants pour le serveur de messagerie
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
AllowedIPs = 10.0.0.3/32
# paramètres distants pour le serveur web
[Peer]
PublicKey = MMsBeTT9v/7XNWB8a/jSMn9O8olPVNduUwvUPJ6eB14=
AllowedIPs = 10.0.0.4/32
# paramètres distants pour l'ordinateur de Justin
[Peer]
PublicKey = kAYKIv6gpBDqueaVNOsY8ddKmIC2dnnXJQ0iKzWxfBI=
AllowedIPs = 10.0.0.5/32
Et que je voulais uniquement mon ordinateur portable et mon bureau accéder à l’application Wayland exposée via le port TCP 5999, je pourrais configurer le jeu de règles nftables suivant sur le serveur :
#!/usr/sbin/nft -f
flush ruleset
define pub_iface = "eth0"
define wg_port = 51822
define justins_laptop = 10.0.0.1
define justins_desktop = 10.0.0.5
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# accepter tous les paquets de boucle locale
iif "lo" accept
# accepter tous les paquets ICMP/ICMPv6
meta l4proto { icmp, ipv6-icmp } accept
# accepter tous les paquets qui font partie d'une connexion déjà établie
ct state vmap { invalid : drop, established : accept, related : accept }
# rejeter les nouvelles connexions au-delà de la limite de taux
ct state new limit rate over 1/second burst 10 packets drop
# accept all DHCPv6 packets received at a link-local address
ip6 daddr fe80::/64 udp dport dhcpv6-client accept
# accept all SSH packets received on a public interface
iifname $pub_iface tcp dport ssh accept
# accept all WireGuard packets received on a public interface
iifname $pub_iface udp dport $wg_port accept
# accept Waypipe connections from specific WireGuard clients
ip saddr { $justins_laptop, $justins_desktop } tcp dport 5999 accept
# reject with polite "port unreachable" icmp response
reject
}
chain forward {
type filter hook forward priority 0; policy drop;
reject with icmpx type host-unreachable
}
}
Ce jeu de règles commence par la configuration de base de nftables à partir de l’article Utiliser WireGuard avec Nftables et ajoute le suivant règle à sa chaîne input pour exposer uniquement le port TCP 5999 aux machines de mon ordinateur portable et bureau (en utilisant les définitions de variables define justins_laptop = 10.0.0.1 et define justins_desktop = 10.0.0.5 à la tête du jeu de règles).
# accept Waypipe connections from specific WireGuard clients
ip saddr { $justins_laptop, $justins_desktop } tcp dport 5999 accept
Cela bloquera tous les clients WireGuard sauf les deux que je lui ai explícitaement autorisés à se connecter à l’application Wayland.
10/7/2025
par Justin Ludwig