Dev Container зөвхөн VPN-оор хүрэх хостоос хүрч чадахгүй байна: хаанаас харах вэ

Хувийн API таны ширээний хөтөч дээр нээгдэх боловч хөгжүүлэлтийн контейнерт бүтэлгүйтдэг. Энэ нь зөрчил биш бөгөөд шалтгаан нь VPN өөрөө байх нь ховор. Хөтчийн хүсэлт болон бүтэлгүйтсэн хүсэлтийг өөр өөр процессууд гаргасан, өөр өөр resolver, proxy, маршруттай, ихэнхдээ огт өөр сүлжээний нэрийн орон зайгаас. «Миний зөөврийн компьютер дээр» гэдэг нь Windows хост, WSL түгээлт, Docker Desktop виртуал машин болон тэр VM доторх контейнер байж болно — нэг хост нэрэнд тус бүр өөр хариулт өгч болох дөрвөн контекст. Нэг ч тохиргоог хүрэхээс өмнө аль процессыг ашиглаж байгааг тодорхойл.

Тохиргоог өөрчлөхөөс өмнө процессыг ол

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

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows дээр wsl -l -v түгээлт WSL 2-ийн доор ажиллаж байгаа эсэхийг хэлнэ, энэ нь түүнийг өөрийн виртуал шилжүүлэгчийн ард байрлуулна. Энэ дэлгэрэнгүй мэдээлэл контейнер хостын маршрутын хүснэгтийг хуваалцаж байгаа эсэх, эсвэл хостод хүрэхийн тулд дамжуулсан порт эсвэл хост нэр шаарддаг NAT-ын ард байгаа эсэхийг шийднэ.

Нэг хүсэлтийг тогтвортой байлгаж харьцуул

Хувийн хост дээр нэг хор хөнөөлгүй төгсгөлийн цэг сонгоод бүх харьцуулалтад ашигла: хөтчөөс, хостын терминалаас, WSL түгээлтээс болон контейнерын дотроос. Оролдлого бүрт дөрвөн зүйл тэмдэглэ: шийдэгдсэн хаяг, proxy ашигласан эсэх, алдааны ангилал болон өнгөрсөн хугацаа. Нэр хайх, холболт тогтоох, TLS баталгаажуулах, HTTP төлөв нь дөрвөн өөр асуудал бөгөөд тэдгээрийг «ажиллахгүй байна» гэж хольсон нь нэг өглөөг үрэгдүүлдэг.

Харьцуулалтыг бүтэлгүйтэж буй контейнерын дотор, таймауттай хий, ингэснээр чимээгүй галт хана терминалыг хэдэн минутад барихгүй. Шинэ контейнер хөдөлгүүрийн сүлжээний контекстийг дахин үүсгэдэг ч аппликейшн контейнерын нэрийн орон зай, proxy хувьсагч, resolver-ыг биш, тиймээс жинхэнэ контейнер руу docker exec хийх нь эрх мэдэлтэй тест бөгөөд хажуугийн контейнер нь ялгаа хөдөлгүүрт эсвэл контейнерт байгаа эсэхийг тусгаарлах арга л юм:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine үндсэн дүрс busybox-той, curlгүй бөгөөд яг ийм дэлгэрэнгүй мэдээлэл хуулсан диагностик блокыг бүтэлгүйтүүлдэг: клиенттэй дүрс сонго эсвэл нэг ажиллуулалтад нэм. Холбоогүй нийтийн сайтуудтай харьцуулах нь юу ч тусгаарлахгүй. Хэрэв контейнероос https://example.com ажиллаж байвал контейнер интернэт хандалттай гэдгийг л мэдсэн бөгөөд туннелээр хувийн хаягт хүрч байгаа эсэхийг мэдэхгүй. Мөн адил шинэ терминал нээх нь шинэ терминал ажиллаж байгааг л батална, бүтэлгүйтсэн аппликейшнтэй нэг ажиллуулах орчныг хуваалцаж байгааг биш.

Docker Desktop VPN-тэй ажиллаж чадна

Docker-ийн өөрийн VPN болон хосттой холбогдох тухай баримт бичиг үүнийг дэмжигдсэн тохиргоо гэж тодорхойлдог бөгөөд шударга дүгнэлт нь автоматаар эвдэрдэггүй, ажилладаг гэсэн үг. Ширээний VM нь хостны туннелийг зохион бүтээлээрээ тойрч гардаг гэж бүү бод. Олон тохиргоонд урсгал хостны туннелийг зөв дагадаг, тиймээс «Docker VPN-ийг үл тоомсорлодог» гэсэн домог итгэлтэй боловч буруу зөвлөгөө өгдөг.

Одоо ч чухал зүйл бол ашиглаж буй backend, клиентийн split-tunnel бодлого, VM-ийн хүлээн авсан resolver тохиргоо. Маршрут суулгадаг ч DNS суулгадаггүй, эсвэл VM-ийн хүрч чадахгүй DNS сервер түлхдэг VPN клиент контейнерын дотор нэр хайлтын алдаа үүсгэдэг бол хост нь нэмэлт resolver эсвэл кэшлэсэн хариулттай тул ажилладаг. Энэ бол контейнерын хувцастай resolver-ын асуудал. Таны оролдсон VPN-ийн дахин холболт бүрийг даван туулдаг, учир нь туннель таны хүссэн урсгалыг аль хэдийн зөөж байгаа.

Хаягийн давхцал ба MTU нь өөр өөр эвдрэл

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

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

Давхцлын шийдэл нь хаягийн төлөвлөгөөний эзэн сонгох өөр контейнерын дэд сүлжээ эсвэл хязгаарлагдмал маршрут юм. MTU гацлын шийдэл нь туннель эсвэл интерфэйсийн MTU-г замаар тэсвэрлэх утга хүртэл чангалах эсвэл багасгах бөгөөд үүнийг өөрийн хянадаг давхаргад хэрэглэнэ.

Proxy тохиргоо нь машин бус процесс тус бүрт

Контейнерын дотор localhost тэр контейнерын өөрийн сүлжээний контекстийг нэрлэдэг тул хост дээр ажиллаж буй proxy тэнд тэр нэрээр хүрэхгүй. Docker Desktop хостод хандахын тулд host.docker.internal-г өгдөг бөгөөд Linux дээр та үүнийг --add-host=host.docker.internal:host-gateway-ээр тодорхой нэмнэ. Ямар ч тохиолдолд тэр нэр танд хост руу маршрут өгдөг; энэ нь proxy үйлчилгээ үүсгэхгүй бөгөөд ашиглах эрх ч өгөхгүй.

Бодит орчинд зориулж өгсөн proxy хаяг, портыг ашиглаж, хэн уншиж байгааг шалга. Интерактив shell-д экспортолсон хувьсагчид засварчийн бүх өргөтгөл, хэлний сервер, build хэрэгсэл, арын дэмоныг автоматаар тохируулдаггүй. Чухал нь бүтэлгүйтсэн хүсэлтийг гаргасан процесс тул өөрийн терминалын бус, түүний орчныг шалга.

Эцэст нь засвар өөрөө өөрийгөө тайлбарла. Ашигтай шийдэл нь буруу байсан хил, түүнийг өөрчилсөн тохиргоо, одоо нөлөөлж буй процессуудын багцыг нэрлэдэг. VPN, засварчин, хөдөлгүүрийг дараалан дахин эхлүүлэх нь шинж тэмдгийг өөрчилж болох ч дараагийн хүнд хэрэглэгдэх юу ч үлдээхгүй.