L'errore di sovrapposizione dei pool di Docker non è un problema di rotta VPN

Docker rifiuta di creare una rete con il messaggio che il pool si sovrappone a un altro in questo spazio di indirizzi, e qualcuno decide che la rotta VPN deve essere la causa. Non può esserlo. Quell'errore viene prodotto mentre un pool viene allocato, prima che esista un solo pacchetto, e una rotta manuale del kernel non ha alcuna influenza su di esso. La VPN conta un passo più tardi, quando un container che ha già un indirizzo smette di essere raggiungibile dopo la comparsa di una rotta. Due problemi, due insiemi di prove, e mescolarli produce un cambiamento che non ne risolve nessuno.

Due errori che si somigliano

L'errore di allocazione è aritmetico. Docker confronta la sottorete che hai richiesto con le sottoreti che già gestisce, trova un'intersezione e rifiuta. Non c'è ancora nulla in esecuzione, quindi non c'è rotta, né container, né traffico da ispezionare.

Il sintomo a runtime è una questione di raggiungibilità. Un container che rispondeva ieri ora non risponde, e qualcosa è cambiato nella tabella di routing dell'host. Il container conserva ancora il suo indirizzo; la questione è quale percorso prende quell'indirizzo.

Entrambi sono problemi di piano degli indirizzi. Solo uno di essi è un problema di Docker.

Leggi prima i pool allocati

Elenca le reti e ispeziona quelle che potrebbero intersecarsi. La sottorete vive nella configurazione IPAM, e i container collegati sono elencati separatamente:

docker network ls
docker network inspect EXISTING_NETWORK

Confronta quella sottorete con il pool richiesto dalla nuova rete, e ricorda che Compose crea la propria rete predefinita per ogni progetto. Un conflitto con un progetto dimenticato sembra esattamente un conflitto con il demone.

Un ipv4_address statico su un servizio è l'indirizzo di un container, non la definizione del pool. Cambiarlo non elimina una sovrapposizione, perché la sovrapposizione è tra sottoreti di rete e non tra container. Il riferimento network-create di Docker richiede sottoreti non sovrapposte per l'allocazione ordinaria tramite bridge e documenta come selezionarne una esplicitamente.

Scegli un prefisso che sopravviva alla VPN

Il conflitto immediato e la rotta futura sono decisi dalla stessa scelta, quindi falla una volta. Confronta l'intervallo candidato con la LAN, con ogni destinazione VPN che l'host può raggiungere e con qualsiasi altro overlay in uso.

Un prefisso che soddisfa Docker e collide con la rete remota ti dà un container che parte pulito e diventa irraggiungibile nel momento in cui il tunnel è attivo. È il secondo errore di questo articolo, ed è molto più difficile da diagnosticare dopo che da evitare ora.

Annota gli intervalli scelti da qualche parte dove il prossimo progetto possa leggerli. Un registro di una riga dei prefissi allocati costa meno di una settimana di timeout inspiegati.

Ritira o modifica una rete deliberatamente

Per una nuova rete Compose, imposta il prefisso inutilizzato nella configurazione IPAM della rete. Per un progetto esistente, pianifica la rinumerazione: gli indirizzi fissi, i servizi dipendenti e il passo di ricreazione della rete devono essere tutti considerati, perché modificare YAML non rinumera una rete in esecuzione.

Se una rete obsoleta possiede l'allocazione in conflitto, ispeziona chi è collegato prima di rimuoverla. docker network rm rifiuta finché esistono endpoint attivi, e docker stop accetta nomi o ID di container invece di un nome di rete. Fermare un container non rimuove nemmeno la definizione di rete che detiene il pool.

Un prune ampio non è uno strumento diagnostico. Raggiunge progetti non correlati e distrugge le prove che stavi per raccogliere.

I pool predefiniti aiutano solo la prossima allocazione

L'impostazione del pool di indirizzi predefinito del demone migliora le allocazioni automatiche future tenendole fuori dagli intervalli che riservi. Non riassegna retroattivamente le reti che esistono già, e non risolve una sottorete esplicita che si sovrappone a un'altra sottorete esplicita.

Tratta quell'impostazione come un cambiamento separato e pianificato con il proprio riavvio, non come parte della riparazione di un progetto. Mescolare le due cose significa che un riavvio del demone finisce in mezzo a un'indagine non correlata. Programmala in una finestra propria. Poi conferma che una nuova allocazione automatica cada davvero fuori dagli intervalli che hai riservato.

Una volta riuscita la creazione, verifica la sottorete effettivamente in esecuzione e poi fai una richiesta reale dell'applicazione con la VPN nel suo stato previsto. Se il pool è valido e l'accesso fallisce ancora, il lavoro rimanente è la selezione della rotta, il filtraggio e il percorso di ritorno. È un'indagine a runtime, e non rende retroattivamente priva di senso l'errore di allocazione.

Ordine di lavoro: leggi i pool allocati, scegli un prefisso che eviti sia Docker sia le destinazioni VPN, ricrea la rete deliberatamente, poi prova una richiesta con il tunnel attivo.