Publication de ports Docker et sources VPN : deux correspondances que vous ratez

La règle dit d’autoriser l’adresse du serveur VPN vers le service publié, et la connexion tombe quand même. Ce résultat est courant et ce n’est pas un bug de Docker. Deux correspondances distinctes sont fausses : la source que vous avez écrite n’est peut-être pas celle que l’hôte reçoit, et le port que vous avez écrit n’est peut-être pas celui que le filtre voit. Corriger les deux exige de regarder le chemin du paquet plutôt que le schéma du service.

Le mythe : autorisez le serveur VPN et c’est fini

Un VPN routé peut conserver l’adresse du tunnel du client jusqu’à l’hôte Docker. Une passerelle qui effectue une traduction de source peut remplacer cette adresse par la sienne. Les deux conceptions sont légitimes, et elles produisent des sources différentes pour la même action utilisateur.

La formule IP du serveur VPN décrit donc une supposition, pas une observation. Tant que vous ne savez pas laquelle des deux conceptions est devant vous, la règle est une conjecture.

Source : pool de clients ou passerelle traduite

Vérifiez quatre choses dans l’ordre. Premièrement, le pool d’adresses clients, par exemple 10.90.0.0/24. Deuxièmement, si la passerelle traduit ce pool avant qu’il atteigne l’hôte. Troisièmement, la source que l’hôte observe réellement pour une nouvelle connexion. Quatrièmement, si l’authentification de l’application distingue les utilisateurs individuels, car une adresse traduite partagée ne le peut pas.

Si le pool est préservé, une règle qui ne correspond qu’à l’adresse publique de la passerelle manque tous les clients. Si la passerelle traduit délibérément, autoriser l’adresse traduite admet tous les utilisateurs derrière elle, ce qui peut être acceptable pour un service doté de sa propre connexion et inacceptable pour tout le reste.

Port : le DNAT change le numéro que vous ciblez

Dans la publication habituelle par pont Linux avec iptables de Docker, une correspondance d’hôte de 8443 vers le port 443 du conteneur est traduite avant que le filtre de transfert ne s’exécute. Le paquet arrive au filtre avec le port de destination 443. Une règle qui correspond à 8443 à cet endroit ne se déclenche jamais, même si 8443 est ce que le client a saisi.

Le port publié existe toujours dans le suivi des connexions, c’est pourquoi la destination d’origine peut y être mise en correspondance quand vous en avez vraiment besoin.

Décidez quel numéro exprime l’intention. Ciblez le port du conteneur après DNAT lorsque la règle protège le service à l’intérieur du conteneur. Ciblez la destination d’origine avec l’option conntrack lorsque la règle doit décrire ce que le client a demandé, et acceptez le coût de correspondance supplémentaire et le soin apporté à l’ordre des règles qui vont avec.

Chaîne : DOCKER-USER, pas INPUT

Le guide iptables de Docker place la politique de transfert utilisateur dans la chaîne DOCKER-USER, qui est évaluée avant les propres règles de transfert de Docker. Une règle copiée d’un service de l’hôte vers la chaîne INPUT filtre le trafic adressé à l’hôte, pas le trafic transféré vers un conteneur. Cette erreur produit une règle qui semble correcte et n’a aucun effet sur le chemin du conteneur.

Gardez la plage source, le port de destination effectif, le protocole et l’interface d’entrée ensemble dans la même règle. Une autorisation fondée uniquement sur la source pour chaque destination transférée est plus large que l’autorisation d’un seul service publié.

Vérifiez avec des connexions neuves

Testez les deux sens avec de nouvelles connexions : un client VPN autorisé et une source qui doit rester refusée. L’état de connexion existant peut maintenir une session en vie après un changement de politique, donc une ancienne connexion ne prouve rien sur la nouvelle règle. Vérifiez ensuite le chemin de retour, car le conteneur doit encore router vers la source qu’il voit.

Le guide iptables de Docker documente l’ordre des chaînes et le comportement de traduction de ports derrière ces vérifications. Lisez-le avant de copier une recette, et confirmez quel backend le Docker installé utilise, car le backend nftables intègre la politique différemment.