Xost trafigini Docker VPN konteyneri orqali qanday yo'naltirish kerak

VPN konteyneri tarmoq nomlar fazosi, proksi emas. Umumiy netns, haqiqiy SOCKS tinglovchisi yoki yo'naltirilgan shlyuz tanlang, so'ng chiqish yo'lini tekshiring.

Sizning tunnel konteyneringiz ishlaydi, docker compose exec vpn curl -s https://ifconfig.me provayder manzili bilan javob beradi, ammo ish stolingizdagi brauzer hanuz ISP orqali chiqadi. Bu farq kutilgan. VPN mijozi ishlaydigan konteyner tarmoq nomlar fazosi, marshrutlar va tunnel interfeysini saqlaydi, HTTP yoki SOCKS gapiradigan hech narsani saqlamaydi; unga port e'lon qilish hech qachon bo'lmagan tinglovchini yarata olmaydi.

Mijoz qayerda ishlashi dizaynni belgilaydi. Qo'shni konteyner tunnelning nomlar fazosiga o'ta oladi, ish stoli ilovasi o'ta olmaydi, marshrutizatorga esa proksi maydoni emas, marshrutlar kerak. Xaritani noto'g'ri qilsangiz, alomat bir xil: ulanish rad etildi yoki trafik jimgina eski yo'ldan ketadi.

Tartibni mijoz ishlaydigan joyga moslang

Compose'ni tahrirlashdan oldin bir savol bering: mijozni VPN konteynerining tarmoq nomlar fazosi ichida ishga tushirish mumkinmi? Allaqachon Linux konteyneri sifatida ishlayotgan har qanday narsa mumkin. Ishingizdagi brauzer, IDE yoki CLI esa mumkin emas, chunki uning proksi sozlamasi protokol xizmatini kutadi, nomlar fazosini emas.

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

Bu uchtasi aralashmaydi. Konteynerning ko'prik manziliga qaratilgan HTTP proksi maydoni u yerda proksi tinglamasa hech narsaga yetib bormaydi, proksi tinglovchisi esa marshrutizator trafigini yo'naltirmaydi. Avval qaror qiling, keyin tegishli bo'limga amal qiling.

Tunnel nomlar fazosini qo'shni konteyner bilan bo'lishing

Bu eng arzon variant, chunki proksi protokoli ishtirok etmaydi. Ilova vpn xizmatining nomlar fazosiga kiradi va uning interfeyslari, marshrutlari va port maydonini meros oladi:

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

Nomlar fazosi boshqa xizmatga tegishli bo'lganidan uchta cheklov kelib chiqadi. Ilova o'z networks kalitini olmaydi, chunki yopishadigan nomlar fazosi yo'q. Port e'lon qilish vpn ga tegishli, chunki nomlar fazosi o'sha yerda yashaydi. Va vpn ni qayta yaratish ilova kirgan nomlar fazosini yo'q qiladi, shuning uchun docker compose up -d --force-recreate vpn sizga app ni ham qayta yaratishni qoldiradi; oddiy qayta ishga tushirish har doim yetarli emas. Compose xizmatlari ma'lumotnomasi bu tartibni va uning port e'lon qilish cheklovini qamrab oladi.

Hal qiluvchi birga keladi deb o'ylamang. /etc/resolv.conf har bir konteyner uchun fayl, tarmoq nomlar fazosining qismi emas, shuning uchun ilova paketlari tunneldan chiqib ketayotganda ham u xostning hal qiluvchisidan so'rashi mumkin. Uni konteyner ichidan o'qing va shaxsiy nomlar tunnel orqali hal qilinishi kerak bo'lganda ilovaga dns: o'rnating.

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

Marshrutlar ro'yxatida tunnel interfeysi bo'lsa va manzil provayderniki bo'lsa, ilova tunnel ichida. Interfeys yo'q bo'lsa, app vpn da tunnel paydo bo'lishidan oldin ishga tushgan, shuning uchun vpn sog'lom ekanini bildirgach app ni qayta yarating.

Xost mijozlari uchun nomlar fazosiga haqiqiy proksi tinglovchisini qo'ying

Ish stoli brauzeri nomlar fazosiga kira olmaydi, shuning uchun tunnelni xizmat sifatida ochish kerak. vpn nomlar fazosi ichida haqiqiy SOCKS yoki HTTP proksi ishga tushiring va faqat uning portini e'lon qiling:

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

Xost tomonidagi manzil bu xaritaning muhim yarmi. Chapdagi 127.0.0.1:1080 tinglovchini LAN dan tashqarida ushlab turadi; yalang'och "1080:1080" mashinangizga yetib bora oladigan har bir qurilmaga ochiq proksi e'lon qiladi.

Konteyner tomonining o'z tuzog'i bor. E'lon qilingan portlar konteynerning ko'prikdagi manziliga yetkaziladi, uning loopback iga emas, shuning uchun nomlar fazosi ichida --socks 127.0.0.1:1080 bilan ishga tushirilgan proksi qo'shnilarning ulanishlarini qabul qiladi va e'lon qilingan port orqali kelgan hamma narsani rad etadi. Uni 0.0.0.0 ga bog'lang va izolyatsiya uchun xost tomonidagi loopback bog'lanishiga tayaning. Xuddi shu qoida proksi konfiguratsiya faylidagi tinglash manziliga ham tegishli.

Keyin nomlar qayerda hal qilinishini hal qiling. curl da --socks5 xost nomini mahalliy hal qiladi, --socks5-hostname esa nomni proksiga yuboradi; brauzerlar xuddi shu kalitni boshqa yorliq ostida ko'rsatadi. Mahalliy hal qilish sahifa tunnel orqali yuklansa ham so'rovni oshkor qiladi.

Konteynerni faqat qaytish marshruti bo'lsa shlyuz deb hisoblang

Marshrutizatorlar, VM lar va telefonlar HTTP proksi maydonidan foydalanmaydi, ba'zi ilovalar proksi o'zgaruvchilarini butunlay e'tiborsiz qoldiradi. Ularning trafigini yo'naltirish 3-qatlam degani: konteyner paketlarni uzatadi va tunnel interfeysida manzillarni tarjima qiladi.

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

Ikki narsani oson o'tkazib yuborish mumkin. Mijozga standart shlyuzini shu xostga yo'naltiruvchi marshrut kerak, javoblar esa qaytish yo'lini topishi kerak — yo yuqori marshrutizatordagi statik marshrut orqali, yo mijozlarga qaragan interfeysdagi NAT orqali. Ulardan biri bo'lmasa, tunnel so'rovni tashqariga olib chiqadi va javob yo'qoladi.

Uning ta'sir doirasi ham eng keng. Butun LAN uchun shlyuz bo'lib turgan xost har bir noto'g'ri sozlangan mijozni sizning VPN hisobingiz orqali yuboradi, tunnel yiqilsa esa kill switch ga qarab LAN qorong'ilashadi yoki ISP ga qaytadi.

Chiqish yo'lini tekshiring, so'ng teskari tartibda qaytaring

Shu tartibda tekshiring va birinchi muvaffaqiyatsizlikda to'xtang: nomlar fazosi ichidagi chiqish manzili, xostdan proksi orqali chiqish manzili, so'ng shaxsiy xost uchun nomlar yechimi.

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

Birinchi ikkita manzil provayderga mos kelishi kerak, uchinchisi esa nom xatosi bilan muvaffaqiyatsiz bo'lish o'rniga proksi orqali hal qilinishi kerak. Birinchi satr mos kelib, ikkinchisi muvaffaqiyatsiz bo'lsa, tinglovchi yoki e'lon qilingan port noto'g'ri, tunnel emas.

Qaytarish — sozlashning teskarisi. Proksi muhit o'zgaruvchilarini shell profilidan va har qanday systemd birligidan olib tashlang, so'ng stekni tushiring, umumiy nomlar fazosi egasi bilan birga yo'qolsin. E'lon qilingan portni proksi xizmatini o'chirishdan oldin o'chiring, aks holda xostda hech kim o'qimaydigan loopback tinglovchisi qoladi.

Davom etishdan oldin to'rt narsani tasdiqlang: sizga muhim bo'lgan mijoz haqiqatan tunnelga yetib boradi, portlarni faqat nomlar fazosining egasi e'lon qiladi, shaxsiy nomlar siz ko'zlagan joyda hal qilinadi va loopback bo'lmagan xost manzilida hech narsa tinglamaydi. Ularning har biri ishlab chiqarishda jimgina muvaffaqiyatsiz bo'ladi va har biri yuqoridagi bir satrli tekshiruvdir.

O'xshash maqolalar