Hoe't jo hostferkear troch in Docker VPN-kontener liede

In VPN-kontener is in netwurknammeromte, gjin proxy. Kies in dielde netns, in echte SOCKS-harker of in rûtele trochgong, en ferifiearje dan it útgongspaad.

Jo tunnelkontener wurket, docker compose exec vpn curl -s https://ifconfig.me antwurdet mei it adres fan de provider, en dochs giet de browser op jo buroblêd noch altyd út troch jo ISP. Dat gat is te ferwachtsjen. In kontener dy't in VPN-klant docht, hâldt in netwurknammeromte, rûtes en in tunnelinterface, en neat dat HTTP of SOCKS sprekt; in poarte dêrop publisearje kin gjin harker meitsje dy't der nea wie.

Wêr't de klant rint, beslút it ûntwerp. In buorkontener kin yn 'e nammeromte fan 'e tunnel komme, in buroblêdapplikaasje kin dat net, en in router hat rûtes nedich yn stee fan in proxyfjild. Kriget men de mapping ferkeard, dan is it symptoom itselde: ferbining wegere, of ferkear dat stil de âlde wei nimt.

Pas de opstelling oan by it plak dêr't de klant rint

Stel ien fraach foardat jo Compose bewurkje: kin de klant binnen de netwurknammeromte fan 'e VPN-kontener starten? Alles dat al as Linux-kontener rint, kin dat. In browser, in IDE of in CLI op jo buroblêd kin dat net, om't syn proxyynstelling in protokoltsjinst ferwachtet, gjin nammeromte.

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

Dizze trije mingje net. In HTTP-proxyfjild rjochte op it brêge-adres fan 'e kontener berikt neat, útsein as dêr in proxy harket, en in proxyharker rûtelet gjin ferkear fan in router. Beskiede earst, folgje dan de byhearrende seksje.

Diel de tunnelnammeromte mei in buorkontener

Dit is de goedkeapste opsje, om't der gjin proxyprotokol by belutsen is. De app komt by de nammeromte fan 'e vpn-tsjinst en erft syn interfaces, rûtes en poarteromte:

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

Trije beheiningen folgje út it feit dat de nammeromte by in oare tsjinst heart. De app krijt gjin eigen networks-kaai, om't er gjin nammeromte hat om oan te hingjen. Poartepublikaasje heart by vpn, om't dêr de nammeromte wennet. En it opnij meitsjen fan vpn ferneatiget de nammeromte dêr't de app by kaam, dat docker compose up -d --force-recreate vpn lit jo ek app opnij meitsje; in gewoane herstart is net altyd genôch. De Compose-tsjinstreferinsje behannelet dizze opstelling en har beheining foar poartepublikaasje.

Tink net dat de resolver mei komt. /etc/resolv.conf is in bestân per kontener, net in part fan 'e netwurknammeromte, dat de app kin de resolver fan 'e host noch freegje wylst syn pakketten troch de tunnel geane. Lês it fan binnen de kontener en set dns: op de app as private nammen troch de tunnel oplost wurde moatte.

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

As de rûtelist de tunnelinterface befettet en it adres is fan 'e provider, dan is de app yn 'e tunnel. As de interface ûntbrekt, is app start foardat vpn in tunnel hie, dat meitsje app opnij sadree't vpn sûn rapportearret.

Set in echte proxyharker yn 'e nammeromte foar hostklanten

In buroblêdbrowser kin net by in nammeromte komme, dat de tunnel moat as tsjinst bleatsteld wurde. Run in echte SOCKS- of HTTP-proxy binnen de vpn-nammeromte en publisearje allinnich syn poarte:

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

It adres oan 'e hostkant is de wichtige helte fan dy mapping. 127.0.0.1:1080 oan 'e linkerkant hâldt de harker bûten jo LAN; in bleate "1080:1080" publisearret in iepen proxy oan elk apparaat dat jo masine berikke kin.

De kontenerkant hat syn eigen falstrik. Publisearre poarten wurde oan it adres fan 'e kontener op 'e brêge levere, net oan syn loopback, dat in proxy start mei --socks 127.0.0.1:1080 binnen de nammeromte akseptearret ferbiningen fan buorlju en wegeret alles dat troch de publisearre poarte komt. Byn it oan 0.0.0.0 en fertrou op 'e loopback-binding oan 'e hostkant foar isolaasje. Deselde regel jildt foar it harkadres yn in proxykonfiguraasjebestân.

Beslút dan wêr't nammen oplost wurde. Yn curl lost --socks5 de hostnamme lokaal op en --socks5-hostname stjoert de namme nei de proxy; browsers eksposearje deselde skeakel ûnder in oar label. Lokale oplossing lekket de oanfreegje sels as de side troch de tunnel laden wurdt.

Behannelje de kontener as trochgong allinnich mei in weromrûte

Routers, VM's en tillefoans sille gjin HTTP-proxyfjild brûke, en guon applikaasjes negearje proxyfariabelen folslein. Harren ferkear rûtele betsjut laach 3: de kontener stjoert pakketten troch en fertaalt adressen op 'e tunnelinterface.

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

Twa dingen wurde maklik mist. De klant hat in rûte nedich dy't syn standerttrochgong nei dizze host wiist, en antwurden moatte de wei werom fine, itsij fia in statyske rûte op 'e boppeste router, itsij fia NAT op 'e interface nei de klanten. Sûnder ien fan beide draacht de tunnel it fersyk nei bûten en ferdwynt it antwurd.

It hat ek de breedste ynfloedsfear. In host dy't as trochgong foar it hiele LAN tsjinnet, stjoert elke ferkeard konfigurearre klant troch jo VPN-account, en in tunnelûnderbrekking makket it LAN tsjuster of falt werom op 'e ISP, ôfhinklik fan 'e kill switch.

Ferifiearje it útgongspaad en rôlje dan yn folchoarder werom

Kontrolearje yn dizze folchoarder en stop by de earste mislearring: útgongsadres binnen de nammeromte, útgongsadres fan 'e host fia de proxy, dan namme-oplossing foar in private host.

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

De earste twa adressen moatte oerienkomme mei de provider, en it tredde moat fia de proxy oplosse yn stee fan te mislearjen mei in namflater. In oerienkommende earste rigel en in mislearjende twadde rigel betsjutte dat de harker of de publisearre poarte ferkeard is, net de tunnel.

Weromrôlje is it tsjinoerstellene fan 'e opset. Ferwiderje de proxy-omjouwingsfariabelen út it shellprofyl en út elke systemd-ienheid, bring dan de stapel del sadat de dielde nammeromte mei syn eigener ferdwynt. Wiskje de publisearre poarte foardat jo de proxystsjinst wiskje, oars hâldt de host in loopback-harker dy't nimmen lêst.

Foardat jo fierder geane, befêstigje fjouwer dingen: de klant dy't jo oanbelanget berikt wier de tunnel, allinnich de eigener fan 'e nammeromte publisearret poarten, private nammen wurde oplost wêr't jo bedoelden, en neat harket op in hostadres dat gjin loopback is. Elk fan dy mislearret stil yn produksje, en elk is in kontrôle fan ien rigel hjirboppe.

Relatearre artikelen