Docker: inga fördefinierade adresspooler kvar under en VPN-session

Felet är specifikt: Docker hittar inget acceptabelt automatiskt subnät för ett nytt bronätverk. Det betyder inte att maskinen har slut på adresser, och inte att VPN:en är trasig. Två frågor avgör diagnosen: vilka kandidatblock daemonen kan se, och vilka av dem dess allokator utesluter i den här miljön. Arbeta igenom dem i den ordningen, eftersom den andra frågan är meningslös tills den första är besvarad.

Bekräfta vad som misslyckades innan du ändrar något

Kör stegen nedan från värden som kör daemonen. Ett skal som talar med en fjärrkontext beskriver en annan maskin, och det felet ensamt kan kosta en timme.

Notera samtidigt Engine-versionen i ärendet. Varje heuristik i resten av den här runbooken är versionsbunden, och ett påstående utan version är ett rykte.

Räkna tilldelningarna du redan har

Lista nätverken och inspektera sedan de som spelar roll: docker network ls följt av docker network inspect NETWORK_NAME. Läs deras IPAM-subnät och de containrar som är kopplade till varje. Flera Compose-projekt förbrukar fler block än deras containerantal antyder, eftersom varje projekt tenderar att skapa sitt eget standardnätverk. En stoppad container frigör inte sin nätverkstilldelning.

Kontrollera även poolkonfigurationen, eftersom en standardpool har ett basintervall och en prefixstorlek per nätverk. Stora tilldelningar per nätverk tar slut på de tillgängliga blocken snabbare, och det är ett kapacitetsfaktum, inte ett routingproblem.

Skriv ner antalet. Det är baslinjen som säger om nästa ändring hjälpte.

Jämför daemonens syn på rutter

En VPN kan påverka kandidaturvalet, men den exakta implementeringen avgör hur. I Moby 28.2.2 på Linux samlar InferReservedNetworks namnserveradresser och vissa on-link IPv4-rutter, och den reserverar inte bara varje rutt från varje tabell. Insamlade länkrutter utesluter också en ospecificerad destinationsadress, så en enda 0.0.0.0/1-rutt reserverar inte alla adresser. Ett annat brett on-link-prefix, som 128.0.0.0/1, kan skära de välbekanta kandidatintervallen 172 och 192.

Jämför ip -4 route show table all före och efter att VPN:en ansluter, på daemonens värd. Deltat är beviset, och versionen är påståendets omfattning.

Generalisera inte en utgåvas heuristik till alla utgåvor. Det är så ett forumsvar blir en policyändring.

Välj den minsta åtgärd som fungerar

Om ett bekräftat oanvänt nätverk håller ett block du behöver, planera dess riktade avveckling tillsammans med ägaren i stället för att beskära brett. För ett nytt nätverk undviker ett uttryckligen granskat oanvänt subnät att bero på automatiskt val helt. Det subnätet måste fortfarande undvika riktiga Docker-, LAN- och nödvändiga VPN-destinationer, eftersom privat inte betyder säkert. Att routa ett riktigt fjärrprefix skulle byta tilldelningsfelet mot bruten åtkomst.

Att ändra default-address-pools är en bredare policy om framtida tilldelningar. Välj en icke-konfliktande bas och en lämplig tilldelad storlek, slå ihop den med de befintliga daemoninställningarna och planera den dokumenterade omstartseffekten. Befintliga nätverk numreras inte om i tysthet.

Inaktivera inte företagets ruttutskick för att tilldelningen ska lyckas. En uttrycklig adressplan löser oftast det lokala problemet utan att försvaga en obligatorisk policy.

Acceptera tilldelning och routing separat

Efter ändringen, inspektera det subnät Docker faktiskt skapade och testa applikationens VPN- och lokala beroenden. Lyckad tilldelning och korrekt routing under körning är två olika acceptanskontroller, och att klara den första är inte bevis för den andra. Om appen inte når en resurs bakom tunneln har du ett routingproblem som poolfelat dolde. Notera båda resultaten i ärendet.

Spara rutt-deltat och poolantalet tillsammans med ändringsloggen, eftersom nästa VPN-klientuppdatering kan ändra det första utan att röra Docker.

Runbooken är komplett när någon annan kan upprepa de två kontrollerna och få samma svar.