Docker: nessun pool di indirizzi predefinito rimasto durante una sessione VPN

Il guasto è specifico: Docker non trova una sottorete automatica accettabile per una nuova rete bridge. Non significa che alla macchina siano finite le scorte di indirizzi, né che la VPN sia rotta. Due domande decidono la diagnosi: quali blocchi candidati il demone riesce a vedere e quali di essi il suo allocatore esclude in questo ambiente. Affrontatele in quest’ordine, perché la seconda domanda non ha senso finché la prima non ha risposta.

Confermate cosa è fallito prima di cambiare qualsiasi cosa

Eseguite i passaggi seguenti dall’host che esegue il demone. Una shell che parla con un contesto remoto sta descrivendo un’altra macchina, e solo questo errore può far perdere un’ora.

Annotate nello stesso momento la versione di Engine nel ticket. Ogni euristica nel resto di questa guida dipende dalla versione, e un’affermazione senza versione è una voce.

Contate le allocazioni che avete già

Elencate le reti, poi ispezionate quelle che contano: docker network ls seguito da docker network inspect NETWORK_NAME. Leggete le loro sottoreti IPAM e i container collegati a ciascuna. Diversi progetti Compose consumano più blocchi di quanto suggerisca il numero dei loro container, perché ogni progetto tende a creare la propria rete predefinita. Un container fermo non libera l’allocazione della sua rete.

Controllate anche la configurazione del pool, perché un pool predefinito ha un intervallo di base e una dimensione di prefisso per rete. Le allocazioni grandi per rete esauriscono più in fretta i blocchi disponibili, e questo è un fatto di capacità, non un problema di routing.

Scrivete il conteggio. È la linea di base che vi dice se il cambiamento successivo ha aiutato.

Confrontate la visione che il demone ha delle route

Una VPN può influenzare la selezione dei candidati, ma l’implementazione esatta decide come. In Moby 28.2.2 su Linux, InferReservedNetworks raccoglie gli indirizzi dei server dei nomi e alcune route IPv4 on-link, e non si limita a riservare ogni route di ogni tabella. Le route di collegamento raccolte escludono anche un indirizzo di destinazione non specificato, quindi una sola route 0.0.0.0/1 non riserva tutti gli indirizzi. Un altro prefisso on-link ampio, come 128.0.0.0/1, può intersecare gli intervalli candidati abituali 172 e 192.

Confrontate ip -4 route show table all prima e dopo la connessione della VPN, sull’host del demone. Il delta è la prova, e la versione è l’ambito dell’affermazione.

Non generalizzate l’euristica di una versione a tutte le versioni. È così che una risposta di un forum diventa un cambio di policy.

Scegliete la correzione più piccola che funziona

Se una rete inutilizzata confermata detiene un blocco che vi serve, pianificate la sua dismissione mirata con il proprietario invece di potare in modo ampio. Per una nuova rete, una sottorete inutilizzata verificata esplicitamente evita del tutto la dipendenza dalla selezione automatica. Quella sottorete deve comunque evitare destinazioni reali di Docker, LAN e VPN richieste, perché privato non significa sicuro. Instradare un vero prefisso remoto scambierebbe l’errore di allocazione con un accesso rotto.

Cambiare default-address-pools è una policy più ampia sulle allocazioni future. Scegliete una base senza conflitti e una dimensione allocata adeguata, unitela alle impostazioni esistenti del demone e pianificate l’impatto documentato del riavvio. Le reti esistenti non vengono rinumerate in silenzio.

Non disattivate il push delle route aziendali per far riuscire l’allocazione. Un piano di indirizzamento esplicito di solito risolve il problema locale senza indebolire una policy obbligatoria.

Accettate allocazione e routing separatamente

Dopo la modifica, ispezionate la sottorete che Docker ha effettivamente creato e provate le dipendenze VPN e locali dell’applicazione. Un’allocazione riuscita e un routing corretto a runtime sono due controlli di accettazione diversi, e superare il primo non è una prova per il secondo. Se l’app non raggiunge una risorsa dietro il tunnel, avete un problema di routing che l’errore del pool nascondeva. Registrate entrambi i risultati nel ticket.

Conservate il delta delle route e il conteggio del pool insieme al record della modifica, perché il prossimo aggiornamento del client VPN può alterare il primo senza toccare Docker.

La guida è completa quando qualcun altro può ripetere questi due controlli e ottenere la stessa risposta.