Docker VPN контейнероор хост трафикийг хэрхэн чиглүүлэх вэ

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

Таны туннель контейнер ажиллаж байна, docker compose exec vpn curl -s https://ifconfig.me нийлүүлэгчийн хаягаар хариулж байна, гэсэн хэдий ч таны ширээний компьютер дээрх хөтөч ISP-ээр гарсаар байна. Энэ зөрүү хүлээгдэж байна. VPN клиент ажиллуулдаг контейнер нь сүлжээний нэрийн орон зай, маршрут, туннелийн интерфейс хадгалдаг бөгөөд HTTP эсвэл SOCKS ярьдаг зүйл байхгүй; түүн дээр порт нийтлэх нь хэзээ ч байгаагүй сонсогчийг үүсгэж чадахгүй.

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

Зохион байгуулалтыг клиент ажиллах газартай тохируулна уу

Compose-ыг засахын өмнө нэг асуулт асуугаарай: клиентийг VPN контейнерын сүлжээний нэрийн орон зайд эхлүүлж болох уу? Linux контейнер хэлбэрээр ажиллаж байгаа бүхэн чадна. Ширээн дээрх хөтөч, IDE эсвэл CLI чадахгүй, учир нь түүний прокси тохиргоо протоколын үйлчилгээг хүлээж байгаа бөгөөд нэрийн орон зайг биш.

ClientArrangementWhat must already exist
Another Compose serviceShares the vpn namespace via network_mode: service:vpnA working tunnel and correct start order
Host browser, IDE or CLIProxy listener inside the namespace, published to host loopbackA configured SOCKS or HTTP proxy and its access rules
Router, VM or phoneThe container as a layer-3 gatewayForwarding, NAT and a return route

Эдгээр гурав холилдохгүй. Контейнерын гүүрэн хаяг руу чиглэсэн HTTP прокси талбар тэнд прокси сонсохгүй бол юунд ч хүрэхгүй, прокси сонсогч нь маршрутлагчийн трафикийг чиглүүлэхгүй. Эхлээд шийдээд, дараа нь тохирох хэсгийг дагана уу.

Туннелийн нэрийн орон зайг хажуугийн контейнертой хуваалцана уу

Энэ нь хамгийн хямд сонголт, учир нь прокси протокол оролцохгүй. Апп нь vpn үйлчилгээний нэрийн орон зайд нэгдэж, түүний интерфейс, маршрут, портын орон зайг өвлөнө:

services:
  vpn:
    image: your-vpn-client
    cap_add:
      - NET_ADMIN
    healthcheck:
      test: ["CMD-SHELL", "ip link show tun0 >/dev/null"]
      interval: 10s
      retries: 5
  app:
    image: your-app
    network_mode: service:vpn
    depends_on:
      vpn:
        condition: service_healthy

Нэрийн орон зай өөр үйлчилгээнд харьяалагддаг тул гурван хязгаарлалт үүсдэг. Апп өөрийн networks түлхүүрийг авдаггүй, учир нь наалдах нэрийн орон зай байхгүй. Порт нийтлэх нь vpn-д хамаарна, учир нь нэрийн орон зай тэнд амьдардаг. Мөн vpn-ийг дахин үүсгэх нь апп нэгдсэн нэрийн орон зайг устгадаг тул docker compose up -d --force-recreate vpn танд app-ыг ч дахин үүсгэхийг үлдээдэг; энгийн дахин эхлүүлэлт үргэлж хангалттай биш. Compose үйлчилгээний лавлагаа энэ зохион байгуулалт болон порт нийтлэх хязгаарлалтыг хамарна.

Шийдэгч хамт ирнэ гэж бүү бодоорой. /etc/resolv.conf нь контейнер бүрийн файл, сүлжээний нэрийн орон зайн хэсэг биш, тиймээс апп-ын пакетууд туннелээр гарч байх үед ч хост-ын шийдэгчээс асууж болно. Үүнийг контейнерын дотроос уншиж, хувийн нэрсийг туннелээр шийдэх шаардлагатай үед апп дээр dns: тохируулна уу.

docker compose exec app ip route
docker compose exec app cat /etc/resolv.conf
docker compose exec app curl -s https://ifconfig.me

Хэрэв маршрутын жагсаалтад туннелийн интерфейс байгаа бөгөөд хаяг нь нийлүүлэгчийнх бол апп туннелийн дотор байна. Интерфейс байхгүй бол vpn-д туннель үүсэхээс өмнө app эхэлсэн тул vpn эрүүл гэж мэдэгдсэний дараа app-ыг дахин үүсгэнэ үү.

Хост-ын клиентүүдэд зориулж нэрийн орон зайд жинхэнэ прокси сонсогч байрлуулна уу

Ширээний хөтөч нэрийн орон зайд нэгдэж чадахгүй тул туннелийг үйлчилгээ болгон ил гаргах ёстой. vpn нэрийн орон зайн дотор жинхэнэ SOCKS эсвэл HTTP прокси ажиллуулж, зөвхөн түүний портыг нийтэлнэ үү:

services:
  vpn:
    ports:
      - "127.0.0.1:1080:1080"
  proxy:
    image: your-proxy
    network_mode: service:vpn
    command: ["--socks", "0.0.0.0:1080"]

Хост талын хаяг нь тэр буулгалтын чухал хагас юм. Зүүн талын 127.0.0.1:1080 сонсогчийг таны LAN-аас гадуур байлгана; нүцгэн "1080:1080" таны машинд хүрч чадах бүх төхөөрөмжид нээлттэй прокси нийтэлнэ.

Контейнерын тал өөрийн урхитай. Нийтэлсэн портууд контейнерын гүүрэн хаяг руу хүргэгддэг, түүний loopback руу биш, тиймээс нэрийн орон зайн дотор --socks 127.0.0.1:1080-ээр эхэлсэн прокси хажуугийн контейнеруудын холболтыг хүлээж аваад нийтэлсэн портоор ирж буй бүхнийг татгалздаг. Үүнийг 0.0.0.0-д уяж, тусгаарлалтын хувьд хост талын loopback холболтод найдна уу. Мөн дүрэм прокси тохиргооны файл дахь сонсох хаягт мөн хамаарна.

Дараа нь нэрсийг хаана шийдэхийг шийднэ үү. curl дотор --socks5 хост-ын нэрийг локалаар шийдэж, --socks5-hostname нэрийг прокси руу илгээдэг; хөтчүүд ижил унтраалгыг өөр шошгон дор харуулдаг. Локал шийдэл нь хуудсыг туннелээр ачаалсан ч асуулгыг алдагдуулдаг.

Буцах маршрут байгаа үед л контейнерыг гарц гэж үзнэ үү

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Хоёр зүйлийг амархан алддаг. Клиентэд үндсэн гарцыг энэ хост руу чиглүүлэх маршрут хэрэгтэй, хариултууд буцах замаа олох ёстой, эсвэл дээд маршрутлагч дээрх статик маршрутаар, эсвэл клиентүүд рүү харсан интерфейс дээрх NAT-аар. Аль нэг нь байхгүй бол туннель хүсэлтийг гадагш аваачиж, хариулт алга болно.

Мөн хамгийн өргөн нөлөөтэй. Бүх LAN-д гарц болж буй хост алдаатай тохируулсан клиент бүрийг таны VPN бүртгэлээр дамжуулж, туннель унавал kill switch-ээс хамаарч LAN харанхуйлах эсвэл ISP руу буцах болно.

Гарах замыг шалгаад, дараа нь дарааллаар нь буцаана уу

Энэ дарааллаар шалгаад эхний алдаанд зогсоно уу: нэрийн орон зайн доторх гарах хаяг, хост-оос проксигоор гарах хаяг, дараа нь хувийн хост-ын нэрийн шийдэл.

docker compose exec vpn curl -s https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 http://internal.example/health

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

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

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

Холбоотой нийтлэлүүд