Si të drejtohet trafiku i hostit përmes një kontejneri Docker VPN

Kontejneri i tunelit tuaj funksionon, docker compose exec vpn curl -s https://ifconfig.me përgjigjet me adresën e ofruesit, dhe megjithatë shfletuesi në desktopin tuaj del ende përmes ISP-së tuaj. Ky hendek është i pritshëm. Një kontejner që ekzekuton një klient VPN mban një hapësirë emrash rrjeti, rrugë dhe një ndërfaqe tuneli, dhe asgjë që flet HTTP ose SOCKS; publikimi i një porte mbi të nuk mund të krijojë një dëgjues që nuk ka ekzistuar kurrë.

Ku ekzekutohet klienti vendos dizajnin. Një kontejner motër mund të kalojë në hapësirën e emrave të tunelit, një aplikacion desktopi nuk mundet, dhe një ruter ka nevojë për rrugë, jo për një fushë proxy. Nëse e gaboni hartëzimin, simptomi është i njëjtë: lidhje e refuzuar, ose trafik që merr në heshtje rrugën e vjetër.

Përshtatni rregullimin me vendin ku ekzekutohet klienti

Bëni një pyetje përpara se të redaktoni Compose: a mund të nisë klienti brenda hapësirës së emrave të rrjetit të kontejnerit VPN? Çdo gjë që ekzekutohet tashmë si kontejner Linux mundet. Një shfletues, një IDE ose një CLI në tavolinën tuaj nuk mundet, sepse cilësimi i tij i proxy pret një shërbim protokolli, jo një hapësirë emrash.

Këto tre nuk përzihen. Një fushë proxy HTTP e drejtuar drejt adresës së urës së kontejnerit nuk arrin asgjë nëse një proxy nuk dëgjon atje, dhe një dëgjues proxy nuk i drejton trafikun një ruteri. Vendosni së pari, pastaj ndiqni seksionin përkatës.

Ndani hapësirën e emrave të tunelit me një kontejner motër

Ky është opsioni më i lirë sepse nuk përfshihet asnjë protokoll proxy. Aplikacioni hyn në hapësirën e emrave të shërbimit vpn dhe trashëgon ndërfaqet, rrugët dhe hapësirën e portave:

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

Tre kufizime rrjedhin nga fakti që hapësira e emrave i takon një shërbimi tjetër. Aplikacioni nuk merr një çelës networks të vetin, sepse nuk ka hapësirë emrash ku të lidhet. Publikimi i portave i takon vpn, sepse atje jeton hapësira e emrave. Dhe rikrijimi i vpn shkatërron hapësirën e emrave ku hyri aplikacioni, prandaj docker compose up -d --force-recreate vpn ju lë t'i rikrijoni edhe app; një rinisje e thjeshtë nuk mjafton gjithmonë. Referenca e shërbimeve Compose mbulon këtë rregullim dhe kufizimin e publikimit të portave.

Mos supozoni se zgjidhësi vjen me të. /etc/resolv.conf është një skedar për kontejner, jo pjesë e hapësirës së emrave të rrjetit, kështu që aplikacioni mund të pyesë ende zgjidhësin e hostit ndërsa paketat e tij dalin përmes tunelit. Lexojeni brenda kontejnerit dhe vendosni dns: tek aplikacioni kur emrat privatë duhet të zgjidhen përmes tunelit.

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

Nëse lista e rrugëve përmban ndërfaqen e tunelit dhe adresa është e ofruesit, aplikacioni është brenda tunelit. Nëse ndërfaqja mungon, app ka nisur përpara se vpn të kishte një tunel, prandaj rikrijoni app sapo vpn raporton shëndet.

Vendosni një dëgjues të vërtetë proxy në hapësirën e emrave për klientët e hostit

Një shfletues desktopi nuk mund të bashkohet me një hapësirë emrash, prandaj tuneli duhet të ekspozohet si shërbim. Ekzekutoni një proxy të vërtetë SOCKS ose HTTP brenda hapësirës së emrave vpn dhe publikoni vetëm portën e tij:

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

Adresa në anën e hostit është gjysma e rëndësishme e atij hartëzimi. 127.0.0.1:1080 në të majtë e mban dëgjuesin jashtë LAN-it tuaj; një "1080:1080" i zhveshur publikon një proxy të hapur për çdo pajisje që mund të arrijë makinën tuaj.

Ana e kontejnerit ka kurthin e vet. Portat e publikuara dorëzohen në adresën e kontejnerit në urë, jo në loopback-un e tij, kështu që një proxy i nisur me --socks 127.0.0.1:1080 brenda hapësirës së emrave pranon lidhjet e motrave dhe refuzon çdo gjë që vjen përmes portës së publikuar. Lidheni me 0.0.0.0 dhe mbështetuni te lidhja loopback e anës së hostit për izolim. I njëjti rregull vlen për adresën e dëgjimit në një skedar konfigurimi proxy.

Më pas vendosni ku zgjidhen emrat. Në curl, --socks5 e zgjidh emrin e hostit lokalisht dhe --socks5-hostname e dërgon emrin te proxy; shfletuesit ekspozojnë të njëjtin çelës nën një etiketë tjetër. Zgjidhja lokale zbulon kërkesën edhe kur faqja ngarkohet përmes tunelit.

Trajtojeni kontejnerin si portë vetëm me një rrugë kthimi

Ruterët, VM-të dhe telefonat nuk do të përdorin një fushë proxy HTTP, dhe disa aplikacione i injorojnë plotësisht variablat e proxy. Rrugëzimi i trafikut të tyre do të thotë shtresë 3: kontejneri përçon paketat dhe përkthen adresat në ndërfaqen e tunelit.

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

Dy gjëra humbin lehtë. Klienti ka nevojë për një rrugë që e drejton portën e tij të paracaktuar drejt këtij hosti, dhe përgjigjet duhet të gjejnë rrugën e kthimit, ose përmes një rruge statike në ruterin sipër, ose përmes NAT në ndërfaqen përballë klientëve. Pa njërën prej tyre, tuneli e nxjerr kërkesën jashtë dhe përgjigja zhduket.

Ka edhe rrezen më të gjerë të ndikimit. Një host që shërben si portë për të gjithë LAN-in dërgon çdo klient të konfiguruar gabimisht përmes llogarisë tuaj VPN, dhe një rënie e tunelit ose e errëson LAN-in ose kthehet te ISP sipas kill switch.

Verifikoni rrugën e daljes, pastaj kthejeni mbrapsht sipas radhës

Kontrolloni në këtë radhë dhe ndaloni në dështimin e parë: adresa e daljes brenda hapësirës së emrave, adresa e daljes nga hosti përmes proxy, pastaj zgjidhja e emrave për një host privat.

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

Dy adresat e para duhet të përputhen me ofruesin, dhe e treta duhet të zgjidhet përmes proxy në vend që të dështojë me gabim emri. Një rresht i parë që përputhet dhe një i dytë që dështon do të thotë se dëgjuesi ose porta e publikuar është gabim, jo tuneli.

Kthimi mbrapsht është e kundërta e konfigurimit. Hiqni variablat e mjedisit të proxy nga profili i shell-it dhe nga çdo njësi systemd, pastaj ulni stivën që hapësira e përbashkët e emrave të zhduket me pronarin e saj. Fshini portën e publikuar përpara se të fshini shërbimin proxy, përndryshe hosti mban një dëgjues loopback që askush nuk e lexon.

Përpara se të vazhdoni, konfirmoni katër gjëra: klienti që ju intereson arrin vërtet në tunel, vetëm pronari i hapësirës së emrave publikon porta, emrat privatë zgjidhen atje ku keni synuar, dhe asgjë nuk dëgjon në një adresë hosti që nuk është loopback. Secila prej tyre dështon në heshtje në prodhim, dhe secila është një kontroll një-rresht më lart.