VPN konteinera tīkla kopīgošana: kas notiek ar DNS

VPN konteinera tīkla nosaukumu telpas kopīgošana dod lietotnei tuneļa saskarnes un maršrutus. Tā nedod tai tuneļa resolveri, ne arī apvienotu kopiju kaut kam citam uz resursdatora. Šī plaisa rada ļoti konkrētu kļūmi: publiskie nosaukumi tiek atrisināti, iekšējie netiek, un nespējīgā lietotne izskatās, ka izmanto nepareizu DNS serveri, jo tā tiešām dara. Labojums parasti ir mazāks, nekā liek domāt diagnostika.

1. solis: pārbaudiet no lietotnes, nevis no resursdatora

Palaidiet meklēšanu konteinerā, kuram ir problēma, nevis uz resursdatora un ne pārlūkā. docker exec app-container getent hosts db.internal atbild uz vienīgo svarīgo jautājumu: ko atgriež šī procesa resolvers.

Ja resursdators atrisina nosaukumu, bet konteiners ne, jūs esat atradis kļūmi. Viss pēc tam ir atbalstīta labošanas veida izvēle.

2. solis: izlasiet runtime atbalstīto modeli

Docker tīkla dokumentācija reģistrē ierobežojumus DNS karodziņiem konteineriem, kas kopīgo cita konteinera tīkla režīmu. Compose network_mode: service:vpn piesaista lietotni VPN konteinera nosaukumu telpai, un katram pakalpojumam dns iestatījumi neuzvedas tā, kā parastā pakalpojumā. Risinājums, ko iegūstat, ir tas, kas ir kopīgajai nosaukumu telpai.

Lietotāja definētie tilta tīkli arī izmanto Docker iebūvēto DNS citādi nekā noklusējuma tilts. Tāpēc dns klauzula, kas nokopēta no strādājoša tilta piemēra, kopīgā stekā var neizdarīt absolūti neko. Pirms klauzulas kopēšanas pārbaudiet sakārtojumu.

Loopback adrese vienmēr attiecas uz attiecīgo tīkla kontekstu. Kopīgā nosaukumu telpā 127.0.0.1 nav resursdatora resolvers.

3. solis: sekojiet vaicājumam līdz tā saņēmējam

Izlasiet lietotnes resolvera konfigurāciju, pēc tam jebkuru lietotnei raksturīgu šifrētu DNS, ko tā piedāvā, jo lietotne, kas darbojas ar savu resolveri, ignorē failu, kuru rediģējāt. Pēc tam pārbaudiet, vai izvēlētais resolvers ir sasniedzams VPN maršrutos un ugunsmūra politikā. Resolvera adrese tuneļa otrā pusē ir bezjēdzīga, ja nosaukumu telpai nav maršruta uz to. Apstipriniet saņēmēju pirms jebkura faila rediģēšanas.

Pārlūka IP pārbaudes lapa nevar pateikt, kur aizgāja nosaukumu vaicājumi. Tā pasaka, kur aizgāja viens HTTP savienojums.

4. solis: labojiet abas kļūmju klases atšķirīgi

Ja pakalpojumu nosaukumi neizdodas, kamēr publiskie nosaukumi darbojas, problēma ir pakalpojumu atklāšanā konteineru tīklā, nevis publisko resolveru sarakstā. Katras publiskās DNS adreses maiņa neizveidos ierakstus, kuru izveidi tīkla atklāšanas mehānismam nekad nav lūgts veikt.

Ja neizdodas abas klases, sāciet ar resolvera sasniedzamību. Ja neizdodas tikai viena, sāciet ar atklāšanas mehānismu. Abām ir dažādi īpašnieki, tāpēc viens labojums nekad neaptver abas.

5. solis: pēc atjaunošanas pārbaudiet vēlreiz

Mainiet konfigurāciju ar runtime atbalstīto mehānismu, pēc tam izveidojiet konteinerus no jauna, nevis rediģējiet failus darbojošā konteinerā. Pārbaudiet jaunu privātu nosaukumu, jaunu publisku nosaukumu un lietotnes pieprasījumu, kas seko meklēšanai. /etc/resolv.conf konteinera iekšienē veikts labojums pazūd atjaunošanas laikā un pārliecinās jūs, ka labojums darbojās, kad tas nedarbojās.

Pierakstiet resolvera īpašnieku un gaidīto nosaukumu telpu blakus kopīgā tīkla definīcijai. Nākamajai personai būs vajadzīgi abi.