Espaces de noms réseau Linux pour un VPN : ce qu’ils n’isolent pas

Démarrez le VPN dans son propre espace de noms, exécutez-y une application, et le trafic sort quand même par la route de l’hôte. Rien n’est cassé : l’espace de noms ne gouverne que les processus qui y entrent, et la fuite venait d’un processus qui n’y est jamais entré. Interfaces, adresses, routes, règles de pare-feu et sockets sont ce que l’espace de noms possède. Les fichiers, les comptes et les services déjà en cours d’exécution ne le sont pas, et c’est de là que viennent la plupart des surprises.

Ce que l’espace de noms possède, et où le socket naît

Déplacez une interface dans un espace de noms et l’hôte la perd ; construisez-y un tunnel et l’hôte ne peut pas le voir. C’est le mécanisme d’un VPN limité à un espace de noms : l’appareil et les routes qui pointent vers lui vivent dans un contexte que seuls les processus choisis atteignent. L’hôte conserve sa route par défaut, donc tout ce qui est dehors reste intact.

Pour WireGuard, le contexte de création compte autant que l’emplacement actuel : le socket UDP est lié dans l’espace de noms où l’interface a été créée, même après que l’appareil a déménagé ailleurs. La table de routage que suivent les paquets chiffrés dépend de ce lieu de naissance. Quand le socket reste dans un contexte sans route vers le pair, l’interface consulte et la poignée de main ne sort jamais. Vérifiez son lieu de naissance, puis son emplacement actuel.

Ce qu’un espace de noms n’isole pas

Rien ici ne sépare les systèmes de fichiers, les comptes ou les secrets, et aucune de ces frontières n’apparaît parce que vous avez créé un espace de noms. La configuration du résolveur est un fichier, donc un processus à l’intérieur peut encore lire un réglage qui pointe vers le résolveur de l’hôte et envoyer sa requête par la route que cela implique. Une application qui remet la requête à un intermédiaire ou à un service système déjà en cours implique un processus dans un contexte entièrement différent. Les deux sont des requêtes auxquelles la frontière n’a jamais été censée répondre.

La solution est un fichier par espace de noms dans /etc/netns/<name>/resolv.conf, ou un bind mount d’un fichier préparé, pointé vers un résolveur joignable de l’intérieur. Modifier /etc/resolv.conf sur l’hôte ne change rien de ce que l’espace de noms voit.

Le placement des processus est le contrôle

L’isolement que vous obtenez est exactement celui des processus que vous démarrez à l’intérieur. Un shell lancé via l’assistant exec de l’espace de noms, et tout ce qu’il engendre, reste dedans ; une application de bureau lancée depuis la session de l’hôte, non. Créez le contexte, déplacez l’appareil, puis prouvez les deux côtés :

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

Lisez le premier wg show depuis l’intérieur de l’espace de noms et le second depuis l’hôte, et attendez-vous à ce qu’un seul des deux liste le pair. Si les deux le font, l’appareil n’a jamais bougé ; si aucun ne le fait, il est allé ailleurs. Quand le lanceur est un gestionnaire de services, c’est le fichier d’unité qu’il faut modifier, pas le raccourci du bureau. Une unité sans le réglage d’espace de noms démarre le démon dans le contexte de l’hôte et annule discrètement la conception.

Testez depuis le contexte de l’application

Exécutez la vérification avec le même binaire et le même utilisateur que l’application, à l’intérieur de l’espace de noms. Incluez le DNS et les deux familles d’adresses, car une route IPv6 que vous n’avez jamais envisagée est une sortie courante. Un test depuis votre propre shell ne prouve qu’une chose : que votre shell est isolé.

Exécutez ensuite la vérification identique sur l’hôte et confirmez que les réponses diffèrent : adresse du tunnel et sortie prévue dedans, route de l’hôte et sortie du bureau dehors, et le résolveur par nom. Nommez les espaces de noms d’après le déploiement plutôt que le protocole, pour qu’un script de nettoyage n’en confonde pas deux.

Transfert, politique de panne et nettoyage

Pour une passerelle, activez le transfert délibérément et décidez de ce qui doit se passer quand le tunnel tombe. Un espace de noms ne bloque pas les routes que vous y installez, donc une route de secours vers l’hôte sera utilisée si vous en créez une. C’est une décision de politique, et elle devrait être écrite avant qu’une panne ne la mette à l’épreuve.

Notez les noms des espaces de noms, les interfaces et le propriétaire de la configuration, pour que le nettoyage ne retire que ce que le déploiement a créé. Réinitialiser le réseau de l’hôte pendant un retour arrière transforme un nettoyage en panne. La page network_namespaces(7) est courte et mérite d’être lue avant de concevoir ce chemin.