Hogyan irányítsuk a gazdagép forgalmát Docker VPN-konténeren át

A VPN-konténer hálózati névtér, nem proxy. Válasszon közös netns-t, valódi SOCKS-hallgatót vagy irányított átjárót, majd ellenőrizze a kilépési útvonalat.

A tunélkonténer működik, a docker compose exec vpn curl -s https://ifconfig.me a szolgáltató címével válaszol, a munkaasztal böngészője mégis az ISP-jén keresztül lép ki. Ez a rés várható. A VPN-klienst futtató konténer hálózati névteret, útvonalakat és tunél-interfészt tart, és semmit, ami HTTP-t vagy SOCKS-t beszél; portot közzétenni rajta nem hozhat létre olyan hallgatót, amely soha nem létezett.

Az dönt a tervezésről, hogy hol fut a kliens. Egy testvérkonténer átléphet a tunél névterébe, egy asztali alkalmazás nem, a routernek pedig útvonalak kellenek, nem proxy-mező. Ha rossz a leképezés, a tünet ugyanaz: elutasított kapcsolat vagy forgalom, amely csendben a régi úton megy.

A kialakítást a kliens futási helyéhez igazítsa

Tegyen fel egy kérdést a Compose szerkesztése előtt: elindítható-e a kliens a VPN-konténer hálózati névterén belül? Minden, ami már Linux-konténerként fut, elindítható. Egy böngésző, IDE vagy CLI az asztalán nem, mert a proxy-beállítása protokollszolgáltatást vár, nem névteret.

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

Ez a három nem keveredik. A konténer híd-címére mutató HTTP proxy-mező semmit nem ér el, ha ott nem hallgat proxy, a proxy-hallgató pedig nem irányítja a router forgalmát. Először döntsön, aztán kövesse a megfelelő szakaszt.

Ossza meg a tunél névterét egy testvérkonténerrel

Ez a legolcsóbb lehetőség, mert nem vesz benne részt proxyprotokoll. Az alkalmazás belép a vpn szolgáltatás névterébe, és örökli annak interfészeit, útvonalait és portterét:

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

Három korlátozás következik abból, hogy a névtér egy másik szolgáltatáshoz tartozik. Az alkalmazás nem kap saját networks kulcsot, mert nincs névtere, amelyhez csatlakozhatna. A portok közzététele a vpn-hez tartozik, mert ott él a névtér. És a vpn újralétrehozása megsemmisíti a névteret, amelyhez az alkalmazás csatlakozott, ezért a docker compose up -d --force-recreate vpn Önre hagyja az app újralétrehozását is; egy egyszerű újraindítás nem mindig elég. A Compose szolgáltatási referenciája tárgyalja ezt a kialakítást és a portközzététel korlátozását.

Ne feltételezze, hogy a feloldó vele jön. A /etc/resolv.conf konténerenkénti fájl, nem a hálózati névtér része, ezért az alkalmazás továbbra is kérdezheti a gazdagép feloldóját, miközben csomagjai a tunélen át távoznak. Olvassa el a konténeren belül, és állítsa be a dns:-ot az alkalmazáson, amikor a privát neveket a tunélen át kell feloldani.

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

Ha az útvonallista tartalmazza a tunél-interfészt, és a cím a szolgáltatóé, az alkalmazás a tunélen belül van. Ha az interfész hiányzik, az app még azelőtt indult, hogy a vpn-nek tunéle lett volna, ezért hozza létre újra az app-ot, amint a vpn egészségesnek jelenti magát.

Tegyen valódi proxy-hallgatót a névtérbe a gazdagép kliensei számára

Az asztali böngésző nem tud belépni egy névtérbe, ezért a tunélt szolgáltatásként kell kitenni. Futtasson valódi SOCKS vagy HTTP proxyt a vpn névterén belül, és csak a portját tegye közzé:

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

A gazdagép oldali cím a leképezés fontos fele. A bal oldali 127.0.0.1:1080 távol tartja a hallgatót a LAN-jától; egy csupasz "1080:1080" nyitott proxyt tesz közzé minden eszköznek, amely eléri a gépét.

A konténer oldalának megvan a maga csapdája. A közzétett portok a konténer híd-címére kerülnek, nem a loopbackjére, ezért a névtéren belül --socks 127.0.0.1:1080-gyel indított proxy fogadja a testvérek kapcsolatait, és elutasít mindent, ami a közzétett porton érkezik. Kösse a 0.0.0.0-höz, és az elkülönítéshez bízzon a gazdagép oldali loopback-kötésben. Ugyanez a szabály vonatkozik a proxy konfigurációs fájljában megadott hallgatási címre.

Ezután döntse el, hol oldódnak fel a nevek. A curlben a --socks5 helyben oldja fel a gazdagépnevet, a --socks5-hostname pedig a proxyhoz küldi a nevet; a böngészők ugyanezt a kapcsolót más címke alatt kínálják. A helyi feloldás akkor is kiszivárogtatja a lekérdezést, ha az oldal a tunélen át töltődik be.

Csak visszaúttal tekintse a konténert átjárónak

A routerek, VM-ek és telefonok nem fognak HTTP proxy-mezőt használni, és egyes alkalmazások teljesen figyelmen kívül hagyják a proxyváltozókat. Forgalmuk irányítása 3. réteget jelent: a konténer továbbítja a csomagokat, és a tunél-interfészen fordítja a címeket.

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

Két dolog könnyen elkerüli a figyelmet. A kliensnek olyan útvonal kell, amely az alapértelmezett átjáróját erre a gazdagépre irányítja, a válaszoknak pedig vissza kell találniuk, akár statikus útvonalon a felső routeren, akár NAT-on a kliensek felé néző interfészen. Ha egyik sincs, a tunél kiviszi a kérést, és a válasz eltűnik.

A hatása is a legszélesebb. A teljes LAN átjárójaként működő gazdagép minden rosszul beállított klienst az Ön VPN-fiókján keresztül küld, a tunél kiesése pedig vagy elsötétíti a LAN-t, vagy visszaesik az ISP-re a kill switch függvényében.

Ellenőrizze a kilépési útvonalat, majd sorrendben vonja vissza

Ebben a sorrendben ellenőrizze, és az első hibánál álljon meg: kilépési cím a névtéren belül, kilépési cím a gazdagépről a proxyn át, majd névfeloldás egy privát gazdagéphez.

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

Az első két címnek meg kell egyeznie a szolgáltatóval, a harmadiknak pedig a proxyn át kell feloldódnia ahelyett, hogy névhibával elbukna. Az egyező első sor és a hibázó második sor azt jelenti, hogy a hallgató vagy a közzétett port rossz, nem a tunél.

A visszavonás a beállítás ellentéte. Távolítsa el a proxy környezeti változóit a shell-profilból és minden systemd-egységből, majd állítsa le a stacket, hogy a megosztott névtér eltűnjön a tulajdonosával együtt. Törölje a közzétett portot a proxyszolgáltatás törlése előtt, különben a gazdagépen marad egy loopback-hallgató, amelyet senki nem olvas.

Mielőtt továbblép, erősítsen meg négy dolgot: a számára fontos kliens valóban eléri a tunélt, csak a névtér tulajdonosa tesz közzé portokat, a privát nevek ott oldódnak fel, ahol szánta, és semmi nem hallgat olyan gazdagép-címen, amely nem loopback. Ezek mindegyike csendben meghibásodik élesben, és mindegyik egysoros ellenőrzés fent.

Kapcsolódó cikkek