Docker: VPN-seansi ajal ei jää alles ühtegi eelmääratud aadressikogumit

Viga on konkreetne: Docker ei leia uue sildvõrgu jaoks vastuvõetavat automaatset alavõrku. See ei tähenda, et masinal on aadressid otsas, ega seda, et VPN on katki. Diagnoosi otsustavad kaks küsimust: milliseid kandidaatblokke deemon näeb ja millised neist tema eraldaja selles keskkonnas välistab. Käige need läbi just selles järjekorras, sest teisel küsimusel pole mõtet enne, kui esimesele on vastatud.

Kinnitage, mis ebaõnnestus, enne kui midagi muudate

Käivitage allolevad sammud hostil, mis deemonit käitab. Kaugkõne kontekstiga suhtlev kest kirjeldab teist masinat ja ainuüksi see viga võib kulutada tunni.

Märkige samal ajal piletile Engine'i versioon. Iga heuristika ülejäänud juhendis on versioonipõhine ja versioonita väide on kuulujutt.

Loendage eraldamised, mis teil juba on

Loetlege võrgud ja seejärel uurige olulisi: docker network ls, millele järgneb docker network inspect NETWORK_NAME. Lugege nende IPAM-i alavõrke ja igasse ühendatud konteinerid. Mitmed Compose'i projektid tarbivad rohkem blokke, kui nende konteinerite arv vihjab, sest iga projekt kipub looma oma vaikevõrgu. Peatatud konteiner ei vabasta oma võrgu eraldist.

Kontrollige ka kogumi konfiguratsiooni, sest vaikekogumil on baasvahemik ja võrgu kohta eesliite suurus. Suured eraldised võrgu kohta ammendavad saadaolevad blokid kiiremini ja see on mahutavuse fakt, mitte marsruutimise probleem.

Kirjutage arv üles. See on baasjoon, mis ütleb, kas järgmine muudatus aitas.

Võrrelge deemoni vaadet marsruutidele

VPN võib kandidaatide valikut mõjutada, kuid täpne teostus otsustab, kuidas. Versioonis Moby 28.2.2 Linuxil kogub InferReservedNetworks nimeserveri aadresse ja teatud on-link IPv4 marsruute ega reserveeri lihtsalt iga marsruuti igast tabelist. Kogutud lingi marsruudid välistavad ka määramata sihtaadressi, seega üksi 0.0.0.0/1 marsruut ei reserveeri kõiki aadresse. Teine lai on-link eesliide, näiteks 128.0.0.0/1, võib lõigata tuttavaid kandidaatvahemikke 172 ja 192.

Võrrelge ip -4 route show table all enne ja pärast VPN-i ühendamist deemoni hostil. Erinevus on tõend ja versioon on väite ulatus.

Ärge üldistage ühe väljalaske heuristikat kõikidele väljalasetele. Nii saab foorumivastusest poliitikamuudatus.

Valige väikseim parandus, mis töötab

Kui kinnitatud kasutamata võrk hoiab blokki, mida vajate, planeerige selle sihitud kasutusest kõrvaldamine koos omanikuga, mitte laialdane kärpimine. Uue võrgu jaoks väldib selgesõnaliselt üle vaadatud kasutamata alavõrk täielikult automaatse valiku sõltuvust. See alavõrk peab siiski vältima tegelikke Dockeri, LAN-i ja nõutavaid VPN-i sihtkohti, sest privaatne ei tähenda turvalist. Tegeliku kaugprefiksi marsruutimine vahetaks eraldamisvea katkise juurdepääsu vastu.

default-address-pools muutmine on laiem poliitika tulevaste eraldamiste kohta. Valige mittevastuoluline baas ja sobiv eraldatud suurus, ühendage see olemasolevate deemoni seadetega ja planeerige dokumenteeritud taaskäivituse mõju. Olemasolevaid võrke ei nummerdata vaikselt ümber.

Ärge lülitage välja ettevõtte marsruutide tõukamist, et eraldamine õnnestuks. Selgesõnaline aadressiplaan lahendab tavaliselt kohaliku probleemi kohustuslikku poliitikat nõrgendamata.

Võtke eraldamine ja marsruutimine eraldi vastu

Pärast muudatust uurige alavõrku, mille Docker tegelikult lõi, ja testige rakenduse VPN-i ja kohalikke sõltuvusi. Edukas eraldamine ja õige marsruutimine tööajal on kaks erinevat vastuvõtukontrolli ning esimese läbimine ei ole tõend teise kohta. Kui rakendus ei pääse tunnelitagusele ressursile ligi, on teil marsruutimisprobleem, mille kogumi viga peitis. Kirjutage mõlemad tulemused piletile.

Hoidke marsruutide erinevus ja kogumi arv koos muudatuse kirjega, sest järgmine VPN-kliendi uuendus võib muuta esimest Dockerit puutumata.

Juhend on täielik siis, kui keegi teine saab need kaks kontrolli korrata ja saada sama vastuse.