docker pull tramite VPN: il demone ha la propria rete

Il tuo portatile è sulla VPN aziendale, curl raggiunge il registry interno eppure docker pull continua a fallire con un EOF. Questa combinazione non è una contraddizione. Il comando che hai digitato viene eseguito nella tua shell, ma il trasferimento avviene nel demone che la CLI di Docker ha selezionato, e quel demone può trovarsi su un host completamente diverso. È il suo percorso di rete che deve funzionare, e sono le sue impostazioni proxy che si applicano.

Inizia identificando il motore, non la rotta

Esegui docker context show e docker version. L'output della versione stampa una sezione client e una sezione server, e il blocco server ti dice chi ha risposto: un motore nativo locale, la macchina virtuale di Docker Desktop o un demone su una macchina remota. docker context inspect mostrerà l'endpoint del contesto selezionato se vuoi esserne certo, e nessuno di questi comandi cambia nulla.

Una variabile d'ambiente come DOCKER_HOST può indirizzare silenziosamente la CLI verso un motore diverso da quello che presupponi, ed è la spiegazione abituale di un portatile che sembra essere sulla VPN mentre il pull viaggia altrove.

Il demone ha una propria identità di rete

Un motore remoto ha bisogno del proprio percorso approvato verso il registry privato. Collegare il client VPN del portatile dà una rotta a quel portatile; non dà lo stesso indirizzo privato a un demone che si trova in un laboratorio o in una sottorete cloud. Se il motore è Docker Desktop, il pull avviene dentro la sua macchina virtuale, che ha una propria configurazione di rete e proxy, separata dall'ambiente della tua shell.

Per questo un curl riuscito sull'host è una prova sull'host e nulla di più.

Scopri quale scambio con il registry è terminato

Il pull di un'immagine è una sequenza: autenticazione, recupero del manifest e poi trasferimenti di blob che spesso vengono reindirizzati verso object storage o un endpoint CDN. Un docker login riuscito dimostra solo il primo passo, e un token può essere perfettamente valido mentre l'host blob reindirizzato non è raggiungibile dalla rete del demone. Annota l'ora esatta, il riferimento dell'immagine e il primo evento utile dal log del demone o del client prima di cambiare qualcosa.

EOF da solo non indica alcuna causa. Può essere una connessione troncata, un proxy che ha lasciato cadere il flusso, un timeout o un problema di MTU, e tirare a indovinare tra queste possibilità senza l'evento con marca temporale è il modo in cui la gente finisce per ricostruire un motore sano. Tratta l'offset in byte nell'output del client come un dato, perché un trasferimento che si ferma sempre alla stessa dimensione è un animale diverso da uno che non parte mai. Registra entrambi gli esiti e confrontali tra i tentativi.

Configura il componente che trasferisce

Per un motore Linux nativo, il proxy appartiene all'ambiente del servizio, non alla tua shell. Un file drop-in sotto /etc/systemd/system/docker.service.d/ con voci HTTP_PROXY, HTTPS_PROXY e NO_PROXY, seguito da systemctl daemon-reload e da un riavvio, è la disposizione documentata. Docker Desktop espone gli stessi valori tramite le proprie impostazioni, e modificare un profilo della shell non tocca nessuno dei due.

Se il registry deve essere raggiunto direttamente tramite la VPN, il demone ha bisogno di un resolver, di una rotta e di un'esclusione proxy deliberata, non solo di un'esclusione. La corrispondenza di NO_PROXY è un confronto di stringhe per componente, e un'esenzione senza una rotta sottostante produce un errore che sembra un problema di proxy.

Quando l'ispezione TLS aziendale si trova sul percorso approvato, installa la sua radice verificata tramite il flusso del motore o di Desktop. Aggiungere il registry a insecure-registries è una modifica diversa che disattiva la validazione, e non è una configurazione di un archivio di fiducia.

Ripeti un pull controllato e controlla cosa è cambiato

Cambia un confine, riavvia il componente che lo possiede e ripeti lo stesso pull dallo stesso contesto. Verifica il riferimento dell'immagine e il digest risultanti, non l'assenza di errori, perché uno strato in cache può far sì che un secondo tentativo percorra molta meno parte del percorso del primo. Conserva nel ticket i trasferimenti che si sono effettivamente verificati, perché sono l'unica registrazione di ciò che il nuovo tentativo ha davvero testato.

I passaggi di build e i container in esecuzione hanno i propri contesti di rete, quindi trattali come domande separate una volta che il pull stesso funziona.