La eraro de pool-tavoliĝo en Docker ne estas problema pri VPN-itinero

Docker rifuzas krei reton kun la mesaĝo, ke la pool tavoliĝas kun alia en ĉi tiu adresspaco, kaj iu decidas, ke la VPN-itinero devas esti la kaŭzo. Ĝi ne povas esti. Tiu eraro produktiĝas dum pool estas atribuata, antaŭ ol ekzistas unu sola paketo, kaj permana kerno-itinero neniel influas ĝin. VPN gravas unu paŝon poste, kiam kontenero, kiu jam havas adreson, ĉesas esti atingebla post kiam itinero aperas. Du problemoj, du aroj da pruvoj, kaj miksi ilin produktas ŝanĝon, kiu riparas neniun el la du.

Du eraroj, kiuj aspektas same

La atribua eraro estas aritmetika. Docker komparas la subreton, kiun vi petis, kun la subretoj, kiujn ĝi jam administras, trovas komunaĵon kaj rifuzas. Nenio ankoraŭ funkcias, do mankas itinero, kontenero kaj trafiko por inspekti.

La rultempa simptomo estas demando pri atingeblo. Kontenero, kiu hieraŭ respondis, nun ne respondas, kaj io ŝanĝiĝis en la enkursiga tabelo de la gastiganto. La kontenero ankoraŭ tenas sian adreson; la demando estas, kiun vojon tiu adreso prenas.

Ambaŭ estas problemoj de adresa plano. Nur unu el ili estas problemo de Docker.

Unue legu la atribuitajn pool-ojn

Listigu la retojn kaj inspektu tiujn, kiuj povus kruciĝi. La subreto loĝas en la IPAM-agordo, kaj la alkroĉitaj konteneroj estas listigitaj aparte:

docker network ls
docker network inspect EXISTING_NETWORK

Komparu tiun subreton kun la pool, kiun la nova reto petas, kaj memoru, ke Compose kreas sian propran implicitan reton por ĉiu projekto. Konflikto kun projekto, kiun vi forgesis, aspektas ekzakte kiel konflikto kun la demono.

Statika ipv4_address en servo estas la adreso de unu kontenero, ne la difino de la pool. Ŝanĝi ĝin ne forigas tavoliĝon, ĉar la tavoliĝo estas inter retaj subretoj, ne inter konteneroj. La network-create-referenco de Docker postulas ne-tavoliĝantajn subretojn por ordinara ponto-atribuo kaj dokumentas, kiel eksplicite elekti unu.

Elektu prefikson, kiu postvivas la VPN

La tuja konflikto kaj la estonta itinero estas deciditaj per la sama elekto, do faru ĝin unufoje. Komparu la kandidatan gamon kun la LAN, kun ĉiu VPN-celo, kiun la gastiganto povas atingi, kaj kun ajna alia overlay en uzo.

Prefikso, kiu kontentigas Docker kaj kolizias kun la fora reto, donas al vi konteneron, kiu startas pure kaj fariĝas neatingebla en la momento, kiam la tunelo staras. Tio estas la dua eraro en ĉi tiu artikolo, kaj ĝi estas multe pli malfacile diagnozeble poste ol eviteble nun.

Skribu la elektitajn gamojn ie, de kie la sekva projekto povas legi ilin. Unulinia registro de atribuitaj prefiksoj estas pli malmultekosta ol semajno da neklarigitaj tempolimoj.

Retiri aŭ ŝanĝi reton intence

Por nova Compose-reto, agordu la neuzatan prefikson en la IPAM-agordo de la reto. Por ekzistanta projekto, planu la renumeradon: fiksaj adresoj, dependaj servoj kaj la paŝo de rekreado de la reto ĉiuj devas esti konsiderataj, ĉar redakti YAML ne renumeras funkciantan reton.

Se malnova reto posedas la konfliktantan atribuon, inspektu, kiu estas alkroĉita, antaŭ ol forigi ĝin. docker network rm rifuzas dum ekzistas aktivaj endpoint-oj, kaj docker stop akceptas kontenerajn nomojn aŭ ID-ojn anstataŭ retan nomon. Haltigi konteneron ankaŭ ne forigas la retan difinon, kiu tenas la pool.

Larĝa prune ne estas diagnoza ilo. Ĝi atingas nerilatajn projektojn kaj detruas la pruvojn, kiujn vi ĵus intencis kolekti.

Implicitaj pool-oj helpas nur la sekvan atribuon

La agordo de implicita adresa pool de la demono plibonigas estontajn aŭtomatajn atribuojn, tenante ilin ekster la gamoj, kiujn vi rezervas. Ĝi ne retroe ŝanĝas la adresojn de retoj, kiuj jam ekzistas, kaj ĝi ne solvas eksplicitan subreton, kiu tavoliĝas kun alia eksplicita subreto.

Traktu tiun agordon kiel apartan, planitan ŝanĝon kun propra restarto, ne kiel parton de riparo de unu projekto. Miksi la du signifas, ke demona restarto falas meze de nerilata esploro. Planu ĝin en propra fenestro. Poste konfirmu, ke unu nova aŭtomata atribuo efektive falas ekster la gamoj, kiujn vi rezervis.

Post kiam kreado sukcesos, kontrolu la subreton, kiu efektive funkcias, kaj poste faru unu realan aplikaĵan peton kun la VPN en sia intencita stato. Se la pool estas valida kaj aliro ankoraŭ malsukcesas, la restanta laboro estas itinera elekto, filtrado kaj la revena vojo. Tio estas rultempa esploro, kaj ĝi ne faras la atribuan eraron retroe sensignifa.

Ordo de laboro: legu la atribuitajn pool-ojn, elektu prefikson, kiu evitas kaj Docker kaj la VPN-celojn, intence rekrei la reton, kaj poste testu unu peton kun la tunelo supre.