Docker: během relace VPN nezbyly žádné předdefinované fondy adres
Chyba předdefinovaného fondu se týká automatického přidělování, ne veřejných adres. Spočítejte přidělení, porovnejte on-link trasy a ponechte politiku VPN nedotčenou.
Selhání je konkrétní: Docker nenajde přijatelnou automatickou podsíť pro novou mostovou síť. Neznamená to, že došly adresy stroje, ani že je VPN rozbitá. Diagnózu rozhodují dvě otázky: které kandidátní bloky démon vidí a které z nich jeho alokátor v tomto prostředí vylučuje. Projděte je v tomto pořadí, protože druhá otázka nemá smysl, dokud není zodpovězena první.
Potvrďte, co selhalo, než cokoli změníte
Spusťte níže uvedené kroky na hostiteli, který spouští démona. Shell komunikující se vzdáleným kontextem popisuje jiný stroj a sama tato chyba může stát hodinu.
Zaznamenejte současně do tiketu i verzi Engine. Každá heuristika ve zbytku této příručky je vázána na verzi a tvrzení bez verze je fáma.
Spočítejte přidělení, která už máte
Vypište sítě a potom prohlédněte ty důležité: docker network ls, následované docker network inspect NETWORK_NAME. Přečtěte jejich IPAM podsítě a kontejnery připojené ke každé. Několik projektů Compose spotřebuje více bloků, než naznačují počty jejich kontejnerů, protože každý projekt má sklon vytvářet vlastní výchozí síť. Zastavený kontejner neuvolní přidělení své sítě.
Zkontrolujte také konfiguraci fondu, protože výchozí fond má základní rozsah a velikost prefixu na síť. Velká přidělení na síť vyčerpávají dostupné bloky rychleji a to je fakt o kapacitě, ne problém směrování.
Zapište počet. Je to základní linie, která vám řekne, zda další změna pomohla.
Porovnejte, jak démon vidí trasy
VPN může ovlivnit výběr kandidátů, ale konkrétní implementace rozhoduje jak. V Moby 28.2.2 na Linuxu InferReservedNetworks shromažďuje adresy jmenných serverů a určité on-link IPv4 trasy a nerezervuje prostě každou trasu z každé tabulky. Shromážděné link trasy také vylučují nespecifikovanou cílovou adresu, takže jediná trasa 0.0.0.0/1 nerezervuje všechny adresy. Jiný široký on-link prefix, například 128.0.0.0/1, může protnout známé kandidátní rozsahy 172 a 192.
Porovnejte ip -4 route show table all před připojením VPN a po něm, na hostiteli démona. Rozdíl je důkaz a verze je rozsah tvrzení.
Nezevšeobecňujte heuristiku jednoho vydání na všechna vydání. Tak se z odpovědi na fóru stane změna politiky.
Vyberte nejmenší opravu, která funguje
Pokud potvrzená nepoužívaná síť drží blok, který potřebujete, naplánujte její cílené vyřazení s vlastníkem místo plošného prořezávání. Pro novou síť se výslovně zkontrolovaná nepoužívaná podsíť úplně vyhne závislosti na automatickém výběru. Ta podsíť se však stále musí vyhýbat skutečným cílům Docker, LAN a požadovaným VPN, protože privátní neznamená bezpečné. Směrování skutečného vzdáleného prefixu by vyměnilo chybu přidělení za nefunkční přístup.
Změna default-address-pools je širší politika budoucích přidělení. Zvolte nekolidující základ a vhodnou přidělenou velikost, slučte ji se stávajícím nastavením démona a naplánujte dokumentovaný dopad restartu. Stávající sítě se tiše nepřečíslují.
Nevypínejte posílání firemních tras, aby přidělení uspělo. Explicitní plán adres obvykle vyřeší místní problém bez oslabení povinné politiky.
Přijměte přidělení a směrování odděleně
Po změně prohlédněte podsíť, kterou Docker skutečně vytvořil, a otestujte závislosti aplikace na VPN a místní zdroje. Úspěšné přidělení a správné směrování za běhu jsou dvě různé přejímací kontroly a absolvování první není důkazem druhé. Pokud se aplikace nedostane ke zdroji za tunelem, máte problém se směrováním, který chyba fondu skrývala. Zaznamenejte oba výsledky do tiketu.
Uchovejte rozdíl tras a počet fondu spolu se záznamem o změně, protože příští aktualizace klienta VPN může změnit první bez zásahu do Dockeru.
Příručka je úplná, když někdo jiný může zopakovat tyto dvě kontroly a dostat stejnou odpověď.