Docker: ingen forhåndsdefinerte adressepooler igjen under en VPN-økt

Feilen er spesifikk: Docker finner ikke et akseptabelt automatisk subnett for et nytt bronettverk. Det betyr ikke at maskinen har gått tom for adresser, og det betyr ikke at VPN-en er ødelagt. To spørsmål avgjør diagnosen: hvilke kandidatblokker daemonen kan se, og hvilke av dem allokatoren dens utelukker i dette miljøet. Gå gjennom dem i den rekkefølgen, fordi det andre spørsmålet er meningsløst til det første er besvart.

Bekreft hva som feilet før du endrer noe

Kjør trinnene nedenfor fra verten som kjører daemonen. Et skall som snakker med en ekstern kontekst beskriver en annen maskin, og den feilen alene kan koste en time.

Noter også Engine-versjonen i saken samtidig. Hver heuristikk i resten av denne runbooken er versjonsbundet, og en påstand uten versjon er et rykte.

Tell tildelingene du allerede har

List nettverkene, og undersøk deretter de som betyr noe: docker network ls etterfulgt av docker network inspect NETWORK_NAME. Les deres IPAM-subnett og containerne som er knyttet til hver. Flere Compose-prosjekter bruker flere blokker enn containerantallet deres antyder, fordi hvert prosjekt har en tendens til å opprette sitt eget standardnettverk. En stoppet container frigjør ikke tildelingen til nettverket sitt.

Kontroller også poolkonfigurasjonen, siden en standardpool har et basisområde og en prefiksstørrelse per nettverk. Store tildelinger per nettverk tømmer de tilgjengelige blokkene raskere, og det er et kapasitetsfaktum, ikke et ruteproblem.

Skriv ned tallet. Det er basislinjen som forteller deg om den neste endringen hjalp.

Sammenlign daemonens syn på ruter

En VPN kan påvirke kandidatvalget, men den konkrete implementasjonen avgjør hvordan. I Moby 28.2.2 på Linux samler InferReservedNetworks navneserveradresser og visse on-link IPv4-ruter, og den reserverer ikke bare hver rute fra hver tabell. Innhentede link-ruter utelukker også en uspesifisert destinasjonsadresse, så en enkelt 0.0.0.0/1-rute reserverer ikke alle adresser. Et annet bredt on-link-prefiks, som 128.0.0.0/1, kan skjære de kjente kandidatområdene 172 og 192.

Sammenlign ip -4 route show table all før og etter at VPN-en kobles til, på daemonens vert. Deltaet er beviset, og versjonen er påstandens omfang.

Ikke generaliser én utgivelses heuristikk til alle utgivelser. Det er slik et forumsvar blir en policyendring.

Velg den minste rettelsen som virker

Hvis et bekreftet ubrukt nettverk holder en blokk du trenger, planlegg den målrettede nedleggelsen sammen med eieren i stedet for å beskjære bredt. For et nytt nettverk unngår et eksplisitt gjennomgått ubrukt subnett å avhenge av automatisk valg helt. Det subnettet må fortsatt unngå reelle Docker-, LAN- og påkrevde VPN-destinasjoner, fordi privat betyr ikke trygt. Å rute et reelt eksternt prefiks ville bytte tildelingsfeilen mot brutt tilgang.

Å endre default-address-pools er en bredere policy om fremtidige tildelinger. Velg en ikke-konfliktende base og en passende tildelt størrelse, flett den med de eksisterende daemoninnstillingene, og planlegg den dokumenterte omstartseffekten. Eksisterende nettverk blir ikke omnummerert i stillhet.

Ikke deaktiver bedriftens ruteutsending for at tildelingen skal lykkes. En eksplisitt adresseplan løser vanligvis det lokale problemet uten å svekke en obligatorisk policy.

Godta tildeling og ruting hver for seg

Etter endringen undersøkes subnettet Docker faktisk opprettet, og applikasjonens VPN- og lokale avhengigheter testes. Vellykket tildeling og korrekt ruting under kjøring er to forskjellige akseptkontroller, og å bestå den første er ikke bevis for den andre. Hvis appen ikke når en ressurs bak tunnelen, har du et ruteproblem som poolfeilen skjulte. Noter begge resultatene i saken.

Ta vare på rutedeltaet og pooletallet sammen med endringsloggen, fordi den neste VPN-klientoppdateringen kan endre det første uten å røre Docker.

Runbooken er komplett når noen andre kan gjenta de to kontrollene og få samme svar.