Хост трафигин 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 эмес хост дарегинде эч нерсе укпайт. Алардын ар бири өндүрүштө үнсүз ийгиликсиз болот, жана ар бири жогорудагы бир саптык текшерүү.

Тектеш макалалар