Docker: ingen førehandsdefinerte adressepoolar att under ei VPN-økt

Feilen er spesifikk: Docker finn ikkje eit akseptabelt automatisk subnett for eit nytt bronettverk. Det tyder ikkje at maskinen har gått tom for adresser, og det tyder ikkje at VPN-en er øydelagd. To spørsmål avgjer diagnosen: kva kandidatblokker daemonen kan sjå, og kva av dei allokatoren hans utelukkar i dette miljøet. Gå gjennom dei i den rekkjefølgja, fordi det andre spørsmålet er meiningslaust til det første er svara.

Stadfest kva som feila før du endrar noko

Køyr stega nedanfor frå verten som køyrer daemonen. Eit skal som snakkar med ein ekstern kontekst skildrar ein annan maskin, og den feilen åleine kan koste ein time.

Noter òg Engine-versjonen i saka samstundes. Kvar heuristikk i resten av denne runboka er versjonsbunden, og ein påstand utan versjon er eit rykte.

Tel tildelingane du alt har

List nettverka, og undersøk deretter dei som betyr noko: docker network ls etterfølgd av docker network inspect NETWORK_NAME. Les IPAM-subnetta deira og containerane som er knytte til kvar. Fleire Compose-prosjekt brukar fleire blokker enn containerantalet deira antydar, fordi kvart prosjekt har ein tendens til å opprette sitt eige standardnettverk. Ein stoppa container frigjer ikkje tildelinga til nettverket sitt.

Kontroller òg poolkonfigurasjonen, sidan ein standardpool har eit basisområde og ein prefiksstorleik per nettverk. Store tildelingar per nettverk tømmer dei tilgjengelege blokkene raskare, og det er eit kapasitetsfaktum, ikkje eit ruteproblem.

Skriv ned talet. Det er basislinja som fortel deg om den neste endringa hjelpte.

Samanlikn synet daemonen har på ruter

Ein VPN kan påverke kandidatvalet, men den konkrete implementasjonen avgjer korleis. I Moby 28.2.2 på Linux samlar InferReservedNetworks namneserveradresser og visse on-link IPv4-ruter, og den reserverer ikkje berre kvar rute frå kvar tabell. Innhenta link-ruter utelukkar òg ei uspesifisert måladdresse, så ei einsleg 0.0.0.0/1-rute reserverer ikkje alle adresser. Eit anna breitt on-link-prefiks, som 128.0.0.0/1, kan skjere dei kjende kandidatområda 172 og 192.

Samanlikn ip -4 route show table all før og etter at VPN-en koplar til, på verten til daemonen. Deltaet er provet, og versjonen er omfanget av påstanden.

Ikkje generaliser heuristikken til ein utgiving til alle utgivingar. Det er slik eit forumssvar blir ei policyendring.

Vel den minste rettinga som verkar

Viss eit stadfesta ubrukt nettverk held ein blokk du treng, planlegg den målretta nedlegginga saman med eigaren i staden for å klippe breitt. For eit nytt nettverk unngår eit eksplisitt gjennomgått ubrukt subnett å vere avhengig av automatisk val heilt. Det subnettet må framleis unngå reelle Docker-, LAN- og påkravde VPN-mål, fordi privat betyr ikkje trygt. Å rute eit reelt eksternt prefiks ville byte tildelingsfeilen mot broten tilgang.

Å endre default-address-pools er ein breiare policy om framtidige tildelingar. Vel ein ikkje-konfliktande base og ein passande tildelt storleik, flett han med dei eksisterande daemoninnstillingane, og planlegg den dokumenterte omstartseffekten. Eksisterande nettverk blir ikkje omnummererte i det stille.

Ikkje slå av rutetilsendinga til verksemda for at tildelinga skal lukkast. Ein eksplisitt adresseplan løyser vanlegvis det lokale problemet utan å svekkje ein obligatorisk policy.

Godta tildeling og ruting kvar for seg

Etter endringa blir subnettet Docker faktisk oppretta undersøkt, og VPN- og lokale avhengnader til applikasjonen blir testa. Vellukka tildeling og korrekt ruting under køyring er to ulike akseptkontrollar, og å klare den første er ikkje prov for den andre. Viss appen ikkje når ein ressurs bak tunnelen, har du eit ruteproblem som poolfeilen skjulte. Noter båe resultata i saka.

Ta vare på rutedeltaet og pooletalet saman med endringsloggen, fordi den neste VPN-klientoppdateringa kan endre det første utan å røre Docker.

Runboka er komplett når nokon andre kan gjenta dei to kontrollane og få same svar.