Docker: VPN sesijos metu nebelieka iš anksto nustatytų adresų telkinių
Iš anksto nustatyto telkinio klaida susijusi su automatiniu priskyrimu, o ne su viešaisiais adresais. Suskaičiuokite priskyrimus, palyginkite on-link maršrutus ir išlaikykite VPN politiką nepakeistą.
Gedimas konkretus: Docker neranda priimtino automatinio potinklio naujam tiltiniam tinklui. Tai nereiškia, kad mašinai baigėsi adresai, ir nereiškia, kad VPN sugadintas. Diagnozę lemia du klausimai: kuriuos kandidatinius blokus demonas mato ir kuriuos iš jų jo paskirstytojas pašalina šioje aplinkoje. Nagrinėkite juos būtent tokia tvarka, nes antrasis klausimas neturi prasmės, kol neatsakytas pirmasis.
Patvirtinkite, kas nepavyko, prieš ką nors keisdami
Vykdykite toliau nurodytus veiksmus tame pagrindiniame kompiuteryje, kuriame veikia demonas. Apvalkalas, kalbantis su nuotoliniu kontekstu, aprašo kitą mašiną, ir vien ši klaida gali kainuoti valandą.
Tuo pačiu metu įrašykite Engine versiją į bilietą. Kiekviena šio vadovo heuristicė yra susieta su versija, o teiginys be versijos yra gandas.
Suskaičiuokite priskyrimus, kuriuos jau turite
Išvardykite tinklus, tada patikrinkite svarbiausius: docker network ls, po to docker network inspect NETWORK_NAME. Perskaitykite jų IPAM potinklius ir prie kiekvieno prijungtus konteinerius. Keli Compose projektai sunaudoja daugiau blokų, nei rodo jų konteinerių skaičius, nes kiekvienas projektas linkęs susikurti savo numatytąjį tinklą. Sustabdytas konteineris neatlaisvina savo tinklo priskyrimo.
Patikrinkite ir telkinio konfigūraciją, nes numatytasis telkinys turi bazinį diapazoną ir prefikso dydį vienam tinklui. Dideli priskyrimai vienam tinklui išsenka turimus blokus greičiau, ir tai yra talpos faktas, o ne maršrutizavimo problema.
Užsirašykite skaičių. Tai bazinė linija, kuri pasakys, ar padėjo kitas pakeitimas.
Palyginkite, kaip demonas mato maršrutus
VPN gali paveikti kandidatų pasirinkimą, bet kaip tiksliai – lemia konkreti realizacija. Moby 28.2.2 Linux sistemoje InferReservedNetworks renka vardų serverių adresus ir tam tikrus on-link IPv4 maršrutus ir ne šiaip rezervuoja kiekvieną maršrutą iš kiekvienos lentelės. Surinkti jungties maršrutai taip pat atmeta neapibrėžtą paskirties adresą, todėl vienas 0.0.0.0/1 maršrutas savaime nerezervuoja visų adresų. Kitas platus on-link prefiksas, pavyzdžiui 128.0.0.0/1, gali kirsti įprastus kandidatų diapazonus 172 ir 192.
Palyginkite ip -4 route show table all prieš VPN prisijungiant ir po to, demono pagrindiniame kompiuteryje. Skirtumas yra įrodymas, o versija yra teiginio apimtis.
Neapibendrinkite vienos versijos heuristicės visoms versijoms. Taip forumo atsakymas tampa politikos pakeitimu.
Pasirinkite mažiausią veikiantį pataisymą
Jei patvirtintas nenaudojamas tinklas laiko jums reikalingą bloką, planuokite tikslingą jo išėmimą kartu su savininku, o ne platų karpymą. Naujam tinklui aiškiai peržiūrėtas nenaudojamas potinklis visiškai išvengia priklausomybės nuo automatinio pasirinkimo. Tas potinklis vis tiek turi vengti tikrų Docker, LAN ir reikalingų VPN paskirčių, nes privatus nereiškia saugus. Tikro nuotolinio prefikso maršrutizavimas pakeistų priskyrimo klaidą į nutrūkusį prieinamumą.
default-address-pools keitimas yra platesnė politika dėl būsimų priskyrimų. Pasirinkite neprieštaraujančią bazę ir tinkamą priskirtą dydį, sujunkite ją su esamais demono nustatymais ir suplanuokite dokumentuotą perkrovimo poveikį. Esami tinklai tyliai nepernumeruojami.
Neišjunkite įmonės maršrutų siuntimo, kad priskyrimas pavyktų. Aiškus adresų planas paprastai išsprendžia vietinę problemą nesusilpnindamas privalomos politikos.
Priimkite priskyrimą ir maršrutizavimą atskirai
Po pakeitimo patikrinkite potinklį, kurį Docker iš tikrųjų sukūrė, ir išbandykite programos VPN bei vietines priklausomybes. Sėkmingas priskyrimas ir teisingas maršrutizavimas veikimo metu yra du skirtingi priėmimo patikrinimai, o pirmojo praėjimas nėra antrojo įrodymas. Jei programa negali pasiekti ištekliaus už tunelio, turite maršrutizavimo problemą, kurią telkinio klaida slėpė. Užrašykite abu rezultatus biliete.
Saugokite maršrutų skirtumą ir telkinio skaičių kartu su pakeitimo įrašu, nes kitas VPN kliento atnaujinimas gali pakeisti pirmąjį neliesdamas Docker.
Vadovas baigtas, kai kas nors kitas gali pakartoti šiuos du patikrinimus ir gauti tą patį atsakymą.