Docker: нэг контейнерийг VPN-ээр дамжуулж, нөгөөг нь шууд үлдээх

Нэг хост, хоёр ажлын ачаалал, тэднийг тусгаарлах нэг шаардлага: арилжааны VPN-ээс гарах ёстой татах клиент болон хостын холболтыг үргэлжлүүлэн ашиглах ёстой удирдлагын интерфейс. VPN клиентийг хост дээр суулгавал шаардлага тэр даруй зөрчигдөнө, учир нь тэр үед хоёр ачаалал нэг гарцыг хуваалцана. Үнэхээр ажилладаг загвар нь туннелийг өөрийн контейнерт шилжүүлж, түүнд хэрэгтэй ачаалуудад л тэр контейнерийн сүлжээний нэрийн орон зайд нэгдэх боломж олгох. Бусад бүхэн ердийн Docker замыг хадгалж, дараах дэлгэрэнгүй мэдээлэл нь нэрийн орон зайг хэн эзэмшиж байгаагийн үр дагавар юм.

Хуваалцсан нэрийн орон зай яагаад дүрмийг өөрчилдөг

Өөр контейнерийн нэрийн орон зайд нэгдсэн контейнер өөрийн сүлжээний стек авдаггүй. Тэр нэгдсэн контейнерын адил интерфейс, адил чиглүүлэлтийн хүснэгт, адил loopback-ыг хардаг, яг ийм учраас энэ загвар ашигтай: ачаалал ердийн байдлаар шийдэж холбогдож, доорх туннель програмын мэдэлгүйгээр урсгалыг барьж авдаг. Үнэ нь сүлжээний тохиргоо бүр одоо нэг эзэнтэй болж, нэгдэж буй контейнер тэр эзэн нь биш юм.

Энэ өмчлөлийн дүрэм тохиргооны ихэнх асуултад тэдгээрийг тавихаас өмнө хариулдаг. Тохиргоо сүлжээний стек дотор амьдардаг бол хажуугийн контейнерынх. Хэрэв процессыйг дүрсэлдэг бол ачаалалтайгаа үлддэг.

loopback бол хүмүүсийг гайхшруулдаг хэсэг. Нэгдэж буй контейнерын дотор localhost хажуугийн контейнерын loopback руу шийдэгддэг, өөрийн хувийн loopback руу биш, тиймээс 127.0.0.1-д холбогдож тусгаарлалт хүлээж буй үйлчилгээ одоо тэр хаягийг туннелийн контейнертой хуваалцаж байна.

Нэрийн орон зайг эзэмшдэг контейнер дээр портуудыг нийтлээрэй

Портын зураглал нь сонсож буй процесс өөр контейнерт ажиллаж байсан ч нэрийн орон зайн эзэмшигчид хамаарна. Зураглалыг хажуугийн контейнер дээр зарлаж, ачаалал өөрийн процессын тохиргоог хөндөгдөөгүй байлгаарай. Нэгдэж буй үйлчилгээн дээрх зураглал хүчин төгөлдөр болж чадахгүй, хөдөлгүүр үүнийг татгалзсан ч, контейнер хэрхэн эхлэхээс хамаарч чимээгүй үл хэрэгсэх ч, ийм учраас агшин өмнө хүрч боломжтой байсан интерфейс загварыг хэрэглэсэн даруйд алга болдог.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Энэ блокыг гурван үйлчилгээ биш, гурван шийдвэр гэж уншаарай. Хажуугийн контейнер туннель болон нийтэлсэн портыг эзэмшдэг; нэгдэж буй клиент ямар ч сүлжээ зарладаггүй; шууд клиент өөрийн зураглалыг үндсэн сүлжээнд хадгалдаг. Чадамж NET_ADMIN нь хажуугийн контейнерт интерфейс үүсгэх, чиглүүлэлт өөрчлөх боломж олгодог зүйл бөгөөд энэ контейнер өөрөө үйлчилдэг ачаалуудаас илүү эрх шаарддаг шалтгаан нь мөн энэ юм.

Шууд үлдэх үйлчилгээ өөрийн сүлжээгээ хадгална

Туннелээр орох ёсгүй ачаалал үндсэн гүүр эсвэл өөрийн хэрэглэгчийн тодорхойлсон сүлжээг өөрийн нийтэлсэн порт, өөрийн гарцтайгаа хадгална. Хоёр контейнер нэрээр ярих боломжтой болгохын тулд үүнийг хажуугийн контейнерын сүлжээнд холбох уруу татагддаг ч тэр нэг алхам урсгалыг чимээгүйгээр туннель руу шилжүүлдэг. Хэрэв тэд бие биедээ хүрэх шаардлагатай бол тусдаа хэрэглэгчийн тодорхойлсон сүлжээ байгуулж, хоёуланг нь түүнтэй холбож, хажуугийн контейнерийг гадагш гарах цорын ганц зам болгон үлдээгээрэй.

Хоёр асуултыг тусад нь байлгаарай: аль контейнерууд бие биедээ хүрч чадах, аль нь хаанаас гардаг. Тэдгээрийг нэгтгэх нь энэ дизайн дахин бүх хост хамарсан VPN болох хамгийн нийтлэг арга юм.

Эхний цагийн алдааны матриц

Эхний оролдлогын ихэнх нь дөрвөн аргаын нэгээр бүтэлгүйтдэг бөгөөд тус бүр өөр шалтгаантай. Тэдгээрийг энэ дарааллаар шалгаарай, учир нь эхний хоёр нь бараг бүх тайланг тайлбарладаг.

Дөрөв дэх мөр нь хүмүүс програмын алдаа гэж буруу оношилдог мөр юм. Ачааллын өөрийн loopback-ын эсрэг бичсэн шалгалт одоо туннелийн контейнерийг шалгаж байгаа тул эсвэл бүтэлгүйтэх, эсвэл огт буруу үйлчилгээний тухай мэдээлнэ.

Нэг хотын нэр туннель шаардах үед

Заримдаа бүрэн туннель хэтэрхий их: нэг дотоод нэр корпорацийн VPN-ээр гарах ёстой, харин локал сокет эсвэл дэлгэцийн холболт үргэлжлэн ажиллана. Контейнер доторх бүрэн туннель тэр замыг болон хост руу хаягласан бүхнийг эвддэг тул зөвхөн хэрэгтэй префиксийг чиглүүлээрэй. Клиентийг тойрсон хуваагдсан чиглүүлэлтийн бүрхүүл үүнийг хийдэг, нэрлэсэн хотыг туннелээр явуулж, бусад бүхэнд өмнөх замыг хөндөгдөөгүй үлдээдэг.

Зөвхөн нэг үйлчилгээнд хүрэх шаардлагатай бөгөөд контейнерын бүх урсгалыг шилжүүлэх гэж оролдохгүй байгаа үед үүнийг сонгоорой. Энэ нь хажуугийн контейнерээс өөр хэрэгсэл бөгөөд өөр асуултад хариулдаг.

Шалгаад, дараа нь дахин эхлэхэд тэсвэртэй болгоорой

Контейнер бүрээс ямар хаягаас ирж байгаа мэт харагдаж байгааг асуугаарай. Туннель доторх нь нийлүүлэгчийн хаягийг, шууд нь хостын гарцыг хэвлэх ёстой. Ижил хариулт нь шууд үйлчилгээ буруу нэрийн орон зайг өвлөсөн эсвэл хост түвшний VPN одоо ч бүгдийг барьж байгаа гэсэн үг бөгөөд эдгээр хоёр засвар өөр юм. compose-ийн өөрчлөлт бүрийн дараа шалгалтыг дахин ажиллуулаарай, учир нь нэг хуулагдсан үйлчилгээний блок асуудлыг буцаахад хангалттай.

Гурван зүйл дараа нь эвдрэх хандлагатай. DNS нэрийн орон зайн эзэмшигчийг дагадаг тул шийдэгч болон хайлтын домэйны тохиргоо хост дээр биш, хажуугийн контейнер дээр байх ёстой. Порт дамжуулалттай VPN дахин холбогдох үед сонсох портоо өөрчилдөг тул нийлүүлэгчийн дамжуулсан порт болон контейнер талын сонсох портыг клиентийн тохиргоо эсвэл портын зураглалд буцааж бичих ёстой, ихэвчлэн нийлүүлэгчийн API-г уншдаг жижиг шинэчлэгчээр. Мөн localhost-ийн эсрэг бичсэн аливаа шалгалт одоо ачаалал биш туннелийн контейнерээс асуудаг.

Загварыг бичиж үлдээгээрэй, аль контейнер нэрийн орон зайг эзэмшиж, ямар портууд түүнд хамаарахыг оруулан. Дараагийн хүн үйлчилгээ нэмж, буруу блокыг хуулж, энэ нийтлэлийн эхний алдааг дахин үүсгэх болно.