OpenVPN SOCKS5 bidez: batu bertsioa, garraioa eta DNSa

Lan-estazio honetatik ateratzeko bide bat SOCKS proxy bat da, eta haren atzean dagoen OpenVPN aplikazioak konexio-denborazkoan erortzen du, erabilgarri den xehetasunik gabe. Makina bereko nabigatzaile batek proxy horren bidez funtzionatzen du, kredentzialak zuzenak dira, eta portuak erantzuten du. Hiru gauza askotan desberdintzen dira lehenengo egiaztatzeko: proxyak hitz egiten duen SOCKS bertsioa, bezeroak aukeratu duen garraioa eta izenen ebazpena non gertatzen den. Egiaztatu horietako bakoitza suebakia txartzat jo aurretik.

Batu SOCKS bertsioa suebakia baino lehen

Komunitateko OpenVPNak SOCKS5 hitz egiten du socks-proxy aukeraren bidez. Eraman ezazu SOCKS4 bakarrik eskaintzen duen proxy batera, eta TCP konexioa ireki eta gero trabatu egiten da, bezeroak beste muturrak inoiz analizatzen ez duen agur bati erantzunaren zain baitago. Kanpotik, trabatze horrek portu iragazi bat ematen du, eta horregatik bertsioaren galdera edozein suebaki-arau baino lehen dator. SOCKSa ezagutzen duen eskaera batek komando bakarrean erabakitzen du.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

Osatutako eskaera batek bi gauza frogatzen ditu aldi berean: proxyak SOCKS eskaera onartu zuela eta izena ebatz zuela. Ez da URL eskema behar, curl-ek host huts bat HTTP gisa tratatzen baitu, eta hori nahikoa da proba honetarako.

Eskaera horrek bezeroaren logak ezkutatzen duen hutsegitea ere baztertzen du. Proxyak nabigatzailea onar dezake eta VPN helmuga uko egin, eta kasu horretan ukapena CONNECTen gertatzen da, VPN autentifikazioaren aurretik. OpenVPNak denborazko bat baino ez du jakinarazten, beraz proxyaren erantzuna da behar duzun froga.

Garraioak TCP izan behar du bi aldeetan

SOCKS5ek TCP korronte bat darama hemen, beraz tuneleko berak proto tcp-client behar du. Oraindik UDPn ezarrita dagoen profil bat ez da bide honetatik ibiliko, bezeroak ez baitu protokoloaren UDP elkarketa modua erabiltzen. Profila aldatzea benetako aldaketa da, ez formalitatea: urrutiko muturrak TCPn entzun behar du portu berean. Karga orduan TCP TCPren barruan bihurtzen da, non galdutako segmentua bi aldiz birbidaltzen den eta erritmoa okertzen den, eta saio interaktiboek askoz gehiago nabaritzen dute transferentzia handiek baino.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

Direktibak proxyaren ostalaria, aukerako portua eta aukerako kredentzial-fitxategia hartzen ditu. Jarri horiek profilean bertan, kopia batek beste leku batean berdin joka dezan.

Mugatu kate osoa edukiontzi bakarrera

Kate ostalarian egiteak haren bide lehenetsia hartzea esan nahi du, eta ebazlea inork geroago azaldu ezin duen egoeran uztea. Namespace edo edukiontzi batek mugatzen du hori, beraz ostalariak bere bidea mantentzen du SOCKS jauziak eta tuneleak elkarrekin bizi diren bitartean. Bertan ez da ezer altxatzen tunel gailu bat, gailu hori konfiguratzeko eskubideak eta proxy irisgarri bat gabe. Compose zerbitzu batek cap_add: NET_ADMIN eta bind muntatutako /dev/net/tun batekin lortzen du.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Bikote hori edukiontzia pribilegioekin exekutatzea baino estuagoa da, eta behar den gailu-sarbide osoa da. Tor bezero batek edo proxy edukiontzi bereizi batek entzulea eman dezake. Edozein kasutan, lotu loopback-era, eta iritsi hara namespacetik ostalariaren bidez, proxya sarera agerian utzi beharrean.

Izenen ebazpena da isolamenduak huts egiten duen tokia

Paketeak eramaten dituen eta aldi berean ostalariaren ebazlea galdetzen duen tuneleak ez du ezer isolatu. Bi gauzak egiten dute isolamendua erreal: namespacelak bere ebazlea du, eta haren kontsultak proxyaren edo tunelearen bidez bidaiatzen dute, inoiz ez interfaze fisikoaren bidez. Erabili bi izen probarako: tunelearen atzean bakarrik existitzen den bat, eta bide bera jarraitu beharko lukeen publiko bat.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

Urrutiko aldea izena ebazten badu eta publikoa ez, katea hautakorra da, ez hautsia, eta desberdintasunak esaten dizu kontsulta bakoitzak zein bide hartu zuen. Biak ostalaritik ebazten badira baina bat ere ez edukiontziaren barruan, edukiontziak oraindik ostalariaren ebazlea maileguan hartzen du. Idatzi aurkitutako ebazle-fitxategia, hori baita aldatu behar den ezarpena.

Frogatu jauzi bakoitza ordenan

Zerrenda laburra da. SOCKS5 eskaera batek erantzuna jasotzen du, tuneleak proxyaren bidez bere entzulera iristen da, eta namespacea uzten duten paketeek urrutiko aldeak espero duen helbidea daramate. Egiaztatu bakoitza banan-banan, konfigurazio gehiago pilatu beharrean. Bezeroak konektatuta dagoela esaten duenean eta ezer mugitzen ez denean, haustura ia beti bigarren edo hirugarren egitatean dago.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

Idatzi funtzionatu zuen konbinazioa: SOCKS bertsioa, garraioa, ebazlea eta namespace ezarpenak. Kate hau bigarren aldiz memoriatik ebazteak oharrak baino gehiago kostatzen du. Gorde lau egitate horiek tikean, eta ez txat hari batean.

Konektatuta dagoela jakinarazi eta ezer pasatzen ez duen kate batek porrot egin du normalean oraindik frogatu ez duzun jauzian. Probatu jauzi hori beste geruza bat gehitu aurretik.