Docker: ingen foruddefinerede adressepuljer tilbage under en VPN-session

Fejlen er specifik: Docker kan ikke finde et acceptabelt automatisk subnet til et nyt bronetværk. Det betyder ikke, at maskinen er løbet tør for adresser, og det betyder ikke, at VPN’en er i stykker. To spørgsmål afgør diagnosen: hvilke kandidatblokke daemonen kan se, og hvilke af dem dens allokator udelukker i dette miljø. Gennemgå dem i den rækkefølge, fordi det andet spørgsmål er meningsløst, indtil det første er besvaret.

Bekræft, hvad der fejlede, før du ændrer noget

Kør trinnene nedenfor fra den vært, der kører daemonen. En shell, der taler med en fjernkontekst, beskriver en anden maskine, og den fejl alene kan spilde en time.

Notér også Engine-versionen i sagen. Hver heuristik i resten af denne runbook er versionsafgrænset, og en påstand uden version er et rygte.

Tæl de tildelinger, du allerede har

List netværkene, og undersøg derefter dem, der betyder noget: docker network ls efterfulgt af docker network inspect NETWORK_NAME. Læs deres IPAM-subnet og de containere, der er knyttet til hver. Flere Compose-projekter bruger flere blokke, end deres containerantal antyder, fordi hvert projekt har tendens til at oprette sit eget standardnetværk. En stoppet container frigiver ikke sin netværks tildeling.

Kontrollér også puljekonfigurationen, da en standardpulje har et basisinterval og en præfiksstørrelse pr. netværk. Store tildelinger pr. netværk udtømmer de tilgængelige blokke hurtigere, og det er en kapacitetskendsgerning, ikke et routingproblem.

Skriv antallet ned. Det er den baseline, der fortæller dig, om den næste ændring hjalp.

Sammenlign daemonens syn på ruter

En VPN kan påvirke kandidatvalget, men den konkrete implementering afgør hvordan. I Moby 28.2.2 på Linux indsamler InferReservedNetworks navneserveradresser og visse on-link IPv4-ruter, og den reserverer ikke blot hver rute fra hver tabel. Indsamlede link-ruter udelukker også en uspecificeret destinationsadresse, så en enkelt 0.0.0.0/1-rute reserverer ikke alle adresser. Et andet bredt on-link-præfiks, såsom 128.0.0.0/1, kan skære de velkendte kandidatområder 172 og 192.

Sammenlign ip -4 route show table all før og efter VPN’en tilsluttes, på daemonens vært. Deltaet er beviset, og versionen er påstandens omfang.

Generalisér ikke én udgivelses heuristik til alle udgivelser. Det er sådan et forumsvar bliver til en politikændring.

Vælg den mindste rettelse, der virker

Hvis et bekræftet ubrugt netværk holder en blok, du har brug for, så planlæg dens målrettede nedlæggelse sammen med ejeren i stedet for at beskære bredt. For et nyt netværk undgår et eksplicit gennemgået ubrugt subnet helt at afhænge af automatisk valg. Det subnet skal stadig undgå reelle Docker-, LAN- og påkrævede VPN-destinationer, fordi privat ikke betyder sikkert. At route et reelt fjernpræfiks ville bytte tildelingsfejlen for brudt adgang.

Ændring af default-address-pools er en bredere politik om fremtidige tildelinger. Vælg en ikke-konfliktende base og en passende tildelt størrelse, flet den med de eksisterende daemonindstillinger, og planlæg den dokumenterede genstartseffekt. Eksisterende netværk omnummereres ikke i stilhed.

Deaktivér ikke virksomhedens ruteudskub for at få tildelingen til at lykkes. En eksplicit adresseplan løser normalt det lokale problem uden at svække en obligatorisk politik.

Accepter tildeling og routing hver for sig

Efter ændringen undersøges det subnet, Docker faktisk oprettede, og applikationens VPN- og lokale afhængigheder testes. Vellykket tildeling og korrekt routing under kørsel er to forskellige acceptkontroller, og at bestå den første er ikke bevis for den anden. Hvis appen ikke kan nå en ressource bag tunnelen, har du et routingproblem, som puljefejlen skjulte. Notér begge resultater i sagen.

Gem rutedeltaet og puljeantallet sammen med ændringsloggen, fordi den næste VPN-klientopdatering kan ændre det første uden at røre Docker.

Runbooken er komplet, når en anden kan gentage de to kontroller og få det samme svar.