Kuidas suunata hosti liiklust Dockeri VPN-konteineri kaudu

VPN-konteiner on võrgu nimeruum, mitte puhverserver. Valige jagatud netns, tõeline SOCKS-kuulaja või marsruuditud lüüs, seejärel kontrollige väljumisteed.

Teie tunnelikonteiner töötab, docker compose exec vpn curl -s https://ifconfig.me vastab teenusepakkuja aadressiga ja ometi väljub teie töölaua brauser teie ISP kaudu. See vahe on ootuspärane. VPN-kliienti käitav konteiner hoiab võrgu nimeruumi, marsruute ja tunneli liidest, mitte midagi, mis räägib HTTP-d või SOCKS-it; pordi avaldamine sellel ei saa luua kuulajat, mida kunagi polnud.

See, kus klient töötab, määrab disaini. Kõrvalkonteiner saab tunnelis nimeruumi liikuda, töölauarakendus ei saa, ja ruuter vajab marsruute, mitte puhverserveri välja. Kui kaardistus on vale, on sümptom sama: ühendusest keelduti või liiklus läheb vaikselt vana teed.

Sobitage lahendus sellega, kus klient töötab

Esitage enne Compose'i muutmist üks küsimus: kas klienti saab käivitada VPN-konteineri võrgu nimeruumi sees? Kõik, mis juba töötab Linuxi konteinerina, saab. Töölaual olev brauser, IDE või CLI ei saa, sest selle puhverserveri säte ootab protokolliteenust, mitte nimeruumi.

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

Need kolm ei segune. Konteineri silla-aadressile suunatud HTTP puhverserveri väli ei jõua kuhugi, kui seal puhverserver ei kuula, ja puhverserveri kuulaja ei marsruudi ruuteri liiklust. Otsustage kõigepealt, seejärel järgige sobivat jaotist.

Jagage tunneli nimeruumi kõrvalkonteineriga

See on odavaim valik, sest ükski puhverserveri protokoll ei osale. Rakendus liitub vpn-teenuse nimeruumiga ja pärib selle liidesed, marsruudid ja pordiruumi:

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

Sellest, et nimeruum kuulub teisele teenusele, tuleneb kolm piirangut. Rakendus ei saa oma networks võtit, sest tal pole nimeruumi, mille külge kinnituda. Portide avaldamine kuulub vpn-ile, sest seal elab nimeruum. Ja vpn-i uuesti loomine hävitab nimeruumi, millega rakendus liitus, seega docker compose up -d --force-recreate vpn jätab teile ka app-i uuesti loomise; tavaline taaskäivitus ei ole alati piisav. Compose'i teenuste viide käsitleb seda lahendust ja selle pordi avaldamise piirangut.

Ärge eeldage, et resolver tuleb kaasa. /etc/resolv.conf on konteineripõhine fail, mitte võrgu nimeruumi osa, seega saab rakendus endiselt hosti resolverit küsida, samal ajal kui selle paketid väljuvad tunnelist. Lugege seda konteineri seest ja seadke rakendusele dns:, kui privaatseid nimesid tuleb tunnelist lahendada.

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

Kui marsruudiloend sisaldab tunneli liidest ja aadress on teenusepakkuja oma, on rakendus tunnelis sees. Kui liides puudub, käivitus app enne, kui vpn-il tunnel oli, seega looge app uuesti, kui vpn teatab tervisest.

Pange hosti klientide jaoks nimeruumi tõeline puhverserveri kuulaja

Töölaua brauser ei saa nimeruumiga liituda, seega tuleb tunnel teenusena avaldada. Käitage vpn-i nimeruumi sees tõelist SOCKS- või HTTP-puhverserverit ja avaldage ainult selle port:

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

Hosti poolne aadress on selle kaardistuse tähtis pool. 127.0.0.1:1080 vasakul hoiab kuulaja teie LAN-ist eemal; paljas "1080:1080" avaldab avatud puhverserveri igale seadmele, mis teie masinani jõuab.

Konteineri poolel on oma lõks. Avaldatud pordid toimetatakse konteineri aadressile sillal, mitte selle loopbackile, seega nimeruumi sees --socks 127.0.0.1:1080-ga käivitatud puhverserver võtab vastu kõrvalkonteinerite ühendusi ja keeldub kõigest, mis saabub avaldatud pordi kaudu. Siduge see 0.0.0.0-ga ja lootke isoleerimiseks hosti poole loopback-sidumisele. Sama reegel kehtib puhverserveri konfiguratsioonifaili kuulamisadressi kohta.

Seejärel otsustage, kus nimesid lahendatakse. Curlis lahendab --socks5 hostinime kohapeal ja --socks5-hostname saadab nime puhverserverile; brauserid pakuvad sama lülitit teise sildi all. Kohalik lahendamine lekitab päringu ka siis, kui leht laaditakse tunnelist.

Käsitlege konteinerit lüüsina ainult tagasiteega

Ruuterid, VM-id ja telefonid ei kasuta HTTP puhverserveri välja ja mõned rakendused eiravad puhverserveri muutujaid täielikult. Nende liikluse marsruutimine tähendab 3. kihti: konteiner edastab pakette ja tõlgib aadresse tunneli liidesel.

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

Kaks asja on kergesti märkamata. Kliendil peab olema marsruut, mis suunab tema vaikelüüsi sellele hostile, ja vastused peavad tagasitee leidma, kas ülemruuteri staatilise marsruudiga või NAT-iga klientide poole jääval liidesel. Ilma ühega neist viib tunnel päringu välja ja vastus kaob.

Sellel on ka kõige laiem mõjuraadius. Host, mis on lüüsiks kogu LAN-ile, saadab iga valesti seadistatud kliendi teie VPN-kontolt läbi, ja tunneli katkemine kas pimendab LAN-i või langeb tagasi ISP-le, sõltuvalt kill switch-ist.

Kontrollige väljumisteed ja seejärel kerige tagasi järjekorras

Kontrollige selles järjekorras ja peatuge esimesel tõrkel: väljumisaadress nimeruumi sees, väljumisaadress hostist puhverserveri kaudu, seejärel nimelahendus privaatse hosti jaoks.

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

Kaks esimest aadressi peaksid teenusepakkujaga sobima ja kolmas peaks lahenduma puhverserveri kaudu, mitte nurjuma nimeveaga. Sobiv esimene rida ja nurjuv teine rida tähendavad, et kuulaja või avaldatud port on vale, mitte tunnel.

Tagasikerimine on seadistuse vastand. Eemaldage puhverserveri keskkonnamuutujad shelli profiilist ja igast systemd-üksusest, seejärel langetage virn, et jagatud nimeruum kaoks koos omanikuga. Kustutage avaldatud port enne puhverserveri teenuse kustutamist, muidu jääb hostile loopback-kuulaja, mida keegi ei loe.

Enne edasiminekut kinnitage neli asja: klient, millest hoolite, jõuab tõesti tunnelini, porte avaldab ainult nimeruumi omanik, privaatsed nimed lahendatakse seal, kus kavatsesite, ja miski ei kuula hosti aadressil, mis pole loopback. Igaüks neist ebaõnnestub tootmises vaikselt ja igaüks on üherealune kontroll ülal.

Seotud artiklid