docker pull через VPN: у демона власна мережа

Ваш ноутбук у корпоративній мережі VPN, curl доходить до внутрішнього registry, і все ж docker pull досі падає з EOF. Це поєднання не суперечність. Введена вами команда виконується у вашій оболонці, але передавання відбувається в тому демоні, який вибрав Docker CLI, і цей демон може бути на зовсім іншому хості. Працювати має саме його мережевий шлях, і застосовуються саме його налаштування проксі.

Почніть з визначення рушія, а не маршруту

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

Змінна середовища, як-от DOCKER_HOST, може тихо спрямувати CLI до іншого рушія, ніж той, який ви припускаєте, і це звичайне пояснення ноутбука, який виглядає підключеним до VPN, поки завантаження прямує кудись інде.

Демон має власну мережеву ідентичність

Віддаленому рушієві потрібен власний схвалений шлях до приватного registry. Підключення VPN-клієнта на ноутбуці дає маршрут цьому ноутбуку; воно не дає демону в лабораторії чи хмарній підмережі тієї самої приватної адреси. Якщо рушій — Docker Desktop, завантаження відбувається всередині його віртуальної машини, яка має власну конфігурацію мережі й проксі, окрему від середовища вашої оболонки.

Тому успішний curl на хості — це доказ про хост і не більше.

З'ясуйте, який обмін із registry завершився

Завантаження образу — це послідовність: автентифікація, отримання маніфесту, а потім передавання блобів, яке часто перенаправляється в об'єктне сховище або на кінцеву точку CDN. Успішний docker login доводить лише перший крок, і токен може бути цілком дійсним, поки перенаправлений хост блобів недоступний із мережі демона. Перш ніж щось змінювати, запишіть точний час, посилання на образ і першу корисну подію з журналу демона або клієнта.

Сам по собі EOF не називає причини. Це може бути обірване з'єднання, проксі, що скинув потік, тайм-аут або проблема з MTU, і вгадування між ними без події з міткою часу — це шлях, яким люди починають перебудовувати здоровий рушій. Ставтеся до байтового зсуву у виводі клієнта як до даних, бо передавання, яке щоразу зупиняється на тому самому розмірі, — зовсім інший звір, ніж те, що ніколи не починається. Запишіть обидва результати й порівняйте їх між спробами.

Налаштуйте компонент, який виконує передавання

Для нативного рушія Linux проксі належить середовищу служби, а не вашій оболонці. Файл drop-in у /etc/systemd/system/docker.service.d/ із записами HTTP_PROXY, HTTPS_PROXY і NO_PROXY, за яким ідуть systemctl daemon-reload і перезапуск, — це задокументована схема. Docker Desktop надає ті самі значення через власні налаштування, і редагування профілю оболонки не зачіпає ні те, ні те.

Якщо до registry треба доходити безпосередньо через VPN, демонові потрібні резолвер, маршрут і навмисне виключення проксі, а не лише виключення. Зіставлення NO_PROXY — це порівняння рядків для кожного компонента, і виняток без маршруту в основі дає збій, який виглядає як проблема з проксі.

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

Повторіть одне контрольоване завантаження і перевірте, що змінилося

Змініть одну межу, перезапустіть компонент, якому вона належить, і повторіть те саме завантаження з того самого контексту. Перевіряйте отримане посилання на образ і digest, а не відсутність помилки, бо кешований шар може змусити другу спробу пройти значно меншу частину шляху, ніж перша. Зберігайте в заявці ті передавання, які справді відбулися, оскільки вони — єдиний запис про те, що насправді перевірила повторна спроба.

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