Kill switch pour un sidecar VPN : bloquer le trafic à son arrêt

Un conteneur d’application qui partage l’espace de noms réseau d’un conteneur VPN n’a pas d’interface propre, il est donc tentant de supposer qu’il ne peut rien envoyer lorsque le tunnel échoue. Cette hypothèse est fausse dans le mode de défaillance qui compte. Si le processus VPN meurt alors que l’espace de noms survit, l’application conserve ses sockets et l’espace de noms conserve ses routes, et le trafic continue sur le chemin encore installé. Un vrai kill switch est une politique de filtrage explicite accompagnée de tests du cycle de vie du runtime, pas une dépendance au démarrage.

Pourquoi le partage d’espace de noms n’est pas un kill switch

Partager un espace de noms signifie que l’application utilise les interfaces, les adresses et la table de routage du conteneur VPN. Cela supprime le chemin indépendant de l’application vers le réseau tant que l’espace de noms partagé est intact, et cela ne dit rien de ce que cet espace de noms fera lorsque le tunnel disparaîtra.

Les conditions de dépendance de Compose peuvent retarder le démarrage d’une application jusqu’à ce qu’une dépendance soit saine. Cela ne couvre qu’un instant précis et aucune défaillance ultérieure, c’est donc un outil d’ordonnancement du démarrage et non un pare-feu de sortie continu.

Ce qui se passe réellement lorsque le conteneur s’arrête

Distinguez trois événements. Le processus VPN à l’intérieur du conteneur peut mourir alors que le conteneur continue de tourner. Le conteneur peut s’arrêter ou être supprimé, ce qui détruit l’espace de noms. Le conteneur peut être recréé, ce qui construit un nouvel espace de noms et de nouvelles règles.

Dans le premier cas l’espace de noms persiste, la route par défaut peut toujours pointer vers l’interface physique, et l’application continue d’envoyer directement. Dans le second cas l’application dépendante perd généralement toute connectivité, parce que son espace de noms a disparu. Dans le troisième cas l’application peut se reconnecter à un espace de noms neuf avant que le tunnel soit prêt. Chaque cas exige un test différent, et une conception qui ne couvre que la déconnexion ordonnée couvre le cas le moins intéressant.

Construire une politique de sortie explicite

Écrivez la politique à l’intérieur de l’espace de noms partagé pour qu’elle s’applique aux paquets de l’application. La forme est un rejet par défaut avec des exceptions étroites : loopback, l’interface du tunnel, et l’adresse et le port précis du point de terminaison dont le transport du tunnel a besoin.

L’exception du point de terminaison doit être en place avant que le tunnel monte, sinon le client VPN ne peut pas joindre son serveur. C’est pourquoi le jeu de règles autorise explicitement le transport extérieur au lieu d’autoriser l’interface physique en général. Ajoutez aussi des règles IPv6 si l’espace de noms dispose d’une connectivité IPv6, car une politique limitée à IPv4 laisse l’autre famille ouverte.

Le DNS fait aussi partie de la politique. Si l’application résout des noms via un résolveur accessible uniquement à l’intérieur du tunnel, la règle de rejet cassera la résolution lorsque le tunnel sera en panne, ce qui est le comportement correct pour un kill switch. Décidez délibérément si c’est ce que vous voulez.

Tester le cycle de vie, pas seulement la déconnexion

Envoyez une requête neuve et inoffensive pendant que le tunnel est sain, puis tuez le processus VPN et envoyez-en une autre. Répétez après un arrêt du conteneur, après un redémarrage et après une recréation. Une requête neuve compte parce qu’une connexion existante peut survivre à un changement de règles qui bloque les nouvelles.

Ne comptez pas sur un contrôle de santé ni sur une recherche d’IP de sortie comme mécanisme de blocage. Un contrôle observe l’état et le rapporte ; une politique contrôle le trafic. Les deux appartiennent au même déploiement, et ils ne sont pas interchangeables.

Consigner les règles pour que le test survive à une mise à jour

Écrivez le résultat attendu de chaque cas de défaillance dans la documentation de déploiement, avec les règles qui l’implémentent. Cette trace permet de rejouer le même test après une mise à jour d’image ou du runtime, lorsque le comportement de l’espace de noms ou les routes par défaut peuvent changer sans que personne n’édite le fichier Compose.

Gardez le chemin extérieur requis du point de terminaison VPN séparé de la sortie applicative non restreinte, et gardez le DNS et l’IPv6 dans la couverture prévue. Si la politique autorise toute l’interface physique pour des raisons de commodité, le kill switch a disparu. La documentation réseau de Docker décrit l’agencement d’espace de noms partagé sur lequel la politique repose, et c’est la référence à consulter lorsque le comportement du runtime est en doute.