docker pull през VPN: daemon има собствена мрежа

Лаптопът ви е в корпоративния VPN, curl достига вътрешния registry, а docker pull все още умира с EOF. Тази комбинация не е противоречие. Командата, която сте въвели, работи във вашия shell, но трансферът се изпълнява в онзи daemon, който Docker CLI е избрал, и този daemon може да е на напълно друг хост. Неговият мрежов път е този, който трябва да работи, и неговите настройки за proxy са тези, които се прилагат.

Започнете с идентифициране на машината, а не на маршрута

Изпълнете docker context show и docker version. Изходът на версията отпечатва секция за клиента и секция за сървъра, а блокът на сървъра ви казва кой е отговорил: локална нативна машина, виртуалната машина на Docker Desktop или daemon на отдалечена машина. docker context inspect ще покаже крайната точка на избрания контекст, ако искате да сте сигурни, и нито една от тези команди не променя нищо.

Променлива на средата като DOCKER_HOST може тихо да насочи CLI към друга машина, различна от тази, която предполагате, което е обичайното обяснение за лаптоп, който изглежда във VPN, докато дърпането отива другаде.

Daemon има собствена мрежова идентичност

Отдалечената машина се нуждае от собствен одобрен път до частния registry. Свързването на VPN клиента на лаптопа дава на този лаптоп маршрут; то не дава на daemon в лаборатория или облачна подмрежа същия частен адрес. Ако машината е Docker Desktop, дърпането се извършва във виртуалната му машина, която има собствена мрежова и proxy конфигурация, отделна от средата на вашия shell.

Ето защо успешен curl на хоста е доказателство за хоста и нищо повече.

Открийте кой обмен с registry е приключил

Дърпането на образ е последователност: удостоверяване, извличане на манифеста, след това трансфери на blob, които често се пренасочват към обектно хранилище или крайна точка на CDN. Успешен docker login доказва само първата стъпка и токенът може да е напълно валиден, докато пренасоченият хост за blob е недостъпен от мрежата на daemon. Запишете точния час, референцията на образа и първото полезно събитие от журнала на daemon или клиента, преди да промените нещо.

EOF сам по себе си не посочва причина. Това може да е прекъсната връзка, proxy, който е изпуснал потока, изтичане на времето или проблем с MTU, и гадането между тях без събитие с времева марка е начинът, по който хората преустройват здрава машина. Третирайте байтовото отместване в изхода на клиента като данни, защото трансфер, който спира на един и същ размер всеки път, е съвсем различно нещо от такъв, който никога не започва. Запишете и двата резултата и ги сравнете между опитите.

Конфигурирайте компонента, който извършва трансфера

За нативна Linux машина proxy принадлежи в средата на услугата, а не във вашия shell. Drop-in файл под /etc/systemd/system/docker.service.d/ с записи HTTP_PROXY, HTTPS_PROXY и NO_PROXY, последван от systemctl daemon-reload и рестарт, е документираната схема. Docker Desktop предоставя същите стойности чрез собствените си настройки и редактирането на профил на shell не засяга нито една от тях.

Ако registry трябва да се достига директно през VPN, на daemon са нужни resolver, маршрут и умишлено изключване на proxy, а не само изключване. Съпоставянето на NO_PROXY е сравнение на низове за всеки компонент и изключение без подлежащ маршрут дава отказ, който изглежда като проблем с proxy.

Когато корпоративната TLS инспекция е на одобрения път, инсталирайте нейния проверен корен чрез работния процес на машината или Desktop. Добавянето на registry към insecure-registries е друга промяна, която изключва валидирането, и не е конфигурация на хранилище за доверие.

Повторете едно контролирано дърпане и проверете какво се е променило

Променете една граница, рестартирайте компонента, който я притежава, и повторете същото дърпане от същия контекст. Проверете получената референция на образа и digest, а не отсъствието на грешка, защото кеширан слой може да накара втория опит да изпита много по-малка част от пътя, отколкото първият. Пазете в тикета трансферите, които действително са се случили, тъй като те са единственият запис какво наистина е тествал повторният опит.

Стъпките за изграждане и работещите контейнери имат свои собствени мрежови контексти, затова ги третирайте като отделни въпроси, след като самото дърпане работи.