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, а не адсутнасць памылкі, бо кэшаваны слай можа прымусіць другую спробу задзейнічаць значна меншую частку шляху, чым першая. Захоўвайце ў заяўцы перадачы, якія фактычна адбыліся, бо гэта адзіны запіс таго, што насамрэч правярала паўторная спроба.

Крокі зборкі і запушчаныя кантэйнеры маюць уласныя сеткавыя кантэксты, таму разглядайце іх як асобныя пытанні, калі сама загрузка ўжо працуе.