Comment utiliser WireGuard avec UFW
|
Important
|
Traduction d’un article du site Pro Custodibus Le contenu de cette page est la traduction Française de l’article How to Use WireGuard With UFW de Justin Ludwig |
Comment utiliser WireGuard avec UFW
Si vous avez des besoins complexes en pare-feu, il est probablement préférable d’utiliser iptables (ou nftables) lors de la configuration de WireGuard — voir l’article Contrôle d’accès avec WireGuard et iptables pour une guide. Mais si vos besoins sont simples, UFW (le Pare-feu simplifié) fonctionnera parfaitement.
Cet article vous montrera comment utiliser UFW avec WireGuard pour chaque des topologies principales de WireGuard:
Consultez également les notes sur Ping et Dépannage à la fin de l’article.
Point à Point
Commençons par le simple VPN WireGuard point-to-point avec deux hôtes, décrit dans le guide Configuration WireGuard Point-to-Point, et configurons un pare-feu pour lui avec UFW (remplaçant le pare-feu iptables décrit dans les sections supplémentaires du guide).
Voici un diagramme réseau de la situation :
Figure 1. Scénario point à point
Sur l’Endpoint A, qui dans cet exemple est simplement un simple ordinateur portable, nous allons configurer UFW pour interdire toutes les nouvelles connexions à Endpoint A, sauf celles vers le port UDP sur lequel WireGuard écoute lui-même (51821). Sur l’Endpoint B, qui dans cet exemple exécute un serveur web sur le port TCP 80, nous allons configurer UFW pour interdire les nouvelles connexions à deux conditions : 1) autoriser toute connexion au port UDP sur lequel WireGuard écoute lui-même (51822), et 2) autoriser les connexions transférées via WireGuard vers le port TCP 80.
Si vous avez déjà ajouté quelques commandes iptables à la configuration de WireGuard sur vos hôtes, arrêtez leurs interfaces WireGuard (sudo wg-quick down wg0), supprimez ces commandes et redémarrez-les (sudo wg-quick up wg0). Nous ne ajoutons rien supplémentaire aux fichiers de configuration de WireGuard dans cet article — nous utiliserons simplement l’outil en ligne de commande ufw.
Étapes à distance
Configuration UFW sur le Point A
Sur le Point A, vérifiez d’abord l’état de UFW. Si vous ne l’avez pas configuré encore, c’est ce que vous verrez :
$ sudo ufw status
État : inactif
Si il est inactif, cela va bien — nous configurerons nos règles en premier lieu et ensuite l’activons.
Si vous êtes connecté au Point A via SSH, votre première règle devrait être celle qui continue d’autoriser l’utilisation de cette connexion SSH (si vous accédez au Point A physiquement, cependant, passez cette étape). Exécutez la commande suivante sur le Point A pour voir l’adresse IP de l’hôte à partir duquel vous êtes connecté via SSH :
$ ss -tn sport 22
État Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 0 192.168.1.11:22 192.168.1.2:59073
192.168.1.11 est l’adresse IP du Point A sur son propre réseau local (exécutant SSH sur le port TCP 22) ; 192.168.1.2 est l’hôte à partir duquel je suis connecté via SSH. Alors exécutez la commande suivante pour continuer d’autoriser cette connexion une fois que nous allons activer le pare-feu :
$ sudo ufw allow proto tcp from 192.168.1.2 to any port 22
Règles mises à jour
Si vous souhaitez permettre à n’importe quel hôte
sur le LAN de pouvoir se connecter au Point de terminaison A (et non limité au seul hôte depuis lequel vous avez actuellement effectué une connexion SSH), au lieu de 192.168.1.2, vous pouvez spécifier 192.168.1.0/24 (un intervalle qui inclut 192.168.1.0-192.168.1.255) pour la règle ci-dessus.
Pour la deuxième règle, nous permettrons à tout hôte de se connecter au Point de terminaison A via WireGuard (qui écoute sur le port UDP 51821 sur le Point de terminaison A). Exécutez la commande suivante :
$ sudo ufw allow 51821/udp
Règles mises à jour
Règles mises à jour (v6)
Maintenant démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action Depuis
-- ------ ----
22/tcp ALLOW 192.168.1.0/24
51821/udp ALLOW Tout le monde
51821/udp (v6) ALLOW Tout le monde (v6)
UFW est maintenant en cours d’exécution et empêchera toute connexion au Point de terminaison A à l’exception de celle effectuée via WireGuard (ou directement par SSH depuis 192.168.1.0/24). De plus, UFW empêchera toute nouvelle connexion entrante au Point de terminaison A même lorsqu’il est accédé via WireGuard — toutes les connexions à travers le tunnel WireGuard doivent être initiées par le Point de terminaison A (par exemple, si un serveur web était en cours d’exécution sur le Point de terminaison A au port TCP 80, aucun hôte ne serait capable de se connecter entrant à celui-ci, même via WireGuard ; mais le Point de terminaison A pourrait toujours se connecter sortant via WireGuard au serveur web en cours d’exécution sur le Point de terminaison B).
Configuration UFW sur le Point de terminaison B
Sur le Point de terminaison B, faites la même chose. D’abord vérifiez l’état de UFW :
$ sudo ufw status
État : inactif
Si vous êtes connecté au Point de terminaison B via SSH, ajoutez une règle pour permettre la maintenance de votre connexion SSH actuelle. Exécutez la commande suivante sur le Point de terminaison B pour voir l’adresse IP de l’hôte depuis lequel vous avez effectué la connexion SSH :
$ ss -tn sport 22
État Recv-Q Send-Q Adresse locale:Port Adresse distante:Port Processus
ESTAB 0 0 10.0.0.2:22 10.0.0.1:44123
Dans ce cas, j’ai SSHé sur le Point de terminaison B (10.0.0.2) via le tunnel WireGuard depuis le Point de terminaison A (10.0.0.1). Donc, je vais exécuter la commande suivante pour permettre cette connexion une fois que je démarre UFW :
$ sudo ufw allow proto tcp from 10.0.0.1 to any port 22
Règles mises à jour
Ajoutez ensuite une deuxième règle pour permettre à tout hôte de se connecter au Point de terminaison B via WireGuard (qui écoute sur le port UDP 51822 au Point de terminaison B) :
$ sudo ufw allow 51822/udp
Règles mises à jour
Règles mises à jour (v6)
Et sur le Point de terminaison B uniquement, ajoutez une troisième règle pour permettre à tout hôte d’accéder au serveur web en cours d’exécution sur le Point de terminaison B (qui écoute sur le port TCP 80) via WireGuard (où l’interface WireGuard est nommée wg0 sur le Point de terminaison B) :
$ sudo ufw allow in on wg0 proto tcp to any port 80
Règles mises à jour
Règles mises à jour (v6)
Maintenant, démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action Depuis
-- ------ ----
22/tcp ALLOW 10.0.0.1
51822/udp ALLOW Tout le monde
80/tcp sur wg0 ALLOW Tout le monde
51822/udp (v6) ALLOW Tout le monde (v6)
80/tcp (v6) sur wg0 ALLOW Tout le monde
Tout le monde (v6)
UFW est maintenant en cours d'exécution sur le Point de terminaison B et empêchera toute connexion à ce dernier sauf via WireGuard (ou directement via SSH depuis `10.0.0.1`). De plus, UFW empêchera toute nouvelle connexion entrante au Point de terminaison B via WireGuard, à l'exception du port TCP `80` (le serveur web en cours d'exécution sur le Point de terminaison B).
### Testez-le
Vous pouvez tester cela en essayant d'accéder au port TCP 80 du Point de terminaison B depuis le Point de terminaison A :
```bash
$ curl 10.0.0.2
Vous devriez voir le HTML de la page d’accueil de l’Endpoint B imprimé. Si vous démarrez un autre serveur web sur l’Endpoint B à un port TCP 8080 (exécutez python3 -m http.server 8080 pour un serveur temporaire fournissant le contenu du répertoire courant), vous ne pourrez pas y accéder depuis l’Endpoint A (ou n’importe où ailleurs) :
$ curl 10.0.0.2:8080
Vous ne verrez rien imprimé pour le-dessus (la commande va “pendre” — tuez-la en appuyant sur la combinaison de touches Ctrl-C).
Hub et Spoke
Pour démontrer UFW avec une topologie hub-and-spoke, nous utiliserons le VPN WireGuard hub-and-spoke décrit dans le guide Configuration du VPN WireGuard Hub and Spoke. Voici un diagramme réseau de la situation :
Figure 2. Scénario hub et spoke
Dans cet exemple de scénario, sur les “spokes” Endpoint A et Endpoint B, nous allons configurer UFW pour interdire toutes nouvelles connexions aux points de terminaison à l’exception du WireGuard — mais permettre un accès complet à tout ce qui est connecté via le WireGuard. Sur le “hub”, Host C, nous allons configurer UFW pour interdire toutes nouvelles connexions au hub à l’exception du WireGuard ; et nous empêcherons le hub de transférer toute nouvelle connexion via ses tunnels WireGuard à l’exception du serveur web en écoute sur le port TCP 80 de Endpoint B.
Cela nous permet d’utiliser UFW sur le hub comme le lieu central pour appliquer le contrôle d’accès dans notre VPN WireGuard. Lorsque nous ajoutons plus de points de terminaison à notre VPN, nous pouvons les configurer avec la même configuration UFW que Endpoint A ou B, et interdire l’accès à ou depuis eux via des modifications de configuration UFW sur Host C.
Si vous avez déjà ajouté quelques commandes iptables à la configuration de WireGuard de vos hôtes, arrêtez leurs interfaces WireGuard (sudo wg-quick down wg0), supprimez les commandes iptables et redémarrez-les (sudo wg-quick up wg0). Nous ne ajoutons rien d’extraordinaire à notre configuration WireGuard dans cet article — nous utiliserons simplement l’outil de ligne de commande ufw pour tout. UFW persistera nos paramètres via des fichiers dans le répertoire /etc/ufw, et configurera automatiquement le pare-feu au démarrage du hôte.
Étapes Hub-and-Spoke
- Configuration UFW sur Endpoint A
- Configuration UFW sur Endpoint B
- Transfert de paquets sur Host C
- Configuration UFW sur Host C
- Tester
Configuration UFW sur Endpoint A
Sur Endpoint A, vérifiez d’abord l’état de UFW. Si vous ne l’avez pas configuré encore, c’est ce que vous verrez :
$ sudo ufw status
État : inactif
Si il est inactif, cela va bien — nous configurerons nos règles et ensuite l’activons.
Si vous êtes connecté à Endpoint A via SSH, votre première règle devrait être de continuer à autoriser cette connexion SSH (si vous accédez à Endpoint A physiquement, vous pouvez sauter cette règle). Exécutez la commande suivante sur Endpoint A pour voir l’adresse IP du hôte à partir duquel vous êtes connecté via SSH :
$ ss -tn sport 22
État Recv-Q Send-Q Local Address:Port Peer Address:Port Pr
… (suite de la commande)
ocess
ESTAB 0 0 192.168.1.11:22 192.168.1.2:61124
`192.168.1.11` est l'adresse IP de Endpoint A sur son propre réseau local (exécutant SSH sur le port TCP `22`) ; `192.168.1.2` est le hôte à partir duquel je suis connecté via SSH. Alors exécutez la commande suivante pour continuer à autoriser cette connexion une fois que nous allons activer le pare-feu :
```bash
$ sudo ufw allow proto tcp from 192.168.1.2 to any port 22
Règles mises à jour
Si vous souhaitez permettre à n’importe quel hôte sur le LAN de pouvoir se connecter au Point de terminaison A (et non limité au seul hôte depuis lequel vous avez actuellement effectué une connexion SSH), au lieu de 192.168.1.2, vous pouvez spécifier 192.168.1.0/24 (un intervalle qui inclut 192.168.1.0-192.168.1.255) pour la règle ci-dessus.
Pour la deuxième règle, nous permettrons à tout hôte de se connecter au Point de terminaison A via WireGuard (qui écoute sur le port UDP 51821 sur le Point de terminaison A). Exécutez la commande suivante :
$ sudo ufw allow 51821/udp
Règles mises à jour
Règles mises à jour (v6)
Maintenant, pour la troisième règle, nous permettrons tout type d’accès à partir de tout hôte, tant qu’il passe par WireGuard (wg0 est le nom de notre interface WireGuard sur le Point de terminaison A) :
$ sudo ufw allow in on wg0
Règles mises à jour
Règles mises à jour (v6)
Démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action De
-- ------ ----
22/tcp ALLOW 192.168.1.2
51821/udp ALLOW Anywhere
Anywhere on wg0 ALLOW Anywhere
51821/udp (v6) ALLOW Anywhere (v6)
Anywhere (v6) on wg0 ALLOW Anywhere (v6)
UFW est maintenant en cours d’exécution sur le Point de terminaison A et empêchera toute connexion à ce dernier, sauf via WireGuard (ou directement via SSH depuis 192.168.1.2).
Configuration UFW sur le Point de terminaison B
Sur le Point de terminaison B, faites la même chose. D’abord vérifiez l’état de UFW :
$ sudo ufw status
État : inactive
Si vous êtes connecté au Point de terminaison B via SSH, ajoutez une règle pour permettre votre connexion SSH actuelle. Exécutez la commande suivante sur le Point de terminaison B pour voir l’adresse IP de l’hôte depuis lequel vous avez effectué la connexion SSH :
$ ss -tn sport 22
État Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 0 192.168.200.22:22 198.51.100.1:59193
Dans ce cas, j’ai SSH’ed sur le Point de terminaison B (192.168.200.22) à distance depuis 198.51.100.1. Ainsi, je pourrais exécuter la commande suivante pour permettre cette connexion une fois que j’aurai démarré UFW :
$ sudo ufw allow proto tcp from 198.51.100.1 to any port 22
Règles mises à jour
Ensuite, ajoutez une deuxième règle pour permettre à tout hôte de se connecter au Point de terminaison B via WireGuard (qui écoute sur le port UDP 51822 sur le Point de terminaison B) :
$ sudo ufw allow 51822/udp
Règles mises à jour
Règles mises à jour (v6)
Et maintenant, ajoutez une troisième règle pour permettre tout type d’accès à partir de tout hôte via WireGuard (wg0 est le nom de notre interface WireGuard sur le Point de terminaison B) :
$ sudo ufw allow in on wg0
Règles mises à jour
Règles mises à jour (v6)
Maintenant, démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action De
-- ------ ----
22/tcp ALLOW 198.51.100.1
51822/udp ALLOW Anywhere
Tout le monde
Tout sur wg0 ALLOW Tout le monde
51822/udp (v6) ALLOW Tout le monde (v6)
Tout (v6) sur wg0 ALLOW Tout le monde (v6)
UFW est maintenant en cours d’exécution sur le Point de terminaison B et empêchera toute connexion à ce dernier, sauf via WireGuard (ou directement via SSH depuis 198.51.100.1).
Transfert des paquets sur l’Hôte C
Le guide original WireGuard Hub and Spoke Configuration dans la section “Configure Routing on Host C” vous dirige vers d’ajouter la ligne suivante dans la configuration WireGuard sur l’Hôte C :
PreUp = sysctl -w net.ipv4.ip_forward=1
Cela permet à l’Hôte C de transférer les paquets depuis le Point de terminaison A vers le Point de terminaison B (ou tout autre hôte). Comme nous utilisons UFW, vous pouvez omettre cette ligne de votre configuration WireGuard et modifier au lieu cela le fichier /etc/ufw/sysctl.conf sur l’Hôte C (en tant que root) pour décommenter les lignes suivantes (c’est-à-dire supprimer le # existant au début des lignes afin qu’elles ressemblent à celles-ci) :
net.ipv4.ip_forward=1
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
Configuration UFW sur l’Hôte C
Sur l’Hôte C, vérifiez l’état de UFW :
$ sudo ufw status
Status: inactive
Si vous êtes connecté à l’Hôte C via SSH, votre première règle devrait être de continuer à autoriser cette connexion SSH (si vous accédez à l’Hôte C physiquement, vous pouvez sauter cette règle). Exécutez la commande suivante sur l’Hôte C pour voir l’adresse IP de l’hôte à partir duquel vous êtes connecté via SSH :
$ ss -tn sport 22
État Recv-Q Send-Q Adresse locale:Port Adresse distante:Port Processus
ESTAB 0 0 192.168.30.33:22 192.168.30.1:56818
192.168.30.33 est l’adresse IP de l’Hôte C sur son propre réseau local (en exécutant SSH sur le port TCP 22) ; 192.168.30.1 est l’hôte à partir duquel j’ai effectué la connexion SSH. Exécutez la commande suivante pour continuer à autoriser cette connexion une fois que nous allons activer le pare-feu :
$ sudo ufw allow proto tcp from 192.168.30.1 to any port 22
Règles mises à jour
Pour la deuxième règle, nous permettrons à tout hôte de se connecter à l’Hôte C via WireGuard (qui écoute sur le port UDP 51823 sur l’Hôte C) en exécutant la commande suivante :
$ sudo ufw allow 51823/udp
Règles mises à jour
Règles mises à jour (v6)
Maintenant pour notre troisième règle, nous permettrons à tout hôte connecté à l’Hôte C via WireGuard (où wg0 est le nom de l’interface WireGuard sur l’Hôte C) d’utiliser cette connexion pour accéder au serveur web en cours d’exécution sur le Point de terminaison B (qui écoute sur le port TCP 80 du Point de terminaison B) :
$ sudo ufw route allow in on wg0 proto tcp to 10.0.0.2 port 80
Règles mises à jour
Remarque que pour les règles UFW comme celle-ci, qui permettent au hôte local de transférer des paquets d’un autre hôte externe à un autre, la règle commence par le mot-clé route (ufw route allow …) ; tandis que les règles UFW qui s’appliquent aux paquets destinés au hôte local lui-même ne le font pas (ufw allow …).
Maintenant, démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Pour Action De
-- ------ ----
22/tcp ALLOW 192.168.30.1
51823/udp ALLOW Toute part
51823/udp (v6) ALLOW Toute part (v6)
10.0.0.2 80/tcp ALLOW FWD Toute part sur wg0
UFW est maintenant en cours d’exécution sur le hôte C, et il empêchera toute connexion à Host C sauf via WireGuard (ou directement par SSH depuis 198.51.100.1).
uis 192.168.30.1). De plus, UFW empêchera Host C de servir comme passerelle pour les nouvelles connexions entre les hôtes dans son réseau WireGuard, à l’exception des nouvelles connexions au port TCP 80 du serveur web en cours d’exécution sur le point de terminaison B (10.0.0.2).
Testez-le
Vous pouvez tester cela en essayant d’accéder au port TCP 80 du point de terminaison B depuis le point de terminaison A :
$ curl 10.0.0.2
Vous devriez voir l’HTML de la page d’accueil du point de terminaison B affiché. Si vous démarrez un autre serveur web sur le point de terminaison B en cours d’exécution au port TCP 8080 (exécutez python3 -m http.server 8080 pour un serveur temporaire fournissant les contenus du répertoire courant), vous ne pourrez pas y accéder depuis le point de terminaison A (ou n’importe où d’autre) :
$ curl 10.0.0.2:8080
Vous ne verrez rien affiché pour la commande ci-dessus (la commande « se bloque » — tuez-la en combinant les touches Ctrl-C).
De même, si vous démarrez un serveur web sur le point de terminaison A (avec python3 -m http.server 8080), vous ne pourrez pas y accéder depuis le point de terminaison B :
$ curl 10.0.0.1:8080
Encore une fois, rien ne sera affiché. Seulement si vous ajoutez des règles UFW supplémentaires à l’Hôte C (comme ufw route allow in on wg0 proto tcp to 10.0.0.1 port 8080), vous pourrez accéder au serveur web sur le Point de terminaison A.
Point à Site
Pour un exemple de point à site, nous utiliserons le VPN WireGuard point à site décrit dans la Configuration du VPN WireGuard Point à Site guide. Nous configurerons un pare-feu sur le point distant (le “point”, Endpoint A), sur le point local (Endpoint B, à l’intérieur du “site”), et sur le serveur WireGuard local (Host β, l’hôte qui permet au “point” d’accéder au “site”). Cela remplacera le pare-feu iptables décrit dans la section “supplémentaire” du guide, ainsi que la configuration de routage pour Host β décrite dans la section “configurer le routage” du guide.
Voici un diagramme réseau de la situation :
Figure 3. Scénario point à site
Sur le point distant (Endpoint A), nous configurerons UFW pour interdire toutes les nouvelles connexions sauf via WireGuard, et permettre un accès complet à tout ce qui est connecté via WireGuard. Sur le point local (Endpoint B), nous configurerons UFW pour interdire toutes les nouvelles connexions sauf depuis le site local (Site B) vers le port TCP 80 d’Endpoint B (où se trouve un serveur web).
Sur le serveur WireGuard local (Host β), nous configurerons UFW pour interdire toutes les nouvelles connexions au serveur sauf pour les connexions WireGuard, et interdire la transmission de toute nouvelle connexion sauf vers le port TCP 80 d’Endpoint B. De plus, nous modifierons la configuration de UFW sur Host β pour permettre le routage des paquets entre le VPN WireGuard et le LAN (Réseau local) du Site B via masquage d’adresse IP (également connu sous le nom de SNAT, ou Translation d’adresse réseau source).
Si vous avez déjà ajouté quelques commandes iptables à la configuration WireGuard de vos hôtes, arrêtez leurs interfaces WireGuard (sudo wg-quick down wg0), supprimez les commandes et redémarrez-les (sudo wg-quick up wg0). Nous ne ferons rien d’extraordinaire dans les fichiers de configuration WireGuard de cet article — nous utiliserons simplement l’outil de ligne de commande ufw pour tout. UFW persistera nos paramètres via des fichiers dans le répertoire /etc/ufw, et configurera automatiquement le pare-feu au démarrage du hôte.
Étapes Point-to-Site
- Configuration UFW sur Endpoint A
- Configuration UFW sur Endpoint B
- Transfert et masquage des paquets sur l’hôte B
Configuration UFW sur Endpoint A
Sur Endpoint A, vérifiez d’abord l’état de UFW. Si vous ne l’avez pas encore configuré, c’est ce que vous verrez :
$ sudo ufw status
État : inactif
Si c’est inactif, cela va bien — nous configurerons nos règles en premier lieu, puis l’activons.
Si vous êtes connecté à Endpoint A via SSH, votre première règle devrait permettre le maintien de l’utilisation de cette connexion SSH (si vous accédez à Endpoint A physiquement, cependant, sautez-la). Exécutez la commande suivante sur Endpoint A pour voir l’adresse IP de l’hôte à partir duquel vous êtes connecté via SSH :
$ ss -tn sport 22
État Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 0 192.168.1.11:22 192.168.1.2:33312
192.168.1.11 est l’adresse IP de Endpoint A sur son propre réseau local (exécutant SSH sur le port TCP 22) ; 192.168.1.2 est l’hôte à partir duquel je suis connecté via SSH. Alors exécutez la commande suivante pour permettre cette connexion une fois que nous allons activer le pare-feu :
$ sudo ufw allow proto tcp from 192.168.1.2 to any port 22
Règles mises à jour
Si vous souhaitez autoriser n’importe quel hôte sur le réseau local de l’Endpoint A d’être en mesure de se connecter à Endpoint A (et non limité au seul hôte depuis lequel vous êtes actuellement connecté par SSH), au lieu de 192.168.1.2, vous pouvez spécifier 192.168.1.0/24 (une plage qui inclut 192.168.1.0-192.168.1.255) pour la règle ci-dessus.
Pour la deuxième règle, nous autoriserons tout hôte à se connecter à Endpoint A via WireGuard (qui écoute sur le port UDP 51821 sur Endpoint A) en exécutant la commande suivante :
$ sudo ufw allow 51821/udp
Règles mises à jour
Règles mises à jour (v6)
Et pour la troisième règle, nous autoriserons tout accès via WireGuard (où l’interface de WireGuard est nommée wg0 sur Endpoint A) :
$ sudo ufw allow in on wg0
Règles mises à jour
Règles mises à jour (v6)
Maintenant, démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action De
-- ------ ----
22/tcp ALLOW 192.168.1.2
51821/udp ALLOW Tout le monde
Tout sur wg0 ALLOW Tout le monde
51821/udp (v6) ALLOW Tout le monde (v6)
Tout (v6) sur wg0 ALLOW Tout le monde (v6)
UFW est maintenant en cours d’exécution sur Endpoint A et empêchera toute connexion à Endpoint A, sauf via WireGuard (ou directement par SSH depuis 192.168.1.2).
Configuration UFW sur Endpoint B
Sur Endpoint B, vérifiez l’état de UFW :
$ sudo ufw status
État : inactif
Si vous êtes connecté à Endpoint B via SSH, ajoutez une règle pour autoriser l’accès SSH depuis le réseau local du Site B :
$ sudo ufw allow proto tcp from 192.168.200.0/24 to any port 22
Règles mises à jour
Ensuite, ajoutez une règle pour autoriser tout hôte sur le réseau local à se connecter au port TCP 80 :
$ sudo ufw allow proto tcp from 192.168.200.0/24 to any port 80
Règles mises à jour
Maintenant, démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action De
-- ------ ----
22/tcp ALLOW 192.168.200.0/24
80/tcp ALLOW 192.168.200.0/24
UFW est maintenant actif et en cours d’exécution sur le Point de terminaison B, et il permettra uniquement
nt les connexions du LAN Site B au port TCP 80 (ou au port TCP 22 pour SSH).
Transfert et masquage des paquets sur l’Hôte B
Dans la section “Configurer le routage sur l’Hôte β” de l’original Guide de configuration WireGuard Point to Site, vous êtes invité à ajouter quelques lignes à la configuration WireGuard de l’Hôte β pour activer le transfert d’adresses IP et le masquage d’IP. Mais étant donné que nous utilisons UFW, vous pouvez omettre ces lignes de votre configuration WireGuard et modifier au lieu cela la configuration de UFW.
Tout d’abord, éditez le fichier /etc/ufw/sysctl.conf sur l’Hôte β (en tant que root) et décommentez les lignes suivantes :
net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1
Ensuite, éditez le fichier /etc/ufw/before.rules (ou si vous utilisez des adresses IPv6, le fichier etc/ufw/before6.rules) pour ajouter le bloc suivant après la ligne existante COMMIT à la fin du fichier :
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
Mais assurez-vous de remplacer eth0 dans le bloc ci-dessus par le nom réel de l’interface réseau qui connecte l’Hôte β au LAN Site B (si ce n’est pas en fait eth0). Si vous ne savez pas quel est ce nom d’interface, exécutez la commande ip -brief address show sur l’Hôte β pour afficher la liste des interfaces :
$ ip -brief address show
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.200.2/24
wg0 UNKNOWN 10.0.0.2/32
Si vous aviez déjà UFW en cours d’exécution avant de faire ces modifications, redémarrez UFW avec la commande sudo systemctl restart ufw.
Configuration de UFW sur l’Hôte B
Sur l’Hôte β, vérifiez le statut d’UFW :
$ sudo ufw status
Status: inactive
Si vous êtes connecté à l’Hôte β via SSH, ajoutez une règle pour permettre l’accès SSH depuis le réseau LAN du Site B :
$ sudo ufw allow proto tcp from 192.168.200.0/24 to any port 22
Rules updated
Ensuite, ajoutez une règle pour permettre à tout hôte de se connecter à l’Hôte β via WireGuard (qui écoute sur le port UDP 51822 de l’Hôte β) :
$ sudo ufw allow 51822/udp
Rules updated
Rules updated (v6)
Ensuite, ajoutez une règle pour permettre à tout hôte connecté à l’Hôte β via WireGuard (wg0 est le nom de l’interface WireGuard sur l’Hôte β) d’utiliser cette connexion pour accéder au serveur web en cours d’exécution sur le Point de terminaison B (qui écoute sur le port TCP 80 du Point de terminaison B) :
$ sudo ufw route allow in on wg0 proto tcp to 192.168.200.22 port 80
Rules updated
Notez que pour les règles UFW comme celle-ci, qui permettent au hôte local de transférer des paquets d’un autre hôte externe à un autre, la règle commence par le mot-clé route (ufw route allow …) ; tandis que les règles UFW qui s’appliquent aux paquets destinés directement au hôte local ne le font pas (ufw allow …).
Maintenant démarrez UFW et vérifiez son statut :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
Status: active
To Action From
-- ------ ----
22/tcp ALLOW 192.168.200.0/24
51822/udp ALLOW Anywhere
51822/udp (v6) ALLOW Anywhere (v6)
192.168.200.22 80/tcp ALLOW FWD Anywhere on wg0
UFW est maintenant en cours d’exécution sur l’Hôte β et empêchera toute connexion à l’Hôte β sauf via WireGuard (ou directement via SSH depuis le réseau LAN du Site B, 192.168.200.0/24). De plus, UFW empêchera l’Hôte β d’être utilisé pour transférer de nouvelles connexions entre les hôtes, sauf via WireGuard au port TCP 80 du serveur web en cours d’exécution sur le Point de terminaison B (192.168.200.22).
Sayant d’accéder au port TCP 80 du Point de terminaison B depuis le Point de terminaison A :
$ curl 192.168.200.22
Vous devriez voir le HTML de la page d’accueil du Point de terminaison B affiché. Si vous démarrez un autre serveur web sur le Point de terminaison B en écoute sur le port TCP 8080 (exécutez python3 -m http.server 8080 pour un serveur temporaire fournissant les contenus du répertoire courant), vous ne pourrez pas y accéder depuis le Point de terminaison A :
$ curl 192.168.200.22:8080
Vous ne verrez rien affiché pour la commande ci-dessus (la commande va “pendre” — tuez-la en appuyant sur la combinaison de touches Ctrl-C).
Extra : Transfert de ports sur le Hôte B
Si vous voulez l’inverse de l’exemple précédent, comme le scénario décrit par le guide WireGuard Point to Site With Port Forwarding qui permet au Point de terminaison B (dans le site local) de se connecter à un serveur web sur le Point de terminaison A (le “point” distant), vous devrez modifier le fichier /etc/ufw/before.rules sur le Hôte β pour autoriser le transfert de ports (également connu sous le nom de Traduction d’adresse réseau de destination, ou DNAT).
Pour activer le transfert de ports pour cet exemple, éditez la section *nat du fichier /etc/ufw/before.rules que nous avons ajoutée précédemment pour inclure également les lignes suivantes PREROUTING :
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
Contrairement à la règle POSTROUTING, qui s’applique à tous les paquets transférés sortants de l’interface LAN du Site B sur le Hôte β, cette règle PREROUTING (la ligne commençant par -A PREROUTING -i …) s’applique spécifiquement à ce cas unique où nous voulons transférer les paquets initialement destinés au port TCP 80 du Hôte β lui-même vers le Point de terminaison A (10.0.0.1). Pour chaque autre port que vous souhaitez transférer sur le Hôte β, vous devrez ajouter une règle supplémentaire PREROUTING au fichier /etc/ufw/before.rules avec le port spécifique à transférer et la destination vers laquelle il doit être transféré.
Nous devons également ajouter une règle UFW séparée pour chaque port transféré. Pour cet exemple spécifique, ajoutez une règle UFW sur l’Hôte β pour permettre le transfert de paquets vers le port TCP 80 sur le Point de terminaison A (10.0.0.1) :
$ sudo ufw route allow proto tcp to 10.0.0.1 port 80
Règles mises à jour
Redémarrez ensuite UFW et vérifiez son état :
$ sudo systemctl restart ufw
$ sudo ufw status
État : actif
To Action From
-- ------ ----
22/tcp ALLOW 192.168.200.0/24
51822/udp ALLOW Anywhere
51822/udp (v6) ALLOW Anywhere (v6)
192.168.200.22 80/tcp ALLOW FWD Anywhere on wg0
10.0.0.1 80/tcp ALLOW FWD Anywhere
Testez-le en essayant d’accéder au port TCP 80 sur l’Hôte β depuis le Point de terminaison B (l’Hôte β transférera maintenant son port TCP 80 vers le Point de terminaison A) :
$ curl 192.168.200.2
Vous devriez voir la page d’accueil HTML du Point de terminaison A affichée.
Site à Site
Pour un exemple site à site, nous utiliserons le VPN WireGuard site à site configuré dans le guide WireGuard Configuration for the Sites. Nous configurerons des pare-feux UFW sur les points de terminaison des deux sites ainsi que sur les hôtes WireGuard, en remplaçant le pare-feu iptables décrit dans la section “supplémentaire” du guide.
Voici un diagramme réseau de la situation :
Figure 4. Scénario site à site
Sur le Point de terminaison A, nous configurerons UFW pour interdire
e toutes les nouvelles connexions ; et sur le Point de terminaison B, nous configurerons UFW pour permettre uniquement les nouvelles connexions au serveur web de l’Hôte B qui écoute sur le port TCP 80. Sur les deux serveurs WireGuard (l’Hôte α et l’Hôte β), nous permettrons à tout hôte de se connecter aux serveurs via WireGuard, et nous permettrons également le transfert de toutes les connexions entre le Site A et le Site B.
Site A et Site B ont déjà été configurés pour se routage entre eux via les deux serveurs WireGuard (comme décrit dans le guide de configuration du site à site), donc nous ne modifierons pas leur configuration UFW pour activer la traduction d’adresses réseau (NAT) comme nous l’avions fait pour l’Hôte β dans le scénario Point to Site. Mais nous éditerons les fichiers de configuration UFW des serveurs WireGuard pour activer le transfert de paquets.
Si vous avez déjà ajouté quelques commandes iptables à la configuration WireGuard de vos hôtes, arrêtez leurs interfaces WireGuard (sudo wg-quick down wg0), supprimez les commandes et redémarrez-les (sudo wg-quick up wg0). Nous ne ajoutons rien supplémentaire aux fichiers de configuration WireGuard dans cet article — nous utiliserons simplement l’outil de ligne de commande ufw. UFW persistera nos paramètres via des fichiers dans le répertoire /etc/ufw, et configurera automatiquement le pare-feu au démarrage de l’hôte.
Étapes du site à site
- Configuration UFW sur le Point de terminaison A
- Configuration UFW sur le Point de terminaison B
- Transfert de paquets
- Configuration UFW sur l’Hôte A
- Configuration UFW sur l’Hôte B
- Testez-le
Configuration UFW sur le Point de terminaison A
Sur le Point de terminaison A, d’abord vérifiez l’état de UFW. Si vous ne l’avez pas encore configuré, c’est ce que vous verrez :
$ sudo ufw status
État : inactif
À moins qu’il n’y ait une connexion SSH à Endpoint A, la seule chose dont vous avez besoin à faire sur Endpoint A est de démarrer UFW. Si vous êtes connecté à Endpoint A via SSH, cependant, exécutez d’abord la commande suivante pour permettre continuer l’accès SSH à Endpoint A depuis le réseau local Site A (192.168.1.0/24 — une plage qui inclut 192.168.1.0-192.168.1.255) :
$ sudo ufw allow proto tcp from 192.168.1.0/24 to any port 22
Règles mises à jour
Maintenant démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action De
-- ------ ----
22/tcp ALLOW 192.168.1.0/24
Ainsi, UFW est maintenant en cours d’exécution sur le Point de terminaison A et empêchera tout nouveau flux entrant vers le Point de terminaison A (sauf via SSH directement à partir du réseau local Site A). Le Point de terminaison A pourra toujours établir de nouveaux flux sortants, comme pour initier de nouvelles connexions au serveur web en cours d’exécution sur le Point de terminaison B.
Configuration UFW sur le Point de terminaison B
Sur le Point de terminaison B, vérifiez l’état de UFW :
$ sudo ufw status
État : inactif
Si vous êtes connecté au Point de terminaison B via SSH, ajoutez une règle pour permettre l’accès SSH à partir du réseau local Site B :
$ sudo ufw allow proto tcp from 192.168.200.0/24 to any port 22
Règles mises à jour
Ensuite, ajoutez quelques règles pour permettre à tout hôte dans l’un des réseaux (Site A ou Site B) de se connecter au port TCP 80 :
$ sudo ufw allow proto tcp from 192.168.1.0/24 to any port 80
Règles mises à jour
$ sudo ufw allow proto tcp from 192.168.200.0/24 to any port 80
Règles mises à jour
Maintenant, démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action De
-- ------ ----
22/tcp ALLOW 192.168.200.0/24
80/tcp ALLOW 192.168.1.0/24
80/tcp ALLOW 192.168.200.0/24
UFW est maintenant en cours d’exécution sur le Point de terminaison B et permettra uniquement les connexions au port TCP 80 des réseaux Site A et B (ou au port TCP 22 pour SSH du réseau local Site B).
Transfert de paquets
Dans le guide original Configuration Site à Site de WireGuard , la section “Configurer le Routage” vous guide à ajouter quelques lignes à la configuration de WireGuard de l’Hôte α et de l’Hôte β pour activer le transfert d’adresses IP. Mais étant donné que nous utilisons UFW, vous pouvez omettre ces lignes de votre configuration de WireGuard et modifier au lieu cela la configuration de UFW.
Sur les deux Hôtes α et β, éditez le fichier /etc/ufw/sysctl.conf (en tant que root) pour décommenter les lignes suivantes :
net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1
Si vous avez déjà UFW en cours d’exécution avant de faire ce changement, redémarrez UFW avec la commande sudo systemctl restart ufw.
Configuration de UFW sur l’Hôte A
Sur l’Hôte α, vérifiez l’état de UFW :
$ sudo ufw status
État : inactive
Si vous êtes connecté à l’Hôte α via SSH, ajoutez une règle pour permettre l’accès SSH depuis le LAN Site A :
$ sudo ufw allow proto tcp from 192.168.1.0/24 to any port 22
Ensuite, ajoutez une règle pour permettre à tout hôte de se connecter à l’Hôte α via WireGuard (qui écoute sur le port UDP 51821 sur l’Hôte α) :
$ sudo ufw allow 51821/udp
Règles mises à jour
Règles mises à jour (v6)
Ensuite, ajoutez une règle pour permettre de nouvelles connexions destinées au Site B (192.168.200.0/24) à travers le tunnel WireGuard vers l’Hôte β :
$ sudo ufw route allow to 192.168.200.0/24
Règles mises à jour
Dans notre exemple de scénario, la seule connexion inter-site que nous devons autoriser est celle entre le Point de terminaison A et le Point de terminaison B via HTTP. Si c’est la seule connexion que vous devez réellement activer, vous pouvez ajuster la règle ci-dessus de nombreuses façons différentes pour la rendre plus restrictive. De manière la plus restrictive, vous pouvez empêcher tout hôte du Site A autre que le Point de terminaison A de se connecter à tout hôte du Site B autre que le Point de terminaison B (et permettre au Point de terminaison A de se connecter uniquement au port TCP 80 du Point de terminaison B) :
$ sudo ufw route allow proto tcp from 192.168.1.11 to 192.168.200.22 port 80
Règles mises à jour
Vous pouvez également permettre à tout hôte du Site A de se connecter uniquement au Point de terminaison B (mais pas d’autres hôtes du Site B) via HTTP (et pas d’autres ports) :
$ sudo ufw route allow proto tcp to 192.168.200.22 port 80
Règles mises à jour
Vous pouvez également permettre uniquement au Point de terminaison A (mais pas d’autres hôtes du Site A) de se connecter à tout hôte du Site B :
$ sudo ufw route allow from 192.168.1.11
Règles mises à jour
Alternativement, si vous vouliez une connexion inverse, par exemple pour permettre à un hôte particulier du Site B (disons un Point de terminaison BBB avec l’adresse IP 192.168.200.123) de se connecter à un hôte particulier du Site A (disons le Point de terminaison AAA, un serveur de messagerie avec l’adresse IP 192.168.1.45, qui écoute sur le port TCP 25), vous pouvez permettre cette connexion spécifique d’être initiée depuis le Site B vers le Site A avec la règle suivante :
$ sudo ufw route allow proto tcp from 192.168.200.123 to any port 25
Règles mises à jour
00.123 à 192.168.1.45 sur le port 25
Règles mises à jour
Vous pouvez également permettre à tout hôte du Site B d’accéder au Point de terminaison AAA :
$ sudo ufw route allow proto tcp to 192.168.1.45 port 25
Règles mises à jour
Vous pouvez également permettre au Point de terminaison BBB d’accéder à tout hôte du Site A :
$ sudo ufw route allow from 192.168.200.123
Règles mises à jour
Vous pouvez simplement permettre à tout hôte du Site B de se connecter à tout hôte du Site A :
$ sudo ufw route allow from 192.168.200.0/24
Règles mises à jour
Notez que pour les règles UFW comme celle-ci, qui permettent au hôte local de transférer des paquets d’un autre hôte externe à un autre, la règle commence par le mot-clé route (ufw route allow …) ; tandis que les règles UFW qui s’appliquent aux paquets destinés directement au hôte local ne le font pas (ufw allow …).
Notez également que UFW ajoute automatiquement des règles de pare-feu pour permettre le transfert de paquets vers les connexions déjà établies (comme si Endpoint A envoie une requête HTTP à Endpoint B, la réponse HTTP de Endpoint B à Endpoint A fait partie d’une connexion établie, et ne compte pas comme une nouvelle connexion). Donc, vous n’avez besoin que de configurer des règles UFW pour permettre (ou interdire) l’initiation de nouvelles connexions entre un hôte et un autre.
Si le seul route rule utilisé ci-dessus était la première, ufw route allow to 192.168.200.0/24, cela permettrait à tout hôte du Site A d’initier une nouvelle connexion vers tout hôte du Site B (par exemple, permettre un navigateur en cours d’exécution sur un hôte du Site A de faire une requête HTTP à un serveur web en cours d’exécution sur un hôte du Site B), mais ne permettrait pas à tout hôte du Site B d’initier une nouvelle connexion vers tout hôte du Site A (par exemple, ne permettant pas un navigateur en cours d’exécution sur un hôte du Site B de faire une requête HTTP à un serveur web en cours d’exécution sur un hôte du Site A).
Avec cette seule règle route ci-dessus en place, lançons UFW et vérifions son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
To Action From
-- ------ ----
22/tcp ALLOW 192.168.1.0/24
51821/udp ALLOW Tout le monde
51821/udp (v6) ALLOW Tout le monde (v6)
192.168.200.0/24 ALLOW FWD Tout le monde
UFW est maintenant en cours d’exécution sur l’Hôte α, et empêchera les connexions directes à lui sauf via WireGuard (ou via SSH depuis le réseau local du Site A). Mais il permettra toujours les nouvelles connexions à transférer du Site A au Site B (permettant à Endpoint A de naviguer sur le serveur web en cours d’exécution sur Endpoint B) — simplement pas du Site B au Site A (interdisant les connexions aléatoires d’être initiées depuis les hôtes du Site B vers les hôtes du Site A).
Configuration UFW sur l’Hôte B
Sur l’Hôte β, vérifiez l’état de UFW :
$ sudo ufw status
État : inactif
Si vous êtes connecté à l’Hôte β via SSH, ajoutez une règle pour permettre l’accès SSH depuis le LAN du Site B :
$ sudo ufw allow proto tcp from 192.168.200.0/24 to any port 22
Règles mises à jour
Ensuite, ajoutez une règle pour permettre à tout hôte de se connecter à l’Hôte β via WireGuard (qui écoute sur le port UDP 51822 de l’Hôte β) :
$ sudo ufw allow 51822/udp
Règles mises à jour
Règles mises à jour (v6)
Ajoutez ensuite une règle pour permettre les nouvelles connexions sortantes destinées au Site A (192.168.1.0/24) via le tunnel WireGuard vers l’Hôte α :
$ sudo ufw route allow to 192.168.1.0/24
Règles mises à jour
Et enfin, ajoutez une règle pour permettre les nouvelles connexions entrantes au Site B (192.168.200.0/24) depuis le tunnel WireGuard avec l’Hôte α :
$ sudo ufw route allow from 192.168.200.0/24
Règles mises à jour
Voici le texte corrigé :
$ sudo ufw route allow to 192.168.200.0/24
Règles mises à jour
Maintenant, démarrez UFW et vérifiez son état :
$ sudo ufw enable
Le pare-feu est actif et activé au démarrage du système
$ sudo ufw status
État : actif
Vers Action De
-- ------ ----
22/tcp ALLOW 192.168.200.0/24
51822/udp ALLOW Tout le monde
51822/udp (v6) ALLOW Tout le monde (v6)
192.168.1.0/24 ALLOW FWD Tout le monde
192.168.200.0/24 ALLOW FWD Tout le monde
UFW est maintenant en cours d’exécution sur l’Hôte β et empêchera les connexions directes à lui, sauf via WireGuard (ou via SSH depuis le LAN du Site B). Cependant, il permettra les nouvelles connexions à être transférées du Site A au Site B et vice versa.
Testez-le
Vous pouvez tester cela en essayant d’accéder au port TCP 80 de l’Endpoint B depuis l’Endpoint A :
$ curl 192.168.200.22
Vous devriez voir le code HTML de la page d’accueil de l’Endpoint B affiché. Si vous démarrez un autre serveur web sur l’Endpoint B en écoute sur le port TCP 8080 (exécutez python3 -m http.server 8080 pour un serveur temporaire fournissant les contenus du répertoire courant), vous ne pourrez pas y accéder depuis l’Endpoint A :
$ curl 192.168.200.22:8080
Vous ne verrez rien affiché pour la commande précédente (la commande “pendra” — arrêtez-la en appuyant sur la combinaison de touches Ctrl-C).
De même, si vous démarrez un serveur web sur l’Endpoint A (avec python3 -m http.server 8080), vous ne pourrez pas y accéder depuis l’Endpoint B :
$ curl 192.168.1.11:8080
Encore une fois, rien ne sera affiché. Seulement si vous ajoutez des règles UFW supplémentaires 1) au Point de terminaison A, pour permettre les nouvelles connexions à celui-ci (comme sudo ufw allow proto tcp to any port 8080), et 2) au Hôte α, pour permettre les nouvelles connexions à être transférées vers le Site A (comme ufw route allow to 192.168.1.0/24), vous pourrez accéder au serveur web en cours d’exécution sur l’Endpoint A.
Ping
Si vous essayez de pinger un hôte exécutant UFW (ou tout hôte où la connexion à l’hôte est transférée via UFW), vous pouvez être surpris de voir vos pings réussir même lorsque le pare-feu UFW bloque la mise en place de la plupart des autres nouvelles connexions. Par exemple, avec les scénarios Point à Point ou Hub et Spoke ci-dessus, vous pouvez exécuter ping 10.0.0.1 sur le Point de terminaison B et voir des réponses provenant du Point de terminaison A ; ou avec le scénario Site à Site, vous pouvez exécuter ping 192.168.1.11 sur le Point de terminaison B et voir des réponses provenant du Point de terminaison A (et bien que vous ne puissiez pas pinger le Point de terminaison A depuis le Point de terminaison B avec le scénario Point à Site en raison de NAT, vous pourriez toujours pinger le Point de terminaison A depuis le Hôte β).
C’est parce que UFW permet toujours certains types de paquets ICMP à travers le pare-feu qu’il crée, y compris les types de paquets ICMP utilisés par les requêtes ping (type 8, “echo request”). Donc plutôt que d’utiliser ping pour vérifier votre pare-feu, essayez de vous connecter aux ports spécifiques que votre pare-feu permet ou refuse.
Si vous cherchez un outil général pour essayer de vous connecter à divers ports, essayez Nmap. Par exemple, pour tester si le port TCP 8080 est accessible sur 10.0.0.1, exécutez ceci :
sudo nmap -Pn -n -sS --reason -p8080 10.0.0.1
Pour tester si le port UDP 51821 est accessible sur 192.168.1.11, exécutez la commande suivante :
sudo nmap -Pn -n -sU --reason -p51821 192.168.1.11
Le comportement d’UFW qui permet indifféremment les paquets ICMP echo-request transférés est
Une faiblesse de sécurité mineure en matière d’exposition d’informations peut permettre à un attaquant tentant de scanner votre réseau de découvrir l’existence d’autres hôtes qui ne seraient autrement pas visibles pour l’attaquant. Si c’est un problème pour votre posture de sécurité, éditez le fichier /etc/ufw/before.rules sur vos hôtes et commentez la ligne suivante (ajoutez un # au début) :
#-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT
Pour les hôtes accessibles via IPv6, éditez également le fichier /etc/ufw/before6.rules, et commentez ces lignes :
#-A ufw6-before-forward -p icmpv6 --icmpv6-type echo-request -j ACCEPT
#-A ufw6-before-forward -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
Si vous souhaitez continuer à autoriser les ping sur les connexions transférées pour certains hôtes sélectionnés, remplacez chaque ligne commentée par une ligne pour chaque hôte que vous souhaitez toujours pouvoir ping. Spécifiez le drapeau -d (aka --destination) sur chaque ligne avec l’adresse de l’hôte à autoriser. Par exemple, dans le scénario Hub and Spoke, pour permettre à Endpoint B (10.0.0.2) de continuer à être pingé via Host C (tandis que d’autres hôtes, comme Endpoint A, ne peuvent pas être pingés), mettez à jour le fichier /etc/ufw/before.rules sur Host C pour commenter la première ligne (ou simplement la supprimer) et ajoutez la deuxième ligne pour remplacer celle-ci :
#-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -d 10.0.0.2 -j ACCEPT
Redémarrez UFW avec la commande sudo systemctl restart ufw pour mettre vos modifications en œuvre.
Dépannage
Tcpdump
Tcpdump peut être vraiment utile pour dépanner les problèmes de pare-feu — vous pouvez l’utiliser pour déterminer si les paquets transitent comme prévu d’un hôte donné. Par exemple, avec le scénario Site à Site, si vous ne voyez aucune sortie lorsque vous essayez de vous connecter de l’Endpoint A à l’Endpoint B (c’est-à-dire en exécutant curl 192.168.200.22), essayez d’exécuter la commande suivante sur chaque hôte le long du chemin entre l’Endpoint A et l’Endpoint B (c’est-à-dire l’Endpoint A, l’Hôte α, l’Hôte β et l’Endpoint B) :
$ sudo tcpdump -ni any 'tcp port 80 and host 192.168.200.22'
Tandis que ces commandes s’exécutent, essayez de vous connecter à nouveau de l’Endpoint A à l’Endpoint B. Vous devriez voir chaque terminal exécutant tcpdump imprimer une série de lignes qui ressemblent à celles-ci :
22:12:16.156120 IP 192.168.1.11.36112 > 192.168.200.22.80: Flags [S], seq 767605079, win 62167, options [mss 8881,sackOK,TS val 1689421470 ecr 0,nop,wscale 6], length 0
22:12:16.157801 IP 192.168.200.22.80 > 192.168.1.11.36112: Flags [S.], seq 3979107600, ack 767605080, win 62083, options [mss 8881,sackOK,TS val 3921390190 ecr 1689421470,nop,wscale 6], length 0
22:12:16.158587 IP 192.168.1.11.36112 > 192.168.200.22.80: Flags [.], ack 1, win 972, options [nop,nop,TS val 1689421475 ecr 3921390190], length 0
22:12:16.158637 IP 192.168.1.11.36112 > 192.168.200.22.80: Flags [P.], seq 1:78, ack 1, win 972, options [nop,nop,TS val 1689421475 ecr 3921390190], length 77: HTTP: GET / HTTP/1.1
22:12:16.158755 IP 192.168.200.22.80 > 192.168.1.11.36112: Flags [.], ack 78, win 969, options [nop,nop,TS val 3921390191 ecr 1689421475], length 0
Les lignes avec 192.168.1.11.36112 > 192.168.200.22.80 représentent des paquets envoyés vers le Point de terminaison B sur le port TCP 80, et les lignes avec 192.168.200.22.80 > 192.168.1.11.36112 représentent des paquets envoyés de retour du Point de terminaison B en réponse. Si la commande tcpdump sur un hôte ne produit que des lignes avec le premier type et aucune avec le second, cela signifie que seuls les paquets envoyés vers le Point de terminaison B atteignent l’hôte — aucun paquet n’est reçu en retour.
Est en retour du Point de terminaison B. Si la commande tcpdump sur un hôte ne produit rien, cela signifie que aucun paquet ne parvient à l’hôte, même ceux de la première partie du voyage vers le Point de terminaison B.
Iptables
Si vos règles UFW ne se comportent pas comme vous le souhaitez, il est possible que vous ayez également d’autres règles iptables en vigueur, à l’extérieur des règles générées par UFW. Essayez d’exécuter sudo iptables-save pour lister toutes vos règles iptables.
Ceci est ce que vous devriez voir avec un pare-feu UFW vide (pour la version 0.36 de UFW) :
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32
```markdown
-p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
Toutes les règles non listées ci-dessus (et ne commençant pas par `-A ufw`) ne proviennent pas d'UFW (sauf si vous avez modifié le fichier `/etc/ufw/before.rules`, dans ce cas, vous devriez également voir ces modifications dans la sortie de `iptables-save`).
Une fois que vous ajoutez des règles UFW, vous verrez quelques règles iptables supplémentaires commençant par `-A ufw-user-forward` ou `-A ufw-user-input` listées juste au-dessus du bas de la sortie (juste au-dessus des lignes commençant par `-A ufw-user-limit`). Par exemple, dans le scénario [Point à Point](#point-to-point), une fois que vous avez configuré UFW sur le Point B, vous verrez les lignes supplémentaires suivantes listées lorsque vous exécutez `sudo iptables-save` sur le Point B :
```bash
-A ufw-user-input -s 10.0.0.1/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 51822 -j ACCEPT
-A ufw-user-input -i wg0 -p tcp -m tcp --dport 80 -j ACCEPT
En tant qu’autre exemple, avec le scénario Hub et Spoke, une fois que vous avez configuré l’Hôte C, vous verrez les lignes supplémentaires suivantes listées lorsque vous exécutez sudo iptables-save sur l’Hôte C :
-A ufw-user-forward -d 10.0.0.2/32 -i wg0 -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw-user-input -s 192.168.30.1/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 51823 -j ACCEPT
5/12/2021
par Justin Ludwig
by Justin Ludwig translated by: Patrice Le Guyader