Conteneurs Windows et VPN : pourquoi le réseau local casse
Un conteneur Windows emprunte la table de routage de l'hôte, donc un VPN qui bloque le sous-réseau local emporte le préfixe du conteneur. Le mode Linux prend un autre chemin.
Sur un seul portable, avec un seul client VPN connecté, les conteneurs Linux continuent de communiquer entre eux et les conteneurs Windows s'arrêtent. La variable n'est pas l'image, mais le chemin que prennent les paquets vers l'hôte. Les conteneurs Windows sur le réseau par défaut empruntent la table de routage et la traduction de l'hôte, donc une politique qui change le routage de l'hôte les change aussi. Confirmez-le par une recherche de route avant de réinstaller quoi que ce soit.
Où les paquets d'un conteneur Windows entrent dans l'hôte
Un conteneur sur le réseau par défaut nat obtient une adresse à partir d'un préfixe du service Host Networking Service, généralement quelque part dans 172.16.0.0/12, et atteint l'hôte par un adaptateur virtuel. L'hôte possède la route de ce préfixe et traduit le trafic vers l'adaptateur actif. Il n'y a pas de machine virtuelle séparée au milieu de ce chemin.
C'est cette conception qui rend la panne mécanique. Quand le conteneur envoie un paquet, l'hôte effectue une recherche de route pour le préfixe du conteneur. La route qui gagne est celle où va le paquet, et le conteneur n'a pas d'avis là-dessus.
Ce que le client VPN change sur ce chemin
Un client d'entreprise installe souvent un large jeu de routes et un filtre qui refuse l'accès au sous-réseau local tant que le tunnel est actif. L'intention est défensive : un réseau local compromis ne doit pas atteindre une machine protégée. L'effet secondaire est que la route de l'hôte vers le préfixe du conteneur n'est plus le réseau NAT local.
À la place, la recherche correspond au tunnel et le paquet est remis à la passerelle, qui n'a jamais entendu parler de cette adresse de conteneur. Le ping échoue, l'application expire et le conteneur semble cassé pendant que l'icône du VPN brille. Regardez la table de l'hôte pendant la connexion et la route concurrente est visible.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Pourquoi les conteneurs Linux se comportent autrement
Le moteur Linux exécute les conteneurs dans une machine virtuelle légère, et les connexions sortantes de cette machine sont ouvertes par un proxy côté hôte pour le compte du conteneur. C'est l'hôte qui initie la socket, donc la règle du VPN sur le préfixe du conteneur ne s'y applique pas de la même façon, et la charge de travail continue d'atteindre le réseau.
Cette différence explique aussi pourquoi les recettes Linux ne se transposent pas. Un conteneur Linux qui a besoin de son propre tunnel reçoit un périphérique TUN plus la capacité NET_ADMIN. Les conteneurs Windows n'exposent aucune interface comme périphérique, donc ce schéma n'a pas d'équivalent de ce côté.
Prouvez la route, puis choisissez une conception
Recueillez les preuves depuis l'hôte, pas depuis le conteneur, car c'est l'hôte qui effectue la recherche :
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Exécutez la sortie des routes une fois avant que le VPN se connecte et une fois après. Si, dans la seconde sortie, le préfixe du conteneur pointe vers l'adaptateur du tunnel, le diagnostic est complet et redémarrer les conteneurs n'aidera pas.
La première option est une décision de politique : demandez au propriétaire du réseau si l'accès au LAN local peut être autorisé pour cet appareil. Plusieurs clients d'entreprise l'exposent comme un réglage, mais cela affaiblit une frontière délibérée. Demandez-le comme une exception documentée avec un propriétaire et une date de revue. Un interrupteur par appareil que personne ne revient consulter, voilà comment une politique défensive disparaît en silence.
Là où la politique doit tenir, déplacez la charge de travail au lieu de lutter contre la route. Un réseau transparent avec un sous-réseau et une passerelle explicites place les conteneurs sur la liaison locale, une charge de travail Linux tourne derrière le proxy de la machine virtuelle, et une machine virtuelle séparée avec son propre client conserve sa propre politique. Choisissez-en une délibérément et testez-la depuis l'intérieur du conteneur, car c'est là que la requête de l'utilisateur prend naissance.