Publication de ports Docker face au VPN : où part la réponse

Un conteneur publié répond depuis sa propre adresse avant le NAT inverse. Deux conceptions peuvent maintenir cette réponse sur le chemin public, à des coûts différents.

L'hôte continue de répondre en SSH après la montée d'un VPN en tunnel complet, tandis qu'un service publié par Docker sur la même machine devient muet. Rien ne cloche dans l'écoute : le conteneur tourne, la redirection de port existe et le paquet arrive. Le conteneur est sain et la requête l'atteint bien. Ce qui diffère, c'est l'endroit d'où part la réponse lorsque Linux choisit sa route, et cette différence décide laquelle des deux conceptions ci-dessous vous est nécessaire.

Suivez le tuple à travers le NAT de destination

Prenez un hôte à 192.0.2.10 qui publie TCP 2222 vers un conteneur à 172.30.240.5:22. Une requête depuis 198.51.100.25 est traduite avant d'atteindre le conteneur, et le conteneur répond en son nom propre.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Lors de la décision de routage de l'hôte, la réponse porte encore l'adresse source du conteneur. La traduction inverse rétablit plus tard le tuple publié, et c'est pourquoi le paquet paraît faux exactement au moment où la route est choisie.

Pourquoi une règle limitée à l'hôte la manque

Une règle qui sélectionne la table WAN uniquement pour les paquets provenant de 192.0.2.10 couvre les démons de l'hôte et manque entièrement cette réponse transférée. L'adresse source de la réponse est 172.30.240.5, pas celle de l'hôte.

La surcorrection consiste à router tout le trafic du conteneur par le WAN, ce qui exempte aussi du VPN les connexions sortantes sans rapport du conteneur. C'est une politique différente de celle demandée, et cela surprend généralement quelqu'un plus tard.

La correspondance après DNAT est un autre hook

La documentation Docker sur les pare-feu note que le filtrage utilisateur ordinaire voit la destination après le DNAT, donc faire correspondre le port publié 2222 dans une règle normale n'équivaut pas à faire correspondre le port 22 du conteneur. Si le tuple d'origine compte, utilisez le mécanisme de destination d'origine pris en charge plutôt que de deviner quel port est visible.

Cette confusion de hooks produit des règles qui semblent correctes et ne correspondent jamais. Vérifiez les compteurs de la règle elle-même avant de réécrire la politique. Une règle sans aucun comptage vous dit qu'elle est évaluée à un endroit où le paquet n'arrive jamais.

Conception A : porter la décision comme état de connexion

Une marque de connexion peut porter la décision d'entrée à travers la traduction, mais elle doit être restaurée sur le paquet avant la recherche de route qui compte. Les étapes sont les suivantes :

  1. Réservez un champ de marque et une priorité de règle qui n'entrent en collision ni avec Docker, ni avec le VPN, ni avec un autre propriétaire de politique.
  2. Identifiez uniquement la nouvelle connexion WAN visée à un point situé avant le DNAT, là où le suivi des connexions est disponible.
  3. Enregistrez la décision sur la marque de connexion, sans forcer la requête d'origine elle-même vers la table WAN.
  4. Dans la direction de la réponse, restaurez uniquement vos propres bits de marque sur le paquet avant le routage.
  5. Sélectionnez une table WAN complète assez tôt pour qu'une règle VPN ne puisse pas gagner en premier.

Cette table a besoin des vraies routes connectées et de la passerelle. Elle a aussi besoin d'un comportement défini lorsque la route manque. Une retombée silencieuse dans le tunnel est le pire résultat, car la configuration continue de sembler fonctionner. Échouez fermé et journalisez-le à la place.

Conception B : terminer sur l'hôte

Un frontal configuré délibérément côté hôte, comme un proxy TCP ou un proxy inverse devant le conteneur, maintient la réponse provenant de l'adresse de l'hôte. Les règles écrites pour l'hôte se comportent alors comme prévu, et le conteneur reste sur son réseau privé.

Le coût est une pièce mobile de plus, avec sa propre configuration, la gestion de l'adresse source et des contrôles d'accès. C'est généralement la limite prise en charge la plus simple, et c'est souvent la bonne réponse lorsque la politique de routage serait maintenue par une seule personne susceptible de partir.

Vérifiez le changement, pas l'intention

Ouvrez une nouvelle connexion autorisée depuis le côté public et confirmez que la réponse sort par l'interface prévue. Vérifiez ensuite qu'une requête sans rapport lancée par le conteneur suit toujours le VPN.

Ne videz pas la table de connexions de la machine pour tester une règle : les entrées existantes gardent leur mappage antérieur, et le vidage casse tout le reste sur l'hôte. Publier un port définit la joignabilité. Cela ne définit pas le chemin de la réponse. Écrivez la conception retenue avec ses noms de table, afin que la personne suivante ne la redécouvre pas pendant un incident.

Articles similaires