VPN konteinerio tinklo bendrinimas: kas nutinka DNS

VPN konteinerio tinklo vardų erdvės bendrinimas suteikia programai tunelio sąsajas ir maršrutus. Ji nesuteikia jai tunelio resolverio, nei sujungtos kopijos ko nors kito hoste. Šis skirtumas sukuria labai konkrečią gedimą: vieši vardai išsprendžiami, vidiniai ne, o nepavykstanti programa atrodo naudojanti netinkamą DNS serverį, nes taip ir daro. Taisymas paprastai būna mažesnis, nei rodo diagnozė.

1 žingsnis: testuokite iš programos, o ne iš hosto

Vykdykite paiešką konteinerio, kuriame yra problema, viduje, o ne hoste ir ne naršyklėje. docker exec app-container getent hosts db.internal atsako į vienintelį svarbų klausimą: ką grąžina šio proceso resolveris.

Jei hostas išsprendžia vardą, o konteineris ne, radote gedimą. Viskas po to yra palaikomo taisymo būdo pasirinkimas.

2 žingsnis: perskaitykite palaikomą runtime modelį

Docker tinklo dokumentacija fiksuoja DNS vėliavėlių apribojimus konteineriams, kurie bendrina kito konteinerio tinklo režimą. Compose network_mode: service:vpn susieja programą su VPN konteinerio vardų erdve, o kiekvienai paslaugai dns nustatymai nesielgia taip, kaip įprastoje paslaugoje. Sprendimas, kurį gaunate, yra tas, kurį turi bendrinama vardų erdvė.

Vartotojo apibrėžti tiltiniai tinklai taip pat naudoja Docker įtaisytąjį DNS kitaip nei numatytasis tiltas. Štai kodėl dns punktas, nukopijuotas iš veikiančio tilto pavyzdžio, bendriname kamine gali nepadaryti visiškai nieko. Patikrinkite tvarką prieš kopijuodami punktą.

Loopback adresas visada nurodo atitinkamą tinklo kontekstą. Bendrinamoje vardų erdvėje 127.0.0.1 nėra hosto resolveris.

3 žingsnis: sekite užklausą iki jos gavėjo

Perskaitykite programos resolverio konfigūraciją, tada bet kokį programai būdingą šifruotą DNS, kurį ji atsineša, nes programa, vykdanti savo resolverį, nepaiso failo, kurį redagavote. Tada patikrinkite, ar pasirinktas resolveris pasiekiamas pagal VPN maršrutus ir užkardos politiką. Resolverio adresas kitoje tunelio pusėje yra bevertis, jei vardų erdvė neturi maršruto į jį. Patvirtinkite gavėją prieš redaguodami bet kurį failą.

Naršyklės IP patikros puslapis negali pasakyti, kur nuėjo vardų užklausos. Jis pasako, kur nuėjo viena HTTP jungtis.

4 žingsnis: ištaisykite dvi gedimų klases skirtingai

Jei paslaugų vardai nepavyksta, o vieši vardai veikia, problema yra paslaugų aptikimas konteinerių tinkle, o ne viešų resolverių sąrašas. Kiekvieno viešo DNS adreso keitimas nesukurs įrašų, kurių tinklo aptikimo mechanizmas niekada nebuvo paprašytas sukurti.

Jei nepavyksta abi klasės, pradėkite nuo resolverio pasiekiamumo. Jei nepavyksta tik viena, pradėkite nuo aptikimo mechanizmo. Abi turi skirtingus savininkus, todėl vienas taisymas niekada neapima abiejų.

5 žingsnis: iš naujo patikrinkite po atkūrimo

Pakeiskite konfigūraciją palaikomu runtime mechanizmu, tada iš naujo sukurkite konteinerius, o ne redaguokite failus veikiančiame. Išbandykite naują privatų vardą, naują viešą vardą ir programos užklausą, kuri seka po paieškos. /etc/resolv.conf konteinerio viduje atliktas pakeitimas dingsta atkūrus ir įtikins jus, kad taisymas veikė, kai jis neveikė.

Užrašykite resolverio savininką ir numatomą vardų erdvę prie bendrinamo tinklo apibrėžimo. Kitam žmogui prireiks abiejų.