Nola bideratu ostalariaren trafikoa Docker VPN edukiontzi baten bidez

VPN edukiontzi bat sare-izen espazio bat da, ez proxy bat. Aukeratu netns partekatua, SOCKS entzule erreala edo bideratutako atebidea, eta egiaztatu irteerako bidea.

Zure tunel edukiontzia martxan dago, docker compose exec vpn curl -s https://ifconfig.me hornitzailearen helbidearekin erantzuten du, eta hala ere zure mahaigaineko nabigatzailea zure ISP bidez ateratzen da. Hutsune hori espero daiteke. VPN bezero bat exekutatzen duen edukiontziak sare-izen espazio bat, bideak eta tunel interfaze bat dauzka, eta HTTP edo SOCKS hitz egiten duen ezer ez; hor ataka bat argitaratzeak ezin du inoiz egon ez zen entzulerik sortu.

Bezeroa non exekutatzen den erabakitzen du diseinuak. Alboan dagoen edukiontzi bat tunelaren izen espaziora pasa daiteke, mahaigaineko aplikazio bat ezin da, eta bideratzaileak bideak behar ditu, ez proxy eremu bat. Kateaketa gaizki eginez gero, sintoma bera da: konexioa ukatuta edo trafikoa isilka bide zaharretik doa.

Egokitu antolamendua bezeroa exekutatzen den tokira

Egin galdera bat Compose editatu aurretik: has daiteke bezeroa VPN edukiontziaren sare-izen espazioaren barruan? Dagoeneko Linux edukiontzi gisa exekutatzen den edozer has daiteke. Mahaigainean duzun nabigatzaile, IDE edo CLI batek ezin du, haren proxy ezarpenak protokolo zerbitzu bat espero baitu, ez izen espazio bat.

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

Hirurok ez dira nahasten. Edukiontziaren zubi-helbidera zuzendutako HTTP proxy eremu batek ez du ezer lortzen han proxy bat entzuten ez badu, eta proxy entzule batek ez du bideratzaile baten trafikoa bideratzen. Erabaki lehenengo, eta gero jarraitu dagokion atala.

Partekatu tunelaren izen espazioa alboan dagoen edukiontzi batekin

Hau da aukerarik merkeena, ez baitago proxy protokolorik tartean. Aplikazioa vpn zerbitzuaren izen espaziora batu eta haren interfazeak, bideak eta ataka espazioa heredatzen ditu:

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

Hiru murrizketa datoz izen espazioa beste zerbitzu bati dagokiolako. Aplikazioak ez du bere networks gakorik lortzen, ez baitu itsasteko izen espaziorik. Ataken argitaratzea vpn-en dago, han bizi baita izen espazioa. Eta vpn berriz sortzeak aplikazioa batu zen izen espazioa suntsitzen du, beraz docker compose up -d --force-recreate vpn-k app ere berriz sortu behar duzula uzten dizu; berrabiarazte soil bat ez da beti nahikoa. Compose zerbitzuen erreferentziak antolamendu hau eta ataken argitaratzeko murrizketa lantzen ditu.

Ez pentsatu ebazlea berarekin datorrenik. /etc/resolv.conf edukiontzi bakoitzeko fitxategi bat da, ez sare-izen espazioaren zati, beraz aplikazioak ostalariaren ebazlea galde dezake oraindik bere paketeak tunel bidez irteten diren bitartean. Irakurri edukiontziaren barruan eta ezarri dns: aplikazioan izen pribatuak tunel bidez ebatzi behar direnean.

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

Bide zerrendak tunel interfazea badauka eta helbidea hornitzailearena bada, aplikazioa tunelaren barruan dago. Interfazea falta bada, app vpn-ek tunela izan baino lehen hasi zen, beraz sortu app berriz vpn osasuntsu dagoela jakinarazi ondoren.

Jarri benetako proxy entzule bat izen espazioan ostalariaren bezeroentzat

Mahaigaineko nabigatzaile batek ezin du izen espazio batera batu, beraz tunela zerbitzu gisa erakutsi behar da. Exekutatu benetako SOCKS edo HTTP proxy bat vpn izen espazioaren barruan eta argitaratu soilik haren ataka:

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

Ostalariaren aldeko helbidea da kateaketa horren erdi garrantzitsua. Ezkerreko 127.0.0.1:1080-k entzulea zure LAN-etik kanpo mantentzen du; "1080:1080" soil batek proxy ireki bat argitaratzen du zure makina har dezakeen gailu bakoitzarentzat.

Edukiontziaren aldeak bere tranpa du. Argitaratutako atakak edukiontziaren zubi-helbidera entregatzen dira, ez haren loopback-era, beraz izen espazioaren barruan --socks 127.0.0.1:1080-rekin hasitako proxy batek alboetako konexioak onartzen ditu eta ataka argitaratuaren bidez iristen den guztia ukatzen du. Lotu 0.0.0.0-ra eta fidatu ostalariaren aldeko loopback lotura isolamendurako. Arau bera aplikatzen zaio proxy konfigurazio fitxategi bateko entzute-helbideari.

Gero erabaki non ebazten diren izenak. curl-en --socks5-k ostalari izena tokian ebazten du eta --socks5-hostname-k izena proxyari bidaltzen dio; nabigatzaileek etengailu bera erakusten dute beste etiketa batekin. Tokiko ebazpenak kontsulta filtratzen du orria tunel bidez kargatzen denean ere.

Hartu edukiontzia atebide gisa itzulerako bide batekin soilik

Bideratzaileek, VM-ek eta telefonoek ez dute HTTP proxy eremurik erabiliko, eta aplikazio batzuek proxy aldagaiak erabat ignoratzen dituzte. Haien trafikoa bideratzeak 3. geruza esan nahi du: edukiontziak paketeak birbidaltzen ditu eta helbideak itzultzen ditu tunel interfazean.

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

Bi gauza erraz ahazten dira. Bezeroak bere atebide lehenetsia ostalari honetara zuzentzen duen bide bat behar du, eta erantzunek itzulera bidea aurkitu behar dute, goiko bideratzailean bide estatiko baten bidez edo bezeroei begira dagoen interfazean NAT bidez. Horietako bat gabe, tunelak eskaera kanpora eramaten du eta erantzuna desagertu egiten da.

Eragin-erradio zabalena ere badu. LAN osoarentzat atebide den ostalari batek gaizki konfiguratutako bezero bakoitza zure VPN kontutik bidaltzen du, eta tunela erortzean LAN-a iluntzen da edo ISP-ra itzultzen da kill switch-en arabera.

Egiaztatu irteerako bidea, eta gero itzuli atzera ordenan

Egiaztatu ordena honetan eta gelditu lehen hutsegitean: irteera helbidea izen espazioaren barruan, irteera helbidea ostalaritik proxyaren bidez, eta gero izen ebazpena ostalari pribatu baterako.

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

Lehen bi helbideek hornitzailearekin bat egin behar dute, eta hirugarrenak proxyaren bidez ebatzi behar du, izen-errore batekin huts egin beharrean. Lehen lerroak bat egitea eta bigarrenak huts egitea entzulea edo argitaratutako ataka oker daudela esan nahi du, ez tunela.

Atzera egitea konfigurazioaren alderantzizkoa da. Kendu proxy ingurune aldagaiak shell profilatik eta edozein systemd unitatetik, gero jaitsi pila izen espazio partekatua bere jabearekin desagertu dadin. Ezabatu argitaratutako ataka proxy zerbitzua ezabatu aurretik, bestela ostalariak inork irakurtzen ez duen loopback entzule bat gordeko du.

Aurrera egin aurretik, berretsi lau gauza: axola zaizun bezeroa benetan tunelera iristen da, izen espazioaren jabeak soilik argitaratzen ditu atakak, izen pribatuak nahi zenituen tokian ebazten dira, eta ezerk ez du entzuten loopback ez den ostalari helbide batean. Horietako bakoitzak isilka huts egiten du produkzioan, eta bakoitza goiko lerro bakarreko egiaztapena da.

Erlazionatutako artikuluak