Docker: geen vooraf gedefinieerde adrespoelen meer over tijdens een VPN-sessie

De fout is specifiek: Docker vindt geen acceptabel automatisch subnet voor een nieuw brugnetwerk. Het betekent niet dat de machine door zijn adressen heen is, en ook niet dat de VPN stuk is. Twee vragen bepalen de diagnose: welke kandidaatblokken de daemon kan zien, en welke daarvan zijn toewijzer in deze omgeving uitsluit. Werk ze in die volgorde af, want de tweede vraag is zinloos tot de eerste is beantwoord.

Bevestig wat er mislukte voordat je iets wijzigt

Voer de stappen hieronder uit op de host die de daemon draait. Een shell die met een externe context praat, beschrijft een andere machine, en alleen die fout kan al een uur kosten.

Noteer tegelijk de Engine-versie in het ticket. Elke heuristiek in de rest van deze runbook is versiegebonden, en een bewering zonder versie is een gerucht.

Tel de toewijzingen die je al hebt

List de netwerken op en bekijk daarna de belangrijke: docker network ls gevolgd door docker network inspect NETWORK_NAME. Lees hun IPAM-subnetten en de containers die aan elk zijn gekoppeld. Verschillende Compose-projecten verbruiken meer blokken dan hun containeraantallen suggereren, omdat elk project de neiging heeft zijn eigen standaardnetwerk aan te maken. Een gestopte container geeft de toewijzing van zijn netwerk niet vrij.

Controleer ook de poelconfiguratie, want een standaardpoel heeft een basisbereik en een prefixgrootte per netwerk. Grote toewijzingen per netwerk putten de beschikbare blokken sneller uit, en dat is een capaciteitsfeit, geen routeringsprobleem.

Schrijf het aantal op. Het is de basislijn die je vertelt of de volgende wijziging hielp.

Vergelijk de kijk van de daemon op routes

Een VPN kan de kandidaatselectie beïnvloeden, maar de exacte implementatie bepaalt hoe. In Moby 28.2.2 op Linux verzamelt InferReservedNetworks namesserveradressen en bepaalde on-link IPv4-routes, en het reserveert niet simpelweg elke route uit elke tabel. Verzamelde linkroutes sluiten ook een niet-gespecificeerd bestemmingsadres uit, dus één enkele 0.0.0.0/1-route reserveert niet alle adressen. Een ander breed on-link-prefix, zoals 128.0.0.0/1, kan de bekende kandidaatreeksen 172 en 192 doorsnijden.

Vergelijk ip -4 route show table all vóór en nadat de VPN verbindt, op de host van de daemon. Het verschil is het bewijs, en de versie is de reikwijdte van de bewering.

Generaliseer de heuristiek van één release niet naar alle releases. Zo wordt een forumannwoord een beleidswijziging.

Kies de kleinste correctie die werkt

Als een bevestigd ongebruikt netwerk een blok vasthoudt dat je nodig hebt, plan dan de gerichte buitengebruikstelling met de eigenaar in plaats van breed te snoeien. Voor een nieuw netwerk vermijdt een expliciet beoordeeld ongebruikt subnet de afhankelijkheid van automatische selectie volledig. Dat subnet moet nog steeds echte Docker-, LAN- en vereiste VPN-bestemmingen vermijden, want privé betekent niet veilig. Een echt extern prefix routeren zou de toewijzingsfout inruilen voor gebroken toegang.

default-address-pools wijzigen is een breder beleid over toekomstige toewijzingen. Kies een niet-conflicterende basis en een passende toegewezen grootte, voeg die samen met de bestaande daemoninstellingen, en plan de gedocumenteerde herstartimpact. Bestaande netwerken worden niet stilzwijgend hernummerd.

Schakel de route-pushes van het bedrijf niet uit om de toewijzing te laten slagen. Een expliciet adresplan lost het lokale probleem meestal op zonder een verplicht beleid te verzwakken.

Accepteer toewijzing en routering afzonderlijk

Bekijk na de wijziging het subnet dat Docker werkelijk heeft aangemaakt en test de VPN- en lokale afhankelijkheden van de applicatie. Succesvolle toewijzing en correcte routering tijdens runtime zijn twee verschillende acceptatiecontroles, en het halen van de eerste is geen bewijs voor de tweede. Als de app een resource achter de tunnel niet bereikt, heb je een routeringsprobleem dat de poelfout verborg. Leg beide resultaten vast in het ticket.

Bewaar het routeverschil en het poelaantal bij het wijzigingsrecord, want de volgende VPN-clientupdate kan het eerste wijzigen zonder Docker aan te raken.

De runbook is compleet wanneer iemand anders die twee controles kan herhalen en hetzelfde antwoord krijgt.