Napaka prekrivanja bazenov v Dockerju ni problem poti VPN

Docker zavrne ustvarjanje omrežja s sporočilom, da se bazen prekriva z drugim v tem naslovnem prostoru, in nekdo sklene, da mora biti vzrok pot VPN. Ne more biti. Ta napaka nastane med dodeljevanjem bazena, preden obstaja en sam paket, in ročna jedrna pot nanjo ne vpliva. VPN šteje korak pozneje, ko vsebnik, ki že ima naslov, postane nedosegljiv po tem, ko se pojavi pot. Dva problema, dva niza dokazov, in njuno mešanje ustvari spremembo, ki ne odpravi nobenega.

Dve napaki, ki sta si podobni

Napaka dodeljevanja je aritmetična. Docker primerja zahtevano podomrežje s podomrežji, ki jih že upravlja, najde presek in zavrne. Nič še ne teče, zato ni poti, vsebnika ali prometa za pregled.

Simptom med delovanjem je vprašanje dosegljivosti. Vsebnik, ki je včeraj odgovarjal, zdaj ne odgovarja, in v usmerjevalni tabeli gostitelja se je nekaj spremenilo. Vsebnik še vedno drži svoj naslov; vprašanje je, katero pot ta naslov ubere.

Oba sta problema naslovnega načrta. Samo eden od njiju je problem Dockerja.

Najprej preberite dodeljene bazene

Naštejte omrežja in pregledajte tista, ki bi se lahko sekali. Podomrežje živi v konfiguraciji IPAM, priloženi vsebniki pa so navedeni ločeno:

docker network ls
docker network inspect EXISTING_NETWORK

Primerjajte to podomrežje z bazenom, ki ga zahteva novo omrežje, in ne pozabite, da Compose ustvari svoje privzeto omrežje za vsak projekt. Konflikt s pozabljenim projektom je videti natanko kot konflikt z demonom.

Statični ipv4_address v storitvi je naslov enega vsebnika, ne definicija bazena. Njegova sprememba ne odpravi prekrivanja, ker je prekrivanje med omrežnimi podomrežji in ne med vsebniki. Dockerjev referenčni priročnik network-create za običajno dodeljevanje prek mostu zahteva podomrežja, ki se ne prekrivajo, in dokumentira, kako eno izrecno izbrati.

Izberite predpono, ki preživi VPN

Neposredni konflikt in prihodnjo pot odloči ista izbira, zato jo opravite enkrat. Primerjajte kandidatno območje z LAN, z vsakim ciljem VPN, ki ga gostitelj doseže, in s katerim koli drugim overlayem v uporabi.

Predpona, ki zadovolji Docker in trči ob oddaljeno omrežje, vam da vsebnik, ki se čisto zažene in postane nedosegljiv v trenutku, ko se tunel dvigne. To je druga napaka v tem članku in jo je veliko težje diagnosticirati pozneje kot se ji izogniti zdaj.

Zapišite izbrana območja nekam, od koder jih bo naslednji projekt lahko prebral. Register dodeljenih predpon v eni vrstici je cenejši od tedna nerazloženih časovnih omejitev.

Omrežje namerno umaknite ali spremenite

Za novo omrežje Compose nastavite neuporabljeno predpono v konfiguraciji IPAM omrežja. Pri obstoječem projektu načrtujte preštevilčenje: fiksni naslovi, odvisne storitve in korak ponovnega ustvarjanja omrežja morajo biti vsi upoštevani, ker urejanje YAML ne preštevilči delujočega omrežja.

Če konfliktno dodelitev ima zastarelo omrežje, pred odstranitvijo preglejte, kdo je priključen. docker network rm zavrne, dokler obstajajo aktivne končne točke, docker stop pa sprejme imena ali ID vsebnikov namesto imena omrežja. Ustavitev vsebnika tudi ne odstrani definicije omrežja, ki drži bazen.

Širok prune ni diagnostično orodje. Doseže nepovezane projekte in uniči dokaze, ki ste jih nameravali zbrati.

Privzeti bazeni pomagajo le naslednji dodelitvi

Nastavitev privzetega bazena naslovov pri demonu izboljša prihodnje samodejne dodelitve tako, da jih drži zunaj območij, ki jih rezervirate. Ne spremeni za nazaj naslovov omrežij, ki že obstajajo, in ne reši izrecnega podomrežja, ki se prekriva z drugim izrecnim podomrežjem.

To nastavitev obravnavajte kot ločeno, načrtovano spremembo z lastnim ponovnim zagonom, ne kot del popravila enega projekta. Mešanje obojega pomeni, da ponovni zagon demona pade na sredino nepovezane preiskave. Načrtujte ga v lastnem oknu. Nato potrdite, da ena nova samodejna dodelitev res pade zunaj območij, ki ste jih rezervirali.

Ko ustvarjanje uspe, preverite podomrežje, ki dejansko teče, in nato izvedite eno resnično zahtevo aplikacije z VPN v predvidenem stanju. Če je bazen veljaven in dostop še vedno ne uspe, je preostalo delo izbira poti, filtriranje in povratna pot. To je preiskava med delovanjem in ne naredi napake dodeljevanja za nazaj nesmiselne.

Vrstni red dela: preberite dodeljene bazene, izberite predpono, ki se izogne Dockerju in ciljem VPN, namerno znova ustvarite omrežje in nato preizkusite eno zahtevo z dvignjenim tunelom.