Docker: nuk mbeten grupe adresash të paracaktuara gjatë një sesioni VPN
Gabimi i grupit të paracaktuar ka të bëjë me shpërndarjen automatike, jo me adresat publike. Numëroni shpërndarjet, krahasoni rrugët on-link dhe mbani politikën e VPN të paprekur.
Dështimi është specifik: Docker nuk gjen një nënrrjetë automatike të pranueshme për një rrjetë ure të re. Kjo nuk do të thotë që makinës i kanë mbaruar adresat, dhe as që VPN është prishur. Diagnozën e vendosin dy pyetje: cilat blloqe kandidate sheh daemoni dhe cilat prej tyre shpërndarësi i tij i përjashton në këtë mjedis. Kalojini në këtë rend, sepse pyetja e dytë nuk ka kuptim derisa të jetë përgjigjur e para.
Konfirmoni çfarë dështoi përpara se të ndryshoni gjithçka
Ekzekutoni hapat më poshtë nga hosti që drejton daemonin. Një shell që flet me një kontekst të largët po përshkruan një makinë tjetër, dhe vetëm ky gabim mund të humbasë një orë.
Shënoni njëkohësisht versionin e Engine në biletë. Çdo heuristikë në pjesën tjetër të këtij udhëzuesi është e lidhur me versionin, dhe një pohim pa version është thashetheme.
Numëroni shpërndarjet që keni tashmë
Listoni rrjetet dhe pastaj inspektoni ato që kanë rëndësi: docker network ls, ndjekur nga docker network inspect NETWORK_NAME. Lexoni nënrrjetat IPAM dhe kontejnerët e lidhur me secilin. Disa projekte Compose konsumojnë më shumë blloqe sesa sugjeron numri i kontejnerëve të tyre, sepse çdo projekt priret të krijojë rrjetën e vet të paracaktuar. Një kontejner i ndalur nuk e lëshon shpërndarjen e rrjetës së tij.
Kontrolloni edhe konfigurimin e grupit, pasi një grup i paracaktuar ka një interval bazë dhe një madhësi prefiksi për rrjetë. Shpërndarjet e mëdha për rrjetë i shterojnë blloqet e disponueshme më shpejt, dhe ky është një fakt kapaciteti, jo një problem rrugëtimi.
Shkruani numrin. Është vija bazë që ju thotë nëse ndryshimi i radhës ndihmoi.
Krahasoni pamjen e daemonit për rrugët
Një VPN mund të ndikojë në përzgjedhjen e kandidatëve, por zbatimi i saktë vendos si. Në Moby 28.2.2 në Linux, InferReservedNetworks mbledh adresat e serverëve të emrave dhe disa rrugë IPv4 on-link, dhe nuk rezervon thjesht çdo rrugë nga çdo tabelë. Rrugët e lidhjes të mbledhura përjashtojnë gjithashtu një adresë destinacioni të papërcaktuar, kështu që një rrugë e vetme 0.0.0.0/1 nuk rezervon të gjitha adresat. Një prefiks tjetër i gjerë on-link, si 128.0.0.0/1, mund të presë intervalet e njohura kandidate 172 dhe 192.
Krahasoni ip -4 route show table all përpara dhe pasi VPN të lidhet, në hostin e daemonit. Delta është prova, dhe versioni është shtrirja e pohimit.
Mos e përgjithësoni heuristikën e një versioni në të gjitha versionet. Kështu një përgjigje forumi bëhet ndryshim politike.
Zgjidhni korrigjimin më të vogël që funksionon
Nëse një rrjetë e konfirmuar e papërdorur mban një bllok që ju nevojitet, planifikoni tërheqjen e saj të synuar me pronarin në vend që të krasitni gjerësisht. Për një rrjetë të re, një nënrrjetë e papërdorur e shqyrtuar shprehimisht shmang plotësisht varësinë nga përzgjedhja automatike. Ajo nënrrjetë duhet gjithsesi të shmangë destinacione reale Docker, LAN dhe VPN të kërkuara, sepse privat nuk do të thotë i sigurt. Rrugëtimi i një prefiksi real të largët do të shkëmbente gabimin e shpërndarjes me akses të prishur.
Ndryshimi i default-address-pools është një politikë më e gjerë për shpërndarjet e ardhshme. Zgjidhni një bazë pa konflikt dhe një madhësi të përshtatshme të shpërndarë, bashkojeni me cilësimet ekzistuese të daemonit dhe planifikoni ndikimin e dokumentuar të rinisjes. Rrjetat ekzistuese nuk rinumerosen në heshtje.
Mos i çaktivizoni shtytjet e rrugëve të kompanisë që shpërndarja të ketë sukses. Një plan adresash i qartë zakonisht e zgjidh problemin lokal pa dobësuar një politikë të detyrueshme.
Pranoni shpërndarjen dhe rrugëtimin veçmas
Pas ndryshimit, inspektoni nënrrjetën që Docker krijoi vërtet dhe testoni varësitë e aplikacionit nga VPN dhe ato lokale. Shpërndarja e suksesshme dhe rrugëtimi i saktë gjatë ekzekutimit janë dy kontrolle pranimi të ndryshme, dhe kalimi i të parit nuk është provë për të dytin. Nëse aplikacioni nuk arrin një burim pas tunelit, keni një problem rrugëtimi që gabimi i grupit e fshihte. Regjistroni të dyja rezultatet në biletë.
Ruani deltën e rrugëve dhe numrin e grupit bashkë me regjistrin e ndryshimit, sepse përditësimi i radhës i klientit VPN mund të ndryshojë të parin pa prekur Docker.
Udhëzuesi është i plotë kur dikush tjetër mund t’i përsërisë këto dy kontrolle dhe të marrë të njëjtën përgjigje.