VPN контейнеринин тармагын бөлүшүү: DNS менен эмне болот

VPN контейнеринин тармактык аталыш мейкиндигин бөлүшүү колдонмого туннелдин интерфейстерин жана маршруттарын берет. Ал ага туннелдин resolverин бербейт, ошондой эле хосттогу башка нерсенин бириктирилген көчүрмөсүн да бербейт. Бул боштук абдан конкреттүү бузулууну жаратат: коомдук аттар чечилет, ички аттар чечилбейт, жана ийгиликсиз болгон колдонмо туура эмес DNS серверин колдонуп жаткандай көрүнөт, анткени чындыгында ошондой. Оңдоо адатта диагностика сунуш кылгандан кичине болот.

1-кадам: Хосттон эмес, колдонмодон текшериңиз

Издөөнү көйгөйү бар контейнердин ичинде иштетиңиз, хостто да, браузерде да эмес. docker exec app-container getent hosts db.internal маанилүү жалгыз суроого жооп берет: бул процесстин resolverи эмнени кайтарат.

Эгер хост атты чечсе, ал эми контейнер чечпесе, сиз бузулууну таптыңыз. Андан кийинкинин баары аны оңдоонун колдоого алынган жолун тандоо.

2-кадам: Runtimeдын колдогон моделин окуңуз

Dockerдин тармак боюнча документтери башка контейнердин тармактык режимин бөлүшкөн контейнерлер үчүн DNS желегине карата чектөөлөрдү жазат. Composeдо network_mode: service:vpn колдонмону VPN контейнеринин аталыш мейкиндигине байланыштырат, ал эми ар бир кызмат үчүн dns жөндөөлөр кадимки кызматтагыдай аракет кылбайт. Сиз алган чечим — жалпы аталыш мейкиндигиндеги чечим.

Колдонуучу аныктаган көпүрө тармактары да Dockerдин курулган DNSин демейки көпүрөдөн башкача пайдаланат. Ошондуктан dns иштеп жаткан көпүрө мисалынан көчүрүлгөн пункт жалпы стекте такыр эч нерсе кылбашы мүмкүн. Пунктту көчүрүүдөн мурун тартипти текшериңиз.

Loopback дареги ар дайым тиешелүү тармактык контекстке шилтейт. Жалпы аталыш мейкиндигинин ичинде 127.0.0.1 хосттун resolverи эмес.

3-кадам: Сурамды анын алуучусуна чейин көзөмөлдөңүз

Колдонмонун resolver конфигурациясын, андан кийин колдонмо менен келген ар кандай колдонмого тиешелүү шифрленген DNSти окуңуз, анткени өз resolverин иштеткен колдонмо сиз түзөткөн файлды этибарга албайт. Андан кийин тандалган resolver VPNдин маршруттары жана firewall саясаты астында жеткиликтүүбү экенин текшериңиз. Туннелдин аркы тарабындагы resolver дареги, эгер аталыш мейкиндигинин ага маршруту жок болсо, пайдасыз. Ар кандай файлды түзөтүүдөн мурун алуучуну ырастаңыз.

Браузердеги IP текшерүү баракчасы ат сурамдары кайда кеткенин айта албайт. Ал бир HTTP байланышынын кайда кеткенин айтат.

4-кадам: Эки бузулуу классын өзүнчө оңдоңуз

Эгер кызмат аттары ийгиликсиз болуп, коомдук аттар иштеп жатса, көйгөй контейнердик тармактын ичиндеги кызматтарды табууда, коомдук resolver тизмесинде эмес. Ар бир коомдук DNS дарегин өзгөртүү тармактын табуу механизминен эч качан суралбаган жазууларды түзбөйт.

Эгер эки класс тең ийгиликсиз болсо, resolverге жеткиликтүүлүктөн баштаңыз. Эгер бирөө гана ийгиликсиз болсо, табуу механизминен баштаңыз. Экөөнүн ээлери башка, ошондуктан бир оңдоо экөөнү тең эч качан камтый албайт.

5-кадам: Кайра түзгөндөн кийин кайра текшериңиз

Конфигурацияны runtimeдын колдогон механизми аркылуу өзгөртүңүз, андан кийин иштеп жаткан контейнердин ичиндеги файлдарды түзөтүүнүн ордуна контейнерлерди кайра түзүңүз. Жаңы жеке атты, жаңы коомдук атты жана издөөдөн кийинки колдонмо сурамын текшериңиз. /etc/resolv.conf контейнердин ичиндеги түзөтүү кайра түзүүдө жоголот жана оңдоо иштебесе да иштеди деп ишендирет.

Resolverдин ээсин жана күтүлгөн аталыш мейкиндигин жалпы тармак аныктамасынын жанына жазыңыз. Кийинки адамга экөө тең керек болот.