docker pull via un VPN : le démon a son propre réseau

Votre ordinateur portable est sur le VPN d'entreprise, curl atteint le registre interne, et pourtant docker pull échoue toujours avec un EOF. Cette combinaison n'est pas une contradiction. La commande que vous avez tapée s'exécute dans votre shell, mais le transfert s'exécute dans le démon que la CLI Docker a sélectionné, et ce démon peut se trouver sur un hôte totalement différent. C'est son chemin réseau qui doit fonctionner, et ce sont ses réglages de proxy qui s'appliquent.

Commencez par identifier le moteur, pas la route

Lancez docker context show et docker version. La sortie de version affiche une section client et une section serveur, et le bloc serveur vous indique qui a répondu : un moteur natif local, la machine virtuelle Docker Desktop ou un démon sur une machine distante. docker context inspect affichera le point de terminaison du contexte sélectionné si vous voulez en être sûr, et aucune de ces commandes ne change quoi que ce soit.

Une variable d'environnement comme DOCKER_HOST peut silencieusement pointer la CLI vers un autre moteur que celui que vous supposez, ce qui est l'explication habituelle d'un ordinateur portable qui semble être sur le VPN alors que le pull part ailleurs.

Le démon a sa propre identité réseau

Un moteur distant a besoin de son propre chemin approuvé vers le registre privé. Connecter le client VPN de votre ordinateur portable donne une route à cet ordinateur portable ; cela ne donne pas la même adresse privée à un démon installé dans un laboratoire ou un sous-réseau cloud. Si le moteur est Docker Desktop, le pull se déroule dans sa machine virtuelle, qui possède sa propre configuration réseau et proxy, distincte de l'environnement de votre shell.

C'est pourquoi un curl réussi sur l'hôte est une preuve concernant l'hôte et rien de plus.

Déterminez quel échange avec le registre s'est terminé

Le pull d'une image est une séquence : authentification, récupération du manifeste, puis transferts de blobs souvent redirigés vers du stockage objet ou un point de terminaison CDN. Un docker login réussi ne prouve que la première étape, et un jeton peut être parfaitement valide alors que l'hôte de blobs redirigé est injoignable depuis le réseau du démon. Notez l'heure exacte, la référence de l'image et le premier événement utile du journal du démon ou du client avant de changer quoi que ce soit.

EOF seul ne nomme aucune cause. Il peut s'agir d'une connexion tronquée, d'un proxy qui a lâché le flux, d'un délai expiré ou d'un problème de MTU, et deviner entre ces possibilités sans l'événement horodaté est ainsi que l'on finit par reconstruire un moteur sain. Traitez le décalage d'octets dans la sortie du client comme une donnée, car un transfert qui s'arrête toujours à la même taille est un animal différent de celui qui ne démarre jamais. Consignez les deux résultats et comparez-les d'une tentative à l'autre.

Configurez le composant qui transfère

Pour un moteur Linux natif, le proxy appartient à l'environnement du service, pas à votre shell. Un fichier drop-in sous /etc/systemd/system/docker.service.d/ avec des entrées HTTP_PROXY, HTTPS_PROXY et NO_PROXY, suivi de systemctl daemon-reload et d'un redémarrage, constitue la disposition documentée. Docker Desktop expose les mêmes valeurs via ses propres réglages, et modifier un profil de shell ne touche ni l'un ni l'autre.

Si le registre doit être joint directement via le VPN, le démon a besoin d'un résolveur, d'une route et d'une exclusion de proxy délibérée, et pas seulement d'une exclusion. La correspondance NO_PROXY est une comparaison de chaînes par composant, et une exemption sans route sous-jacente produit un échec qui ressemble à un problème de proxy.

Lorsque l'inspection TLS d'entreprise se trouve sur le chemin approuvé, installez sa racine vérifiée via le flux du moteur ou de Desktop. Ajouter le registre à insecure-registries est une modification différente qui désactive la validation, et ce n'est pas une configuration de magasin de confiance.

Répétez un pull contrôlé et vérifiez ce qui a changé

Changez une frontière, redémarrez le composant qui la possède et répétez le même pull depuis le même contexte. Vérifiez la référence d'image et le digest obtenus plutôt que l'absence d'erreur, car une couche mise en cache peut faire qu'une seconde tentative parcourt bien moins du chemin que la première. Conservez dans le ticket les transferts qui ont réellement eu lieu, car ils sont la seule trace de ce que la nouvelle tentative a vraiment testé.

Les étapes de build et les conteneurs en cours d'exécution ont leurs propres contextes réseau, alors traitez-les comme des questions distinctes une fois le pull lui-même fonctionnel.