Dockeri pooli kattumise viga ei ole VPN-i marsruudi probleem

Docker keeldub võrgu loomisest teatega, et pool kattub teisega selles aadressiruumis, ja keegi otsustab, et VPN-i marsruut peab olema põhjus. See ei saa olla. See viga tekib pooli jaotamise ajal, enne kui eksisteerib ükski pakett, ja käsitsi tuuma marsruut ei mõjuta seda. VPN loeb üks samm hiljem, kui konteiner, millel on juba aadress, muutub pärast marsruudi ilmumist kättesaamatuks. Kaks probleemi, kaks tõendite kogumit ja nende segamine annab muudatuse, mis ei paranda kumbagi.

Kaks samamoodi näivat viga

Jaotamise viga on aritmeetiline. Docker võrdleb teie küsitud alamvõrku alamvõrkudega, mida see juba haldab, leiab ühisosa ja keeldub. Midagi veel ei tööta, seega pole marsruuti, konteinerit ega liiklust, mida uurida.

Käitusaegne sümptom on kättesaadavuse küsimus. Konteiner, mis eile vastas, ei vasta nüüd, ja midagi on muutunud hosti marsruutimistabelis. Konteiner hoiab endiselt oma aadressi; küsimus on, millist teed see aadress võtab.

Mõlemad on aadressiplaani probleemid. Ainult üks neist on Dockeri probleem.

Lugege esmalt jaotatud poolid

Loetlege võrgud ja kontrollige neid, mis võivad lõikuda. Alamvõrk asub IPAM-i konfiguratsioonis ja ühendatud konteinerid on loetletud eraldi:

docker network ls
docker network inspect EXISTING_NETWORK

Võrrelge seda alamvõrku pooliga, mida uus võrk küsib, ja pidage meeles, et Compose loob iga projekti jaoks oma vaikevõrgu. Konflikt projektiga, mille olete unustanud, näeb välja täpselt nagu konflikt deemoniga.

Teenuse staatiline ipv4_address on ühe konteineri aadress, mitte pooli definitsioon. Selle muutmine ei kõrvalda kattumist, sest kattumine on võrkude alamvõrkude vahel, mitte konteinerite vahel. Dockeri network-create viide nõuab tavalise silla jaotamise jaoks mittekattuvaid alamvõrke ja dokumenteerib, kuidas üht selgesõnaliselt valida.

Valige prefiks, mis elab VPN-i üle

Vahetu konflikt ja tulevane marsruut otsustatakse sama valikuga, tehke see üks kord. Võrrelge kandidaatvahemikku LAN-iga, iga VPN-i sihtkohaga, mille host saab kätte, ja mis tahes muu kasutusel oleva overlayga.

Prefiks, mis rahuldab Dockerit ja põrkab kokku kaugvõrguga, annab teile konteineri, mis käivitub puhtalt ja muutub kättesaamatuks hetkel, mil tunnel püsti tõstetakse. See on selle artikli teine viga ja seda on hiljem palju raskem diagnoosida kui praegu vältida.

Kirjutage valitud vahemikud üles kohta, kust järgmine projekt saab neid lugeda. Üherealise jaotatud prefiksite registri pidamine on odavam kui nädal seletamatuid aegumisi.

Võtke võrk teadlikult kasutusest välja või muutke seda

Uue Compose'i võrgu jaoks määrake kasutamata prefiks võrgu IPAM-i konfiguratsioonis. Olemasoleva projekti jaoks planeerige ümbernummerdamine: fikseeritud aadressid, sõltuvad teenused ja võrgu uuesti loomise samm tuleb kõik arvesse võtta, sest YAML-i muutmine ei nummerda töötavat võrku ümber.

Kui vananenud võrk omab konfliktset jaotust, kontrollige enne selle eemaldamist, kes on ühendatud. docker network rm keeldub, kuni aktiivsed lõpp-punktid on olemas, ja docker stop võtab konteineri nimesid või ID-sid, mitte võrgu nime. Konteineri peatamine ei eemalda ka võrgu definitsiooni, mis pooli hoiab.

Lai prune ei ole diagnostikavahend. See jõuab seotud projektideni ja hävitab tõendid, mida te just koguda kavatsesite.

Vaikepoolid aitavad ainult järgmist jaotamist

Deemoni vaikimisi aadressipooli säte parandab tulevasi automaatseid jaotusi, hoides neid väljaspool vahemikke, mille te reserveerite. See ei anna juba olemasolevatele võrkudele tagasiulatuvalt uusi aadresse, ja see ei lahenda selgesõnalist alamvõrku, mis kattub teise selgesõnalise alamvõrguga.

Käsitlege seda sätet eraldi, planeeritud muudatusena, millel on oma taaskäivitus, mitte ühe projekti parandamise osana. Kahe segamine tähendab, et deemoni taaskäivitus maandub seotud uurimise keskele. Ajastage see oma aknasse. Seejärel kinnitage, et üks uus automaatne jaotus maandub tõepoolest väljapoole vahemikke, mille reserveerisite.

Kui loomine õnnestub, kontrollige tegelikult töötavat alamvõrku ja seejärel tehke üks tõeline rakendusepäring, kui VPN on kavandatud olekus. Kui pool on kehtiv ja juurdepääs ikka ebaõnnestub, on ülejäänud töö marsruudi valik, filtreerimine ja tagasitee. See on käitusaegne uurimine ja see ei muuda jaotamise viga tagasiulatuvalt mõttetuks.

Töö järjekord: lugege jaotatud poolid, valige prefiks, mis väldib nii Dockerit kui VPN-i sihtkohti, looge võrk teadlikult uuesti ja seejärel testige üht päringut tunneliga püsti.