WireGuard en mode noyau peut fonctionner parfaitement dans des conteneurs Podman sans root. Cet article vous explique comment, avec dix exemples d’exécution de Podman sans root (plus trois qui doivent être exécutés en tant que root) :

sommaire des 10 solutions

1. Comme un HUB
2. Utiliser pour le masquage de site (Site Masquerading)
3. Utiliser pour la redirection de port du site (port forwarding)
4. Utiliser pour la redirection de port entrant (Inbound Port Forwarding)
5. Utiliser pour la redirection de port sortant (Outbound Port Forwarding)
6. Utiliser pour le réseau hôte (rootfull)
7. Utiliser pour le réseau hôte avec la route par défaut (rootfull)
8. Utilisation pour le réseau de conteneurs
9. Utiliser pour le réseau de pont
10. Utiliser pour un réseau de pont sans masquage
11. Utiliser pour un réseau pont avec WireGuard sur l’hôte (rootfull)
12. Utiliser pour le réseau Pod
13. Utiliser pour la redirection de port depuis Internet

Différences avec Docker

Mais d’abord, passons en revue quelques différences importantes entre l’exécution de WireGuard dans un conteneur Docker « rootfull » et un conteneur Podman « rootless » :

1. Chargement du module du noyau
2. Modifications du pare-feu
3. Option de montage de volume
4. Registres de recherche non qualifiés
5. Mode réseau avec Podman Compose
6. Liste des paramètres noyau avec Podman Compose
7. Transfert des paramètres du noyau

Chargement du module du noyau

Comme avec Docker, le module noyau WireGuard doit être installé sur l’hôte Podman. Tous les noyaux Linux depuis la version 5.6 intègrent le module WireGuard ; vous n’avez donc rien à installer, sauf si vous utilisez un noyau Linux antérieur à la version 5.6 sur l’hôte. Si vous utilisez un noyau plus ancien, vous pourrez peut-être installer le module noyau WireGuard depuis le gestionnaire de paquets de votre distribution ; mais le plus souvent, vous devrez compiler le module noyau WireGuard depuis les sources.

Contrairement à Docker, avec Podman, vous devez charger le module noyau WireGuard en dehors de Podman . Le chargement des modules noyau nécessite un accès root ; lorsque vous exécutez WireGuard en tant que root sur l’hôte, le module noyau est chargé automatiquement. En revanche, si vous exécutez WireGuard dans un conteneur Podman, si le module n’a pas déjà été chargé, WireGuard ne démarrera pas (généralement avec un Protocol not supportedmessage d’erreur).

Vous pouvez vérifier quels modules du noyau ont été chargés en exécutant la lsmodcommande sur l’hôte. Si le module WireGuard a été chargé, le résultat ressemblera à ceci :

$ lsmod | grep wireguard
wireguard              94208  0
libblake2s             16384  1 wireguard
ip6_udp_tunnel         16384  1 wireguard
udp_tunnel             28672  1 wireguard
libcurve25519_generic  40960  1 wireguard

Si le module WireGuard n’a pas encore été chargé, il ne sera pas répertorié. Dans ce cas, vous pouvez utiliser la modprobecommande suivante pour le charger :

$ lsmod | grep wireguard
$ sudo modprobe wireguard
$ lsmod | grep wireguard
wireguard              94208  0
...

Les modules du noyau ne doivent être chargés qu’une seule fois après chaque démarrage ; vous pouvez donc les exécuter modprobemanuellement à chaque démarrage de l’hôte Podman. Cependant, sur les hôtes avec systemd , vous pouvez lister les modules à charger dans un fichier du /etc/modules-load.d/répertoire de l’hôte (vous pouvez nommer ce fichier comme vous le souhaitez ; nous l’utiliserons wireguard.confpour notre exemple) :

$ echo wireguard | sudo tee /etc/modules-load.d/wireguard.conf
$ sudo systemctl restart systemd-modules-load

Sur les hôtes sans systemd, le fichier /etc/modules sert généralement le même objectif que le répertoire /etc/modules-load.d/.

De plus, si vous exécutez iptables dans un conteneur Podman, comme nous le ferons dans plusieurs des exemples suivants, vous devrez charger plusieurs modules noyau iptables de la même manière. Le fichier /etc/modules-load.d/wireguard.conf suivant garantit que le module noyau WireGuard et tous les modules iptables utilisés dans les différents exemples de cet article (à l’exception de ceux qui utilisent la route par défaut) sont chargés au démarrage :

# /etc/modules-load.d/wireguard.conf
# Module WireGuard
wireguard
# modules iptables pour DNAT/SNAT de base et masquage
iptable_nat
xt_MASQUERADE
xt_nat

Pour les exemples qui prennent en charge la route par défaut (c’est-à-dire use AllowedIPs = 0.0.0.0/0), le script WireGuard exécute plusieurs commandes iptables en arrière-plan, ce qui nécessite le chargement de plusieurs modules iptables différents. Le /etc/modules-load.d/wireguard.conffichier suivant garantit que vous disposez de tous les modules iptables nécessaires pour prendre en charge la route par défaut :

# /etc/modules-load.d/wireguard.conf
# Module WireGuard
wireguard
# modules iptables pour la route par défaut de wg-quick
iptable_mangle
iptable_raw
xt_addrtype
xt_comment
xt_connmark
xt_mark

# /etc/modules-load.d/wireguard.conf
# Module WireGuard
wireguard
# modules iptables/nftables pour DNAT/SNAT de base et masquage
nft_chain_nat
nft_compat
xt_nat
# modules nftables pour la route par défaut de wg-quick
nft_ct
nft_fib_inet

Après avoir modifié ce fichier, exécutez la commande sudo systemctl restart systemd-modules-load pour vérifier que tous les modules inclus sont chargés. Si cette commande génère un message d’erreur, exécutez-la commande journalctl -u systemd-modules-load pour vérifier quels modules n’ont pas pu être chargés.

$ find /lib/modules/$(uname -r)/kernel -iname '*masq*'
/lib/modules/4.18.0-305.3.1.el8_4.aarch64/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko.xz
/lib/modules/4.18.0-305.3.1.el8_4.aarch64/kernel/net/ipv6/netfilter/ip6t_MASQUERADE.ko.xz
/lib/modules/4.18.0-305.3.1.el8_4.aarch64/kernel/net/netfilter/nft_masq.ko.xz

Modifications du pare-feu

Une autre différence entre Podman (rootless) et Docker (avec racine) est que lorsque Docker exécute un conteneur, il configure automatiquement les règles iptables nécessaires au réseau du conteneur.

Cependant, la modification du pare-feu nécessite un accès root ; Podman sans root ne le fait donc pas. Si vous utilisez un pare-feu sur l’hôte qui bloque les connexions entrantes par défaut (comme vous le devriez) et que vous devez initier des connexions WireGuard depuis un hôte distant, vous devrez ouvrir manuellement le port d’écoute WireGuard pour le conteneur Podman.

Par exemple, si vous utilisez firewalld pour gérer votre pare-feu et que la zone public de firewalld protège l’interface réseau à partir de laquelle les connexions WireGuard distantes seront établies (par exemple eth0), et que votre conteneur Podman utilise un port d’écoute WireGuard de 51820, vous devrez exécuter la commande suivante pour autoriser l’accès à ce port WireGuard :

$ sudo firewall-cmd --zone=public --add-port=51820/udp
success

Options de montage du volume

Lors de l’exécution de Podman sur un système avec SELinux activé (valeur par défaut pour Fedora , RHEL et nombre de leurs dérivés), certains volumes hôtes montés sur un conteneur Podman devront être réétiquetés avec une étiquette SELinux permettant au conteneur d’y accéder. (Ceci est également vrai avec Docker, mais vous risquez davantage de rencontrer ce problème avec Podman, car ce dernier est souvent utilisé à la place de Docker par les distributions qui activent SELinux par défaut.)

Tous les exemples de cet article utiliseront l’option Z lors du montage du répertoire de configuration WireGuard de l’hôte dans le conteneur, qui indique à Podman de réétiqueter automatiquement le volume avec une étiquette privée et non partagée qui permet au conteneur de lire et d’écrire sur le volume sous SELinux :

podman run \
    ...
    --volume /srv/wg-hub/conf:/etc/wireguard​ :Z \
    docker.io/procustodibus/wireguard

Registres de recherche non qualifiés

Docker utilise automatiquement le registre docker.io par défaut lors de la recherche d’images de conteneurs ; Podman n’a pas de registre par défaut. Si vous essayez d’exécuter une image avec un nom non qualifié avec Podman, vous obtiendrez une erreur similaire à celle-ci :

Error: short-name "procustodibus/wireguard" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

Pour résoudre ce problème, vous pouvez soit ajouter docker.io à la liste unqualified-search-registries dans votre fichier /etc/containers/registry.conf :

# /etc/containers/registries.conf
unqualified-search-registries = ["docker.io"]

Ou vous pouvez simplement qualifier le nom de l’image lors de l’exécution d’un conteneur, comme nous le ferons dans tous les exemples de cet article :

podman run \
    ...
    docker.io/ ​procustodibus/wireguard

Mode réseau avec Podman Compose

Avant la version 1.0.4, Podman Compose ignorait principalement les directives network_mode et network dans les fichiers docker-compose.yml; aucun des exemples docker-compose.yml de cet article qui utilisent l’une ou l’autre directive ne fonctionnera correctement avec Podman Compose avant la version 1.0.4.

Malheureusement, à la mi-octobre 2022, la version 1.0.4 de Podman Compose n’était pas encore officiellement disponible. Pour accéder à ses correctifs, vous devez exécuter la version de développement. Vous pouvez l’installer avec la commande suivante :

$ pip3 install https://github.com/containers/podman-compose/archive/devel.tar.gz

Installez-le en tant que root (par exemple avec sudo) pour le rendre accessible à tous les utilisateurs de votre système (au lieu de votre propre utilisateur uniquement). Si vous n’avez pas pip sur votre système, vous pouvez généralement l’installer avec le paquet python3-pip via le gestionnaire de paquets de votre distribution (puis exécuter pip3 install --upgrade pi setuptools pour mettre à jour de pip vers sa dernière version).

Liste des paramètres noyau avec Podman Compose

Une autre particularité de Podman Compose est qu’il ne prend pas en charge l’utilisation de la directive sysctls avec une table de paramètres, mais avec une liste clé=valeur. Par conséquent, l’utilisation suivante de la directive sysctls dans un fichier docker-compose.yml ne fonctionnera pas :

sysctls:
  net.ipv4.conf.all.forwarding: 1

Mais cette utilisation de la directive sysctls avec Podman Compose fonctionnera :

sysctls:
- net.ipv4.conf.all.forwarding=1

Transfert des paramètres du noyau

Enfin, une dernière différence significative entre Podman rootless et rootfull Docker réside dans le fait que Docker active automatiquement le paramètre du noyau de l’hôte net.ipv4.ip_forward (aka net.ipv4.conf.all.forwarding) à chaque démarrage d’un conteneur (sauf si ce conteneur est exécuté sans accès réseau). Podman rootless ne le fait pas. Par conséquent, si vous souhaitez que WireGuard transfère des paquets et que vous n’avez pas encore activé ce paramètre à l’échelle du système, vous devez l’activer explicitement pour le conteneur WireGuard.

Vous pouvez le faire via le flag --sysctl net.ipv4.conf.all.forwarding=1 avec podman run, ou via la directive sysctls ci-dessus dans un fichier docker-compose.yml. Tous les exemples de cet article nécessitant ce paramètre incluront l’indicateur ou la directive ci-dessus.

Exemples de scénarios

Maintenant que nous avons couvert les principales différences entre Podman et Docker lors de son utilisation pour exécuter un conteneur WireGuard, examinons quelques exemples concrets d’exécution de WireGuard dans un conteneur Podman :

Utiliser comme un Hub

Le premier exemple que nous allons examiner concerne l’exécution du hub d’une topologie en étoile WireGuard dans un conteneur Podman. Nous utiliserons pour ce hub la même configuration WireGuard que celle de l’« hôte C » du guide de configuration WireGuard en étoile , à la seule exception que nous ne définirons pas le paramètre noyau « IP forwarding » dans la configuration WireGuard (nous le définirons plutôt dans la configuration Podman).

Enregistrez la configuration WireGuard pour le hub dans son propre répertoire, à un endroit pratique sur l’hôte, comme dans le /srv/wg-hub/conf/répertoire :

# /srv/wg-hub/conf/wg0.conf

#  paramètres locaux pour l'hôte C
[Interface]
PrivateKey = CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCGA=
Address = 10.0.0.3/32
ListenPort = 51823

# paramètres distants pour le point de terminaison A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

# paramètres distants pour le point de terminaison B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.2/32

Vous pouvez ensuite exécuter un conteneur pour le hub avec la podman runcommande suivante :

podman run \
    --cap-add NET_ADMIN \
    --name wg-hub \
    --publish 51823:51823/udp \
    --rm \
    --sysctl net.ipv4.conf.all.forwarding=1 \
    --volume /srv/wg-hub/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

Voici ce que font les arguments de commande :

1. --cap-add NET_ADMIN: Accorde au conteneur la NET_ADMINcapacité — cela est nécessaire pour démarrer une interface WireGuard à l’intérieur du conteneur.
2. --name wg-hub: Définit le nom du conteneur sur wg-hub(vous pouvez le définir sur le nom que vous souhaitez, ou l’omettre complètement si vous ne vous souciez pas de la façon dont il est nommé).
3. --publish 51823:51823/udp Transfère le port 51823 public de l’hôte vers celui du conteneur . 51823 Assurez-vous que ce dernier correspond au ListenPortparamètre du fichier de configuration WireGuard (le premier peut être le port que vous souhaitez rendre public). Assurez-vous également d’ouvrir séparément l’accès au port public de l’hôte via votre pare-feu si vous souhaitez que les hôtes distants puissent établir des connexions WireGuard vers ce conteneur.
4. --rm: Supprime le conteneur lorsqu’il est arrêté (vous pouvez omettre cette option si vous ne souhaitez pas supprimer le conteneur).
5. --sysctl net.ipv4.conf.all.forwarding=1: Active la transmission de paquets dans le conteneur.
6. --volume /srv/wg-hub/conf:/etc/wireguard:Z: Mappe le /srv/wg-hub/conf/répertoire de l’hôte vers /etc/wireguard/celui du conteneur (vous pouvez modifier le répertoire de l’hôte comme vous le souhaitez). Cette Zoption permet au conteneur d’accéder à ce répertoire même lorsque SELinux est activé.
7. docker.io/procustodibus/wireguard: Exécute la dernière version de l’ image WireGuard .

Alternativement, vous pouvez placer le fichier suivant docker-compose.yml dans le répertoire au-dessus du fichier de configuration WireGuard :

# /srv/wg-hub/docker-compose.yml
version: '3'
services:
  wireguard:
    image: docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    ports:
    - 51823:51823/udp
    sysctls:
    - net.ipv4.conf.all.forwarding=1
    volumes:
    - ./conf:/etc/wireguard:Z

Ensuite, démarrez un conteneur pour le hub en l’exécutant podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

La configuration Podman pour cet exemple est très similaire à l’ exemple d’utilisation rootfull de Docker pour un Hub de l’article original sur les conteneurs WireGuard , avec les différences suivantes pour Podman :

1. Nous avons explicitement activé le paramètre du noyau de transfert de paquets.
2. Nous avons ajouté l’option Z au volume de configuration WireGuard.
3. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour le masquage de site (Site Masquerading)

Voyons maintenant comment utiliser un conteneur Podman pour assurer la connectivité au réseau local (LAN) de l’hôte Podman depuis d’autres points de terminaison WireGuard distants, dans une topologie point à site (avec masquage). Nous utiliserons la même configuration WireGuard pour le conteneur que « Hôte β » du guide de configuration point à site WireGuard , à deux exceptions près :

1. Nous ne définirons pas le paramètre du noyau « IP forwarding » dans la configuration WireGuard (nous le définirons plutôt dans la configuration Podman).
2. Nous pouvons simplifier les règles iptables du conteneur en une seule ligne (pour masquer tous les paquets transférés à l’exception de ceux envoyés via son interface WireGuard).

   Important

   Pour exécuter cet exemple, assurez-vous de charger le module du noyau WireGuard sur l’hôte Podman et d’ouvrir l’accès au port UDP de l’hôte 51822, comme décrit dans les sections Chargement du module du noyau et Modifications du pare-feu au début de cet article.

   Enregistrez la configuration WireGuard pour l’hôte β dans son propre répertoire, à un endroit pratique sur l’hôte, comme dans le répertoire /srv/wg-p2s/conf/ :

# /srv/wg-p2s/conf/wg0.conf

# local settings for Host β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# IP masquerading
PreUp = iptables -t nat -A POSTROUTING ! -o %i -j MASQUERADE

# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Vous pouvez exécuter un conteneur pour cette interface WireGuard avec la podman runcommande suivante :

podman run \
    --cap-add NET_ADMIN \
    --cap-add NET_RAW \
    --publish 51822:51822/udp \
    --name wg-p2s \
    --rm \
    --sysctl net.ipv4.conf.all.forwarding=1 \
    --volume /srv/wg-p2s/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

Alternativement, vous pouvez placer le fichier suivant docker-compose.yml dans le répertoire au-dessus du fichier de configuration WireGuard :

# /srv/wg-p2s/docker-compose.yml
version: '3'
services:
  wireguard:
    image: docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    - NET_RAW
    ports:
    - 51822:51822/udp
    sysctls:
    - net.ipv4.conf.all.forwarding=1
    volumes:
    - ./conf:/etc/wireguard:Z

Et puis démarrez le conteneur en l’exécutant podman-compose up à partir du même répertoire que le fichier docker-compose.yml. La configuration Podman pour cet exemple est très similaire à l’ exemple d’utilisation rootfull de Docker pour le masquage de site de l’article original sur les conteneurs WireGuard , avec les différences suivantes pour Podman :

1. Nous avons accordé la capacité NET_RAW (de faire fonctionner iptables dans un conteneur rootless).
2. Nous avons explicitement activé le paramètre du noyau pour le transfert de paquets.
3. Nous avons ajouté l’option Z au volume de configuration WireGuard.
4. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour la redirection de port du site (Site Port Forwarding)

Vous pouvez également utiliser un conteneur Podman pour assurer la connectivité du réseau local (LAN) de l’hôte Podman vers d’autres points de terminaison WireGuard distants, inversant ainsi la topologie point à site classique en transférant le trafic de services spécifiques du « site » vers le « point ».
Dans ce scénario, nous utiliserons la même configuration WireGuard pour le conteneur que celle de l’« hôte β » du guide WireGuard Point à site avec redirection de port , à la seule exception que nous ne définirons pas le paramètre noyau « redirection IP » dans la configuration WireGuard (nous le définirons plutôt dans la configuration Podman).

# /srv/wg-p2s/conf/wg0.conf

# local settings for Host β
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# IP masquerading
PreUp = iptables -t nat -A POSTROUTING ! -o %i -j MASQUERADE

# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Comme dans ce scénario, nous transférons le port 80 de l’hôte, qui est un port « privilégié » (comme tous les ports en-dessous de 1024), nous aurions normalement besoin d’utiliser l’utilisateur root sur l’hôte pour exécuter un conteneur avec cette configuration WireGuard.
Nous pouvons toutefois l’exécuter en rootless Podman, si nous ajustons cette restriction. Le plus simple est de modifier la définition des ports privilégiés et d’exécuter la commande suivante en tant que root :

$ sudo sysctl -w net.ipv4.ip_unprivileged_port_start=0

podman run \
    --cap-add NET_ADMIN \
    --cap-add NET_RAW \
    --publish 51822:51822/udp \
    --name wg-p2s \
    --rm \
    --sysctl net.ipv4.conf.all.forwarding=1 \
    --volume /srv/wg-p2s/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

Alternativement, vous pouvez placer le fichier suivant docker-compose.yml dans le répertoire au-dessus du fichier de configuration WireGuard :

# /srv/wg-fwd/docker-compose.yml
version: '3'
services:
  wireguard:
    image: docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    - NET_RAW
    network_mode: slirp4netns:port_handler=slirp4netns
    ports:
    - 80:80
    - 51822:51822/udp
    sysctls:
    - net.ipv4.conf.all.forwarding=1
    volumes:
    - ./conf:/etc/wireguard:Z

Et puis démarrez le conteneur en l’exécutant podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

1. Nous avons accordé la capacité NET_RAW (de faire fonctionner iptables dans un conteneur rootless).
2. Nous définissons slirp4netns comme gestionnaire de transfert de port (pour permettre le transfert de port de l’hôte vers une destination en dehors du conteneur).
3. Nous avons explicitement activé le paramètre du noyau de transfert de paquets.
4. Nous avons ajouté l’option Z au volume de configuration WireGuard.
5. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour la redirection de port entrant (Inbound Port Forwarding)

Vous pouvez également utiliser la redirection de port avec un conteneur Podman de manière à faire de l’hôte Podman un proxy public pour un service privé connecté via une topologie point à point WireGuard (ou topologie en étoile ).

Dans cet exemple, nous utiliserons un réseau point à point entre les points de terminaison A et B, similaire à celui présenté dans le guide de configuration WireGuard point à point . Cependant, au lieu d’être un poste de travail d’utilisateur final, le point de terminaison A est en réalité un serveur situé dans un centre de données avec un port TCP exposé publiquement 80. Le point de terminaison B est un serveur web situé dans un autre centre de données, dont seul le port WireGuard UDP 51822 est exposé.

# /srv/wg-ifw/conf/wg0.conf

# local settings for Endpoint A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821

# port forwarding
PreUp = iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2
PreUp = iptables -t nat -A POSTROUTING -p tcp --dport 80 -j MASQUERADE

# remote settings for Endpoint B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 10.0.0.2/32

La première règle iptables ci-dessus transmettra les paquets que le conteneur reçoit sur le port TCP 80vers le point de terminaison B. La deuxième règle iptables masquera ces paquets comme s’ils provenaient du conteneur lui-même, de sorte que le point de terminaison B leur renverra des réponses via le point de terminaison A.

$ sudo sysctl -w net.ipv4.ip_unprivileged_port_start=0

$ sudo firewall-cmd --zone=public --add-port=80/tcp
success

podman run \
    --cap-add NET_ADMIN \
    --cap-add NET_RAW \
    --publish 80:80 \
    --publish 51821:51821/udp \
    --name wg-ifw \
    --network slirp4netns:port_handler=slirp4netns \
    --rm \
    --sysctl net.ipv4.conf.all.forwarding=1 \
    --volume /srv/wg-ifw/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

Alternativement, vous pouvez placer le fichier suivant docker-compose.ymldans le répertoire au-dessus du fichier de configuration WireGuard :

# /srv/wg-ifw/docker-compose.yml
version : « 3 »
services:
  grillage de protection:
    image : docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    - NET_RAW
    ports:
    - 80:80
    - 51821:51821/udp
    network_mode : slirp4netns : port_handler = slirp4netns
    commandes système :
    - net.ipv4.conf.all.forwarding=1
    volumes:
    - ./conf:/etc/wireguard:Z

Et puis démarrez le conteneur en l’exécutant podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

1. Nous avons accordé la capacité NET_RAW (de fonctionner iptables dans un conteneur rootless).
2. Nous définissons slirp4netns comme gestionnaire de transfert de port (pour permettre le transfert de port de l’hôte vers une destination en dehors du conteneur).
3. Nous avons explicitement activé le paramètre du noyau de transfert de paquets.
4. Nous avons ajouté l’option Z au volume de configuration WireGuard.
5. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour la redirection de port sortant (Outbound Port Forwarding)

Vous pouvez également utiliser la redirection de port avec un conteneur Podman de manière à faire de l’hôte Podman un proxy public pour un service privé connecté via une topologie point à point WireGuard (ou topologie en étoile ).

Dans cet exemple, nous utiliserons un réseau point à point entre les points de terminaison A et B, similaire à celui présenté dans le guide de configuration WireGuard point à point . Cependant, au lieu d’être un poste de travail d’utilisateur final, le point de terminaison A est en réalité un serveur situé dans un centre de données avec un port TCP exposé publiquement 80. Le point de terminaison B est un serveur web situé dans un autre centre de données, dont seul le port WireGuard UDP 51822 est exposé.

# /srv/wg-ofw/conf/wg0.conf
# local settings for Endpoint B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# port forwarding
PreUp = iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.0.2.3
PreUp = iptables -t nat -A POSTROUTING -p tcp --dport 80 -j MASQUERADE

# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

La première règle iptables ci-dessus transmet les paquets reçus par le conteneur via le tunnel WireGuard* sur le port TCP 80 vers l’adresse IP du serveur web 192.0.2.3.
La seconde règle iptables masque ces paquets comme s’ils provenaient du conteneur lui-même, de sorte que (conjointement au masquage fourni par l’hôte Podman pour le conteneur) le serveur web externe leur renvoie les réponses via le point de terminaison B (où l’hôte Podman renvoie ces réponses au conteneur, qui les transmet ensuite au point de terminaison A).

podman run \
    --cap-add NET_ADMIN \
    --cap-add NET_RAW \
    --publish 51822:51822/udp \
    --name wg-ofw \
    --rm \
    --sysctl net.ipv4.conf.all.forwarding=1 \
    --volume /srv/wg-ofw/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

Alternativement, vous pouvez placer le fichier suivant docker-compose.yml dans le répertoire au-dessus du fichier de configuration WireGuard :

# /srv/wg-ofw/docker-compose.yml
version: '3'
services:
  wireguard:
    image: docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    - NET_RAW
    ports:
    - 51822:51822/udp
    sysctls:
    - net.ipv4.conf.all.forwarding=1
    volumes:
    - ./conf:/etc/wireguard:Z

Et puis démarrez le conteneur en l’exécutant podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

La configuration Podman pour cet exemple est très similaire à l’exemple d’utilisation rootfull de Docker pour la redirection de port sortant de l’article original sur les conteneurs WireGuard , avec les différences suivantes pour Podman :

1. Nous avons accordé la capacité NET_RAW (de fonctionner iptables dans un conteneur rootless).
2. Nous avons explicitement activé le paramètre du noyau de transfert de paquets.
3. Nous avons ajouté l’option Z au volume de configuration WireGuard.
4. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour le réseau hôte (rootfull)

# /srv/wg-host/conf/wg0.conf

# paramètres locaux pour le point de terminaison A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821

# paramètres à distance pour l'hôte β
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 10.0.0.2/32

La seule différence entre cet exemple et le scénario du guide de configuration WireGuard point à site réside dans le fait que, dans cet exemple, c’est Internet qui est le « site » auquel l’hôte β fournira l’accès, et non pas seulement son propre réseau local. Nous avons donc modifié le AllowedIPsparamètre de configuration WireGuard du point de terminaison A pour qu’il corresponde 0.0.0.0/0à l’intégralité de l’espace d’adressage IPv4.

Ce paramètre AllowedIPs déclenche le script WireGuard utilisé dans le conteneur Podman pour prendre en charge la route par défaut de l’hôte, envoyant tout le trafic non local de l’hôte via le tunnel WireGuard. Cela nécessite également l’activation du paramètre ipv4.conf.all.src_valid_mark du noyau en dehors du conteneur :

$ sudo sysctl -w net.ipv4.conf.all.src_valid_mark=1

sudo podman run \
    --cap-add NET_ADMIN \
    --cap-add NET_RAW \
    --name wg-host-internet \
    --network host \
    --rm \
    --volume /srv/wg-host-internet/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

L’hôte envoie désormais tout son trafic Internet via le tunnel WireGuard. Si vous exécutez la commande suivante sur le point de terminaison A, cela démontrera qu’il utilise désormais l’adresse IP de l’hôte β pour accéder à Internet :

$ curl icanhazip.com
203.0.113.2

Alternativement, vous pouvez exécuter le conteneur WireGuard via la podman-composecommande si vous placez le docker-compose.ymlfichier suivant dans le répertoire au-dessus du fichier de configuration WireGuard :

# /srv/wg-host-internet/docker-compose.yml
version : « 3 »
services:
  grillage de protection:
    image : docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    - NET_RAW
    network_mode : hôte
    volumes:
    - ./conf:/etc/wireguard:Z

Et puis démarrez le conteneur en l’exécutant sudo podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

1. Nous avons ajouté l’option Z au volume de configuration WireGuard.
2. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour le réseau hôte avec la route par défaut

Vous pouvez également utiliser un conteneur Podman pour fournir un accès Internet à l’hôte lui-même via le réseau WireGuard du conteneur.
Cependant, dans ce cas, vous devez également exécuter le conteneur en tant que root afin qu’il puisse configurer l’interface WireGuard dans l’espace de noms du réseau racine de l’hôte.

# /srv/wg-host-internet/conf/wg0.conf

# local settings for Endpoint A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821

# remote settings for Host β
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 0.0.0.0/0

La seule différence entre cet exemple et le scénario du guide de configuration WireGuard point à site réside dans le fait que, dans cet exemple, c’est Internet qui est le « site » auquel l’hôte β fournira l’accès, et non pas seulement son propre réseau local. Nous avons donc modifié le paramètre AllowedIPs de configuration WireGuard du point de terminaison A pour qu’il corresponde 0.0.0.0/0 à l’intégralité de l’espace d’adressage IPv4.

Ce paramètre AllowedIPs déclenche le script WireGuard utilisé dans le conteneur Podman pour prendre en charge la route par défaut de l’hôte, envoyant tout le trafic non local de l’hôte via le tunnel WireGuard.
Cela nécessite également l’activation du paramètre ipv4.conf.all.src_valid_mark du noyau en dehors du conteneur :

$ sudo sysctl -w net.ipv4.conf.all.src_valid_mark=1

sudo podman run \
    --cap-add NET_ADMIN \
    --cap-add NET_RAW \
    --name wg-host-internet \
    --network host \
    --rm \
    --volume /srv/wg-host-internet/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

L’hôte envoie désormais tout son trafic Internet via le tunnel WireGuard. Si vous exécutez la commande suivante sur le point de terminaison A, cela démontrera qu’il utilise désormais l’adresse IP de l’hôte β pour accéder à Internet :

$ curl icanhazip.com
203.0.113.2

Alternativement, vous pouvez exécuter le conteneur WireGuard via la commande podman-compose si vous placez le fichier docker-compose.yml suivant dans le répertoire au-dessus du fichier de configuration WireGuard :

# /srv/wg-host-internet/docker-compose.yml
version: '3'
services:
  wireguard:
    image: docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    - NET_RAW
    network_mode: host
    volumes:
    - ./conf:/etc/wireguard:Z

Et puis démarrez le conteneur en l’exécutant sudo podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

Utilisation pour le réseau de conteneurs

# /srv/wg-point/conf/wg0.conf

# local settings for Endpoint B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Exécutez un conteneur pour cette configuration WireGuard avec la commande podman run suivante :

podman run \
    --cap-add NET_ADMIN \
    --publish 51822:51822/udp \
    --name wg-point \
    --rm \
    --volume /srv/wg-point/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

Et avec ce conteneur en cours d’exécution (auquel nous avons donné le nom arbitraire « wg-point »), utilisez l’indicateur --network container:wg-point pour exécuter chaque conteneur frère avec lequel vous souhaitez partager le réseau WireGuard, comme ceci :

podman run \
    --name example-web-server \
    --network container:wg-point \
    --rm \
    docker.io/nginx

Le conteneur example-web-server ci-dessus démarre un serveur web Nginx générique , en écoute sur le port TCP 80 de l’espace de noms réseau du conteneur WireGuard. Cela vous permet d’accéder au serveur web depuis le réseau WireGuard en utilisant l’adresse IP WireGuard du conteneur (10.0.0.2). Par exemple, nous pouvons y accéder avec cURL depuis le point de terminaison A :

$ curl 10.0.0.2:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

Alternativement, vous pouvez exécuter le conteneur WireGuard avec ses frères et sœurs à l’aide de la commande podman-compose si vous placez le fichier docker-compose.yml suivant dans le répertoire au-dessus du fichier de configuration WireGuard :

# /srv/wg-point/docker-compose.yml
version: '3'
services:
  wg-point:
    image: docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    ports:
    - 51822:51822/udp
    volumes:
    - ./conf:/etc/wireguard:Z
  example-web-server:
    image: docker.io/nginx
    network_mode: 'service:wireguard'

Démarrez ensuite les conteneurs en les exécutant podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

La configuration Podman de cet exemple est similaire à l’ exemple d’utilisation de Docker pour un réseau de conteneurs de l’article original sur les conteneurs WireGuard. Cependant, nous avons inversé les rôles entre les points de terminaison A et B pour correspondre aux exemples d’utilisation pour un réseau de ponts et d’utilisation pour un réseau de pods plus loin dans cet article. Si nous avions conservé les mêmes rôles, les seules différences entre cet exemple Podman et celui de Docker de l’autre article seraient :

1. Nous avons ajouté l’option Z au volume de configuration WireGuard.
2. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour le réseau de pont (Bridge Network)

Nous utiliserons en fait la même configuration WireGuard pour le conteneur Podman dans cet exemple que celle utilisée par « Host β » dans le guide de configuration WireGuard Point to Site — à deux exceptions près :

1. Nous ne définirons pas le paramètre du noyau IP forwarding dans la configuration WireGuard (nous le définirons plutôt dans la configuration Podman).
2. Nous pouvons simplifier les règles iptables du conteneur en une seule ligne (pour masquer tous les paquets transférés à l’exception de ceux envoyés via son interface WireGuard).

# /srv/wg-net-masq/wg-server/wg0.conf

# local settings for Endpoint B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# IP masquerading
PreUp = iptables -t nat -A POSTROUTING ! -o %i -j MASQUERADE

# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Ensuite, créez le réseau de pont à utiliser par les conteneurs en exécutant la commande suivante :

$ podman network create \
    --subnet 192.168.123.0/24 \
    wg-network

Vous pouvez utiliser un sous-réseau différent de 192.168.123.0/24 celui que vous souhaitez, ainsi qu’un nom différent de celui-ci wg-network.
Assurez-vous simplement d’ajuster la configuration des conteneurs en conséquence.

Enfin, démarrez le conteneur WireGuard, ainsi que les autres conteneurs que vous souhaitez exposer via WireGuard.
Pour chaque conteneur, spécifiez le nom du réseau que nous venons de créer et une adresse IP disponible sur le réseau :

$ podman run \
    --cap-add NET_ADMIN \
    --cap-add NET_RAW \
    --name wg-server \
    --network wg-network \
    --ip 192.168.123.123 \
    --publish 51822:51822/udp \
    --rm \
    --sysctl net.ipv4.conf.all.forwarding=1 \
    --volume /srv/wg-net-masq/conf:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

.

$ podman run \
    --name example-web-server \
    --network wg-network \
    --ip 192.168.123.2 \
    --rm \
    docker.io/nginx

L’ordre de démarrage des conteneurs n’a pas d’importance. Si vous avez déjà démarré un conteneur et souhaitez l’exposer via WireGuard, vous pouvez le connecter au réseau pont avec la commande suivante :

$ podman network connect \
    --ip 192.168.123.2 \
    wg-network \
    example-web-server

Sur le point de terminaison A (l’hôte distant), assurez-vous d’inclure le sous-réseau du réseau de pont dans le paramètre AllowedIPs de configuration WireGuard du point de terminaison A :

# /etc/wireguard/wg0.conf

# local settings for Endpoint A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821

# remote settings for Endpoint B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 192.168.123.0/24

Vous pourrez ensuite accéder aux conteneurs du point de terminaison B depuis le point de terminaison A en utilisant leur adresse IP sur le réseau de pont.
Par exemple, nous pouvons accéder au conteneur example-web-server depuis le point de terminaison A en utilisant son adresse réseau de pont 192.168.123.2:

$ curl 192.168.123.2:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

Vous pouvez également utiliser Podman Compose pour configurer le réseau de pont et les conteneurs. Par exemple, en utilisant la syntaxe Docker Compose version 3.5 et ultérieure, vous pouvez créer un élément similaire à wg-network celui ci-dessus et y connecter des éléments similaires à wg-server et des conteneurs example-web-server:

# /srv/wg-net-masq/docker-compose.yml
version: '3.5'

networks:
  wg-network:
    ipam:
      config:
      - subnet: 192.168.123.0/24

services:
  wg-server:
    image: docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    - NET_RAW
    networks:
      wg-network:
        ipv4_address: 192.168.123.123
    ports:
    - 51822:51822/udp
    sysctls:
    - net.ipv4.conf.all.forwarding=1
    volumes:
    - ./conf:/etc/wireguard:Z

  example-web-server:
    image: docker.io/nginx
    networks:
      wg-network:
        ipv4_address: 192.168.123.2

Démarrez le réseau et les conteneurs en les exécutant via podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

1. Nous avons accordé la capacité NET_RAW (de fonctionner iptables dans un conteneur rootless).
2. Nous avons explicitement activé le paramètre du noyau de transfert de paquets.
3. Nous avons ajouté l’option Z au volume de configuration WireGuard.
4. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour un réseau de pont sans masquage (Bridge Network Without Masquerading)

Pour conserver les adresses sources d’origine du trafic, nous devons ajouter manuellement une ou plusieurs routes à l’espace de noms réseau de chaque conteneur vers lequel le conteneur WireGuard transfère le trafic.
Dans le scénario ci-dessus, nous avons attribué au conteneur WireGuard l’adresse IP 192.168.123.123, et sa configuration WireGuard est configurée pour autoriser uniquement les paquets provenant du 10.0.0.1/32 point de terminaison A. Dans ce scénario, nous devons donc ajouter la route suivante au conteneur example-web-server :

ip route add 10.0.0.1/32 via 192.168.123.123

Si la configuration WireGuard du conteneur WireGuard contenait plusieurs blocs d’adresses AllowedIPs, nous devions ajouter une route pour chaque bloc.
Par exemple, si la configuration contenait les éléments suivants :

AllowedIPs = 10.0.0.1/32
AllowedIPs = 10.1.2.3/32, 10.1.2.99/32
AllowedIPs = 192.168.234.0/24

Nous devrions ajouter quatre routes, une pour chaque bloc d’adresses :

ip route add 10.0.0.1/32 via 192.168.123.123
ip route add 10.1.2.3/32 via 192.168.123.123
ip route add 10.1.2.99/32 via 192.168.123.123
ip route add 192.168.234.0/24 via 192.168.123.123

Pour ajouter des routes au conteneur, vous devez exécuter la comande ip route add soit depuis l’hôte, en utilisant l’espace de noms du conteneur, soit depuis le conteneur lui-même.
Pour ajouter des routes depuis l’hôte, utilisez la commande nsenter décrite dans la section « Ajouter la route depuis l’hôte » de l’ article « Accès à distance WireGuard aux conteneurs Docker» .

Pour ajouter des routes à partir d’un conteneur Podman sans racine, vous devez :

1. Installez le iproute2package dans le conteneur (ou, idéalement, l’image du conteneur).
2. Démarrez le conteneur avec la capacité NET_ADMIN.
3. Exécutez la commande ip route add depuis le conteneur.

La manière exacte de procéder dépend de l’image du conteneur, mais cela signifie généralement que vous devez :

1. Créez une image personnalisée avec un Dockerfile personnalisé dans lequel vous installez le package iproute2.
2. Exécutez l’image avec une commande de script personnalisée (et avec l’indicateur --cap-add NET_ADMIN).
3. En tant que première partie du script, exécutez la commande ip route add.
4. En tant que deuxième partie du script, exécutez la commande par défaut à partir de l’image de base d’origine.

Pour notre exemple de serveur Web, nous créerions un Dockerfile personnalisé comme celui-ci (placé dans son propre répertoire quelque part de pratique sur l’hôte, comme le répertoire /srv/wg-net-route/example-web-server/), qui remplace l’image nginx de base pour installer le package iproute2:

# /srv/wg-net-route/example-web-server/Dockerfile
FROM docker.io/nginx
RUN apt-get update && apt-get install -y iproute2

Ensuite, nous créerions un script de commande personnalisé (placé dans /srv/wg-net-route/example-web-server/command.sh) qui exécute d’abord la commande ip route add, puis exécute la commande pour démarrer nginx:

#!/bin/sh -e
# /srv/wg-net-route/example-web-server/command.sh
ip route add 10.0.0.1/32 via 192.168.123.123
nginx -g 'daemon off;'

Et nous construirions l’image personnalisée comme ceci, en lui attribuant une balise de custom-nginx:

podman build \
    --tag custom-nginx \
    /srv/wg-net-route/example-web-server

Ensuite, nous enregistrerons la configuration WireGuard pour le point de terminaison B dans un répertoire différent sur l’hôte (comme /srv/wg-net-route/wg-server/) :

# /srv/wg-net-route/wg-server/wg0.conf

# local settings for Endpoint B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# remote settings for Endpoint A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

La configuration de WireGuard doit être la même que pour l’ exemple d’utilisation pour le réseau de conteneurs ci-dessus, mais sans la règle iptables de masquage.

$ podman network create \
    --subnet 192.168.123.0/24 \
    wg-network

Et démarrez le conteneur WireGuard, en le connectant au réseau du pont :

$ podman run \
    --cap-add NET_ADMIN \
    --name wg-server \
    --network wg-network \
    --ip 192.168.123.123 \
    --publish 51822:51822/udp \
    --rm \
    --sysctl net.ipv4.conf.all.forwarding=1 \
    --volume /srv/wg-net-route/wg-server:/etc/wireguard:Z \
    docker.io/procustodibus/wireguard

Contrairement au scénario d’utilisation pour le réseau de conteneurs , nous n’avons pas besoin d’ajouter la capacité NET_RAW au conteneur WireGuard, car nous n’avons pas besoin d’exécuter de règles iptables à l’intérieur. Enfin, nous pouvons exécuter un conteneur avec l’image nginx personnalisée que nous avons créée ci-dessus, en l’attachant au même réseau de pont :

$ podman run \
    --cap-add NET_ADMIN \
    --name example-web-server \
    --network wg-network \
    --ip 192.168.123.2 \
    --rm \
    --volume /srv/wg-net-route/example-web-server:/custom:Z \
    custom-nginx \
    /custom/command.sh

Comme ce conteneur exécutera la commande ip route add, cette capacité NET_ADMIN doit lui être accordée. Et comme nous le faisons via le script command.sh personnalisé décrit ci-dessus, nous devons également monter ce script dans le répertoire /custom/ du conteneur (ou sur un autre point de montage pratique au sein du conteneur). Avec cet itinéraire ajouté, nous pouvons tester le tunnel WireGuard en essayant d’accéder au conteneur personnalisé par son adresse sur le réseau de pont (192.168.123.2) à partir du point de terminaison A:

$ curl 192.168.123.2:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

Vous pouvez également utiliser Podman Compose pour créer l’image personnalisée et l’exécuter sur un réseau pont avec le conteneur WireGuard.
Par exemple, en utilisant la syntaxe Docker Compose version 3.5 et ultérieure, vous pouvez créer une image similaire wg-network à celle ci-dessus et y connecter wg-server des conteneurs example-web-server similaires :

# /srv/wg-net-route/docker-compose.yml
version: '3.5'

networks:
  wg-network:
    ipam:
      config:
      - subnet: 192.168.123.0/24

services:
  wg-server:
    image: docker.io/procustodibus/wireguard
    cap_add:
    - NET_ADMIN
    networks:
      wg-network:
        ipv4_address: 192.168.123.123
    ports:
    - 51822:51822/udp
    sysctls:
    - net.ipv4.conf.all.forwarding=1
    volumes:
    - ./wg-server:/etc/wireguard:Z

  example-web-server:
    build: example-web-server
    cap_add:
    - NET_ADMIN
    command: /custom/command.sh
    networks:
      wg-network:
        ipv4_address: 192.168.123.2
    volumes:
    - ./example-web-server:/custom:Z

Démarrez le réseau et les conteneurs en les exécutant podman-compose up à partir du même répertoire que le fichier docker-compose.yml.

1. Nous avons explicitement activé le paramètre du noyau de transfert de paquets.
2. Nous avons ajouté l’option Z au volume de configuration WireGuard.
3. Nous avons qualifié le nom de l’image avec le registre docker.io.

Utiliser pour un réseau pont avec WireGuard sur l’hôte

Utiliser pour le réseau Pod

Utiliser pour la redirection de port depuis Internet (Port Forwarding From Internet)

Dépannage

Erreur non prise en charge

Impossible d’initialiser iptables

Erreur de slirp4netns

Erreur lors du réglage de src_valid_mark

Outils de diagnostic