VPN контейнерийн сүлжээг хуваалцах: DNS-д юу тохиолддог
Хуваалцсан нэрийн орон зай апп-д туннелийн интерфейсүүдийг өгдөг, нэгтгэсэн resolver биш. Апп-ын дотроос туршаад runtime дэмждэг 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-ийн эзэмшигч болон хүлээгдэж буй нэрийн орон зайг хуваалцсан сүлжээний тодорхойлолтын хажууд бичээрэй. Дараагийн хүнд хоёулаа хэрэгтэй болно.