VPN контейнерінің желісін бөлісу: DNS-ке не болады

VPN контейнерінің желілік атау кеңістігін бөлісу қосымшаңызға туннельдің интерфейстері мен маршруттарын береді. Ол оған туннельдің resolver-ін бермейді, hostтағы кез келген басқа нәрсенің біріктірілген көшірмесін де бермейді. Бұл алшақтық өте нақты ақау тудырады: жалпыға ортақ атаулар шешіледі, ішкі атаулар шешілмейді, ал сәтсіздікке ұшыраған қосымша дұрыс емес DNS серверін қолданып тұрғандай көрінеді, өйткені шынымен солай. Жөндеу әдетте диагностика ұсынғаннан кішірек болады.

1-қадам: Hostтан емес, қосымшадан тексеріңіз

Іздеуді мәселесі бар контейнердің ішінде орындаңыз, hostта да, браузерде де емес. docker exec app-container getent hosts db.internal маңызды жалғыз сұраққа жауап береді: бұл процестің resolver-і не қайтарады.

Егер host атауды шешсе, ал контейнер шешпесе, ақауды таптыңыз. Одан кейінгінің бәрі оны түзетудің қолдау көрсетілген жолын таңдау.

2-қадам: Runtime-ның қолдайтын моделін оқыңыз

Docker-дің желі туралы құжаттамасы басқа контейнердің желілік режимін бөлісетін контейнерлер үшін DNS жалаушаларына қатысты шектеулерді жазады. Compose-та network_mode: service:vpn қосымшаны VPN контейнерінің атау кеңістігіне байланыстырады, ал әр қызмет үшін dns параметрлер қарапайым қызметтегідей әрекет етпейді. Сіз алатын шешім — ортақ атау кеңістігінде бар шешім.

Пайдаланушы анықтаған көпірлік желілер де Docker-дің кірістірілген DNS-ін әдепкі көпірден өзгеше пайдаланады. Сондықтан dns жұмыс істеп тұрған көпір мысалынан көшірілген тармақ ортақ стекте мүлде ештеңе істемеуі мүмкін. Тармақты көшіру алдында тәртіпті тексеріңіз.

Loopback мекенжайы әрқашан тиісті желілік контекстіге сілтейді. Ортақ атау кеңістігінің ішінде 127.0.0.1 hostтың resolver-і емес.

3-қадам: Сұраулы оның алушысына дейін қадағалаңыз

Қосымшаның resolver конфигурациясын, содан кейін қосымша әкелетін кез келген қосымшаға тән шифрланған DNS-ті оқыңыз, өйткені өз resolver-ін іске қосатын қосымша сіз өңдеген файлды елемейді. Содан кейін таңдалған resolver-дің VPN маршруттары мен firewall саясаты аясында қолжетімді екенін тексеріңіз. Туннельдің арғы жағындағы resolver мекенжайы, егер атау кеңістігінің оған маршруты болмаса, пайдасыз. Кез келген файлды өңдеу алдында алушыны растаңыз.

Браузердегі IP тексеру беті атау сұрауларының қайда кеткенін айта алмайды. Ол бір HTTP қосылысының қайда кеткенін айтады.

4-қадам: Екі ақау класын бөлек түзетіңіз

Егер қызмет атаулары сәтсіздікке ұшырап, жалпыға ортақ атаулар жұмыс істесе, мәселе контейнерлік желінің ішіндегі қызметтерді табуда, жалпыға ортақ resolver тізімінде емес. Әрбір жалпыға ортақ DNS мекенжайын өзгерту желінің табу механизмінен ешқашан сұралмаған жазбаларды жасамайды.

Егер екі класс та сәтсіздікке ұшыраса, resolver-ге қолжетімділіктен бастаңыз. Егер тек біреуі сәтсіз болса, табу механизмінен бастаңыз. Екеуінің иелері әртүрлі, сондықтан бір жөндеу екеуін де ешқашан қамтымайды.

5-қадам: Қайта жасағаннан кейін қайта тексеріңіз

Конфигурацияны runtime-ның қолдайтын механизмі арқылы өзгертіңіз, содан кейін жұмыс істеп тұрған контейнердің ішіндегі файлдарды өңдеудің орнына контейнерлерді қайта жасаңыз. Жаңа жеке атауды, жаңа жалпыға ортақ атауды және іздеуден кейінгі қосымша сұрауын тексеріңіз. /etc/resolv.conf контейнердің ішіндегі өңдеу қайта жасау кезінде жоғалады және жөндеу жұмыс істемегенде жұмыс істеді деп сендіреді.

Resolver иесін және күтілетін атау кеңістігін ортақ желі анықтамасының жанына жазыңыз. Келесі адамға екеуі де қажет болады.