Testez le routage VPN dans des espaces de noms sans toucher aux routes de l’hôte

Deux laboratoires peuvent modéliser la même topologie VPN et échouer de manières complètement différentes : l’un vit dans des espaces de noms réseau, l’autre sur les routes propres à l’hôte. La version avec espaces de noms conserve chaque interface, route et socket dans un contexte que vous pouvez supprimer, tandis que la version sur l’hôte démarre plus vite et laisse de l’état derrière elle. Cet état résiduel est la raison pour laquelle le second laboratoire est difficile à reproduire un mois plus tard. Comparez d’abord le nettoyage, car il décide si vous pouvez exécuter l’expérience deux fois.

Deux façons de construire le même laboratoire, et quand chacune l’emporte

Dans un laboratoire de routes d’hôte, vous ajoutez une interface de tunnel et des routes à la machine sur laquelle vous travaillez, si bien que l’expérience partage le sort de votre shell, de votre gestionnaire de paquets et de toute autre connexion. Dans un laboratoire d’espaces de noms, chaque rôle reçoit sa propre pile d’interfaces, d’adresses, de routes et de sockets, et supprimer l’espace de noms retire tout cela. Aucun des deux modèles n’est plus correct, car ils répondent à des questions différentes. Choisissez les espaces de noms quand le sujet est le routage et le transfert, et un laboratoire sur l’hôte quand le sujet est la façon dont un client de bureau s’intègre.

Mélanger les deux est l’erreur habituelle : un laboratoire d’espaces de noms testé contre un client uniquement sur l’hôte ne prouve rien sur l’une ou l’autre des dispositions. Décidez quelle question vous posez avant de créer le premier lien.

Un contexte par rôle, relié à dessein

Créez un espace de noms par rôle et déplacez chaque extrémité de chaque paire veth dans le contexte qui la possède. Les quatre premières commandes suffisent pour voir la forme :

ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns client

Donnez au laboratoire des plages qui ne chevauchent rien sur l’hôte, et notez avant de commencer quel espace de noms possède quelle adresse. Un laboratoire qui fonctionne a besoin de deux chemins distincts : un extérieur pour que le point de terminaison VPN atteigne son homologue, et un chemin de retour pour la ressource protégée. Modélisez-les comme deux décisions, car un laboratoire qui ne construit que la moitié sortante réussit un test de poignée de main et échoue à un test d’application.

Le rôle de transfert est là où les laboratoires deviennent intéressants

Un rôle doit transférer, ce qui signifie activer le transfert à l’intérieur de cet espace de noms et ajouter la règle dont la conception a besoin. L’état de transfert est par espace de noms, donc le réglage de l’hôte est sans importance pour le laboratoire et le réglage du laboratoire ne fuit pas vers l’extérieur, comme le décrit la documentation sur les espaces de noms réseau. WireGuard documente qu’une interface et son socket extérieur peuvent vivre dans des espaces de noms différents, ce qui est une astuce utile et une excellente façon de vous embrouiller. Ne supposez pas que déplacer une interface déplace chaque partie de la connexion de la même manière.

Vérifiez le compteur de transfert après un paquet de test, car une règle qui n’a jamais correspondu et une règle qui a rejeté le paquet semblent identiques dans la table de routage. Seuls les compteurs les séparent.

Enregistrez une référence, puis cassez une route

Commencez par enregistrer ce qui existe, avec le contexte écrit à côté de chaque ligne. Lisez les espaces de noms, puis la route qu’une destination de test emprunterait à l’intérieur de l’un d’eux, puis les compteurs sur le lien qui la transporte :

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

La troisième commande est celle que les gens sautent, et c’est là que vivent les preuves : les compteurs de paquets rejetés et d’erreurs vous disent si un paquet a même atteint le rôle de transfert. Capturez les trois mêmes vues après un changement, et laissez le diff être la preuve plutôt que votre souvenir. Cassez ensuite exactement une chose, soit en supprimant une route, soit en ajoutant une règle de refus sur le chemin de transfert, et confirmez le symptôme que vous aviez prédit : une poignée de main terminée sans réponse, ou un échec de résolution au lieu d’un délai d’attente. Un laboratoire qui ne démontre que le succès enseigne très peu.

Le nettoyage est ce qui rend la prochaine exécution reproductible

Gardez le nettoyage limité aux ressources que vous avez nommées, car une réinitialisation générale du pare-feu ou la suppression d’une route de l’hôte n’est pas de la reproductibilité, c’est un second incident. Enregistrez la topologie, les commandes exactes et les observations que vous attendiez, afin que la prochaine exécution reproduise la même défaillance au lieu de deviner quel contexte détenait l’état précédent. Sans cet enregistrement, le laboratoire est une histoire et non une procédure.

Utilisez des identifiants générés localement pour le laboratoire et tenez les comptes de production hors des exemples partagés. Supprimez ensuite chaque espace de noms et confirmez que la vue de l’hôte est inchangée, ce qui est toute la raison de choisir ce modèle. Un laboratoire que vous ne pouvez pas retirer proprement est une modification de l’hôte avec des étapes en plus.