Docker: neniuj antaŭdifinitaj adresujoj restas dum VPN-kunsido

La malsukceso estas specifa: Docker ne trovas akcepteblan aŭtomatan subreton por nova ponta reto. Ĝi ne signifas, ke la maŝino elĉerpiĝis je adresoj, kaj ne signifas, ke la VPN estas difektita. Du demandoj decidas la diagnozon: kiujn kandidatajn blokojn la demono povas vidi, kaj kiujn el ili ĝia atribuilo ekskludas en ĉi tiu medio. Trapasu ilin en tiu ordo, ĉar la dua demando estas senenhava ĝis la unua estos respondita.

Konfirmu, kio malsukcesis, antaŭ ol ŝanĝi ion ajn

Rulu la subajn paŝojn de la gastiganto, kiu rulas la demonon. Ŝelo, kiu parolas kun fora kunteksto, priskribas alian maŝinon, kaj tiu eraro sola povas malŝpari horon.

Notu samtempe la version de Engine en la bileto. Ĉiu heŭristiko en la resto de ĉi tiu gvidilo dependas de la versio, kaj aserto sen versio estas famo.

Kalkulu la atribuojn, kiujn vi jam havas

Listigu la retojn, poste inspektu la gravajn: docker network ls sekvata de docker network inspect NETWORK_NAME. Legu iliajn IPAM-subretojn kaj la ujojn alligitajn al ĉiu. Pluraj Compose-projektoj konsumas pli da blokoj ol iliaj ujnombroj sugestas, ĉar ĉiu projekto emas krei sian propran defaŭltan reton. Haltigita ujo ne liberigas la atribuon de sia reto.

Kontrolu ankaŭ la agordon de la ujo, ĉar defaŭlta ujo havas bazan gamon kaj prefiksan grandecon por reto. Grandaj atribuoj por reto elĉerpas la disponeblajn blokojn pli rapide, kaj tio estas kapacita fakto, ne itinera problemo.

Skribu la nombron. Ĝi estas la bazlinio, kiu diras al vi, ĉu la sekva ŝanĝo helpis.

Komparu la vidon de la demono pri itineroj

VPN povas influi la elekton de kandidatoj, sed la konkreta efektivigo decidas kiel. En Moby 28.2.2 sur Linux InferReservedNetworks kolektas adresojn de nomserviloj kaj certajn surligajn IPv4-itinerojn, kaj ĝi ne simple rezervas ĉiun itineron de ĉiu tabelo. Kolektitaj ligaj itineroj ankaŭ ekskludas nespecifitan celadreson, do unu itinero 0.0.0.0/1 sola ne rezervas ĉiun adreson. Alia vasta surliga prefikso, ekzemple 128.0.0.0/1, povas sekci la konatajn kandidatajn gamojn 172 kaj 192.

Komparu ip -4 route show table all antaŭ kaj post kiam la VPN konektiĝas, sur la gastiganto de la demono. La delto estas la pruvo, kaj la versio estas la amplekso de la aserto.

Ne ĝeneraligu la heŭristikon de unu eldono al ĉiuj eldonoj. Tiel respondo en forumo fariĝas politika ŝanĝo.

Elektu la plej malgrandan ripeton, kiu funkcias

Se konfirmita neuzata reto tenas blokon, kiun vi bezonas, planu ĝian celitan emeritiĝon kun la posedanto anstataŭ vasta pritondado. Por nova reto, eksplicite reviziita neuzata subreto tute evitas dependecon de aŭtomata elekto. Tiu subreto tamen devas eviti realajn Docker-, LAN- kaj postulatajn VPN-celojn, ĉar privata ne signifas sekura. Itinerigi realan foran prefikson interŝanĝus la atribueraron kontraŭ rompita aliro.

Ŝanĝi default-address-pools estas pli vasta politiko pri estontaj atribuoj. Elektu nekonfliktantan bazon kaj taŭgan atribuitan grandecon, kunfandu ĝin kun la ekzistantaj demonagordoj, kaj planu la dokumentitan efikon de restartiĝo. Ekzistantaj retoj ne estas silente renumerotaj.

Ne malŝaltu la puŝojn de firmaaj itineroj por ke la atribuo sukcesu. Eksplicita adresplano kutime solvas la lokan problemon sen malfortigi devigan politikon.

Akceptu atribuon kaj itineradon aparte

Post la ŝanĝo, inspektu la subreton, kiun Docker efektive kreis, kaj testu la VPN- kaj lokajn dependecojn de la aplikaĵo. Sukcesa atribuo kaj ĝusta itinerado dum rulado estas du malsamaj akceptokontroloj, kaj trapasi la unuan ne estas pruvo por la dua. Se la aplikaĵo ne povas atingi rimedon malantaŭ la tunelo, vi havas itineran problemon, kiun la ujeraro kaŝis. Registru ambaŭ rezultojn en la bileto.

Konservu la itineran delton kaj la ujan nombron kun la ŝanĝregistro, ĉar la sekva ĝisdatigo de la VPN-kliento povas ŝanĝi la unuan sen tuŝi Docker.

La gvidilo estas kompleta, kiam iu alia povas ripeti tiujn du kontrolojn kaj ricevi la saman respondon.