Dockers poolöverlappningsfel är inte ett VPN-rutproblem

Docker vägrar skapa ett nätverk med meddelandet att poolen överlappar en annan i detta adressutrymme, och någon bestämmer att VPN-rutten måste vara orsaken. Det kan den inte vara. Det felet uppstår medan en pool tilldelas, innan ett enda paket finns, och en manuell kärnrutt påverkar det inte. VPN spelar roll ett steg senare, när en container som redan har en adress slutar vara nåbar efter att en rutt dyker upp. Två problem, två uppsättningar bevis, och att blanda dem ger en ändring som inte reparerar något av dem.

Två fel som ser likadana ut

Tilldelningsfelet är aritmetiskt. Docker jämför subnätet du begärde med de subnät det redan hanterar, hittar en skärning och vägrar. Ingenting körs ännu, så det finns ingen rutt, ingen container och ingen trafik att undersöka.

Driftsymptomet är en fråga om nåbarhet. En container som svarade i går svarar inte nu, och något har ändrats i värdens routingtabell. Containern behåller fortfarande sin adress; frågan är vilken väg den adressen tar.

Båda är adressplanproblem. Bara det ena är ett Docker-problem.

Läs de tilldelade poolarna först

Lista nätverken och undersök dem som kan överlappa. Subnätet bor i IPAM-konfigurationen, och de anslutna containrarna listas separat:

docker network ls
docker network inspect EXISTING_NETWORK

Jämför det subnätet med den pool som det nya nätverket begär, och kom ihåg att Compose skapar sitt eget standardnätverk per projekt. En konflikt med ett projekt du glömt ser exakt ut som en konflikt med daemonen.

En statisk ipv4_address på en tjänst är en containers adress, inte pooldefinitionen. Att ändra den tar inte bort en överlappning, eftersom överlappningen är mellan nätverkssubnät och inte mellan containrar. Dockers network-create-referens kräver icke-överlappande subnät för vanlig bryggtilldelning och dokumenterar hur man väljer ett explicit.

Välj ett prefix som överlever VPN

Den omedelbara konflikten och den framtida rutten avgörs av samma val, så gör det en gång. Jämför kandidatintervallet med LAN, med varje VPN-destination som värden kan nå och med alla andra overlay som används.

Ett prefix som tillfredsställer Docker och kolliderar med fjärrnätverket ger dig en container som startar rent och blir onåbar i samma ögonblick som tunneln är uppe. Det är det andra felet i den här artikeln, och det är mycket svårare att diagnostisera senare än att undvika nu.

Skriv ned de valda intervallen någonstans där nästa projekt kan läsa dem. Ett enradsregister över tilldelade prefix är billigare än en vecka av oförklarliga tidsgränser.

Ta ett nätverk ur bruk eller ändra det medvetet

För ett nytt Compose-nätverk anger du det oanvända prefixet i nätverkets IPAM-konfiguration. För ett befintligt projekt planerar du omnumreringen: fasta adresser, beroende tjänster och steget att återskapa nätverket måste alla beaktas, eftersom redigering av YAML inte omnumrerar ett körande nätverk.

Om ett föråldrat nätverk äger den konfliktande tilldelningen, undersök vem som är ansluten innan du tar bort det. docker network rm vägrar så länge aktiva slutpunkter finns, och docker stop tar containernamn eller ID i stället för ett nätverksnamn. Att stoppa en container tar inte heller bort nätverksdefinitionen som håller poolen.

En bred prune är inte ett diagnostiskt verktyg. Den når orelaterade projekt och förstör bevisen du var på väg att samla in.

Standardpooler hjälper bara nästa tilldelning

Daemonens inställning för standardadresspool förbättrar framtida automatiska tilldelningar genom att hålla dem utanför intervallen du reserverar. Den ändrar inte adresser på befintliga nätverk i efterhand, och den löser inte ett explicit subnät som överlappar ett annat explicit subnät.

Behandla den inställningen som en separat, planerad ändring med egen omstart, inte som en del av reparationen av ett projekt. Att blanda de två innebär att en daemon-omstart landar mitt i en orelaterad undersökning. Schemalägg den i ett eget fönster. Bekräfta sedan att en ny automatisk tilldelning verkligen landar utanför intervallen du reserverade.

När skapandet lyckas, verifiera subnätet som faktiskt körs och gör sedan en riktig applikationsbegäran med VPN i sitt avsedda tillstånd. Om poolen är giltig och åtkomsten fortfarande misslyckas, är det återstående arbetet ruttval, filtrering och returvägen. Det är en driftsundersökning, och den gör inte tilldelningsfelet meningslöst i efterhand.

Arbetsordning: läs de tilldelade poolarna, välj ett prefix som undviker både Docker och VPN-destinationerna, återskapa nätverket medvetet och testa sedan en begäran med tunneln uppe.