Хост трафигін 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

Маршруттар тізімінде туннель интерфейсі болса және мекенжай провайдердікі болса, қолданба туннельдің ішінде. Интерфейс жоқ болса, app vpn-де туннель болмай тұрып іске қосылған, сондықтан 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 емес хост мекенжайында ештеңе тыңдамайды. Олардың әрқайсысы өндірісте үнсіз сәтсіздікке ұшырайды, және әрқайсысы жоғарыдағы бір жолдық тексеру.

Қатысты мақалалар