SOCKS5 proxy-a OpenVPN-rako: TCP tunela edo aplikazioak proxytik pasatzea?

Irteera proxy baten bidez soilik onartzen duten sareak dira profil lanean ari zena bat-batean hiltzen den tokia. Proxy helbidea huts egite horretako aldagairik interesgutxiena da. Dena trafikoaren formak erabakitzen du, proxyak bidaliko duenak, izan ere proxy hauek byte-jario bat birbidaltzen dute eta UDP tunel bat ez da hori. Horrek bi arkitektura uzten ditu, eta leku ezberdinetan hausten dira.

Muga batek erabakitzen du diseinua

SOCKS5ek UDP elkartze modu bat zehazten du, hain zuzen. OpenVPN bezeroaren proxy euskarria, ordea, jarioen inguruan eraikita dago: socks-proxy TCP profiletarako dokumentatuta dago, eta HTTP CONNECT proxy batek ez du datagrametarako biderik bat ere. Dokumentazio-lerro batek arkitektura erabakitzen du konfigurazio-fitxategia ukitu aurretik.

Beraz, galdera ez da zein proxy aukeratu. Galdera da tunela jario bihurtzen den, ala datagrama izaten jarraitzen duen eta beste zerbaiti uzten dion proxing-a bere gain har dezan.

A aukera: bihurtu tunela jario

Horretarako TCP entzule bat duen zerbitzari bat eta proxya izendatzen duen bezero-profil bat behar dira. Bi zatiak beharrezkoak dira, eta jendeak ahazten duena zerbitzariaren aldea da:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Ordeztu azken lerroa http-proxy proxy.internal 8080 erabiliz, proxyak HTTP hitz egiten duenean, eta gehitu kredentzialen fitxategi bat eskatzen badu. Proxya zure VPN portura CONNECT egiteko prest egon behar da, eta zerbitzariak TCP bidez erantzun behar du; UDP soilik den entzule batek ez du saiakera aintzat hartzen. 443 aukeratzea erabaki praktikoa da, sare murriztaile askok hori eta gutxi gehiago onartzen dutelako.

Kostua TCP TCP gainean pilatzea da. Kanpoko segmentu bat galtzeak konexio hori partekatzen duen barneko jario guztiak blokeatzen ditu, beraz normalki independentea izango litzatekeen berreskuratzea partekatua bihurtzen da. Konfigurazioak ere denbora gehiago hartzen du, eta kanpoko bide ezegonkor bat tunel ezegonkor bihurtzen da, motel baten ordez.

B aukera: utzi tunela bakean

Tunelak UDPn egon behar duenean, tunela ez da ezer konfiguratzen duzun lekua. Horren ordez, aplikazioen irteerako TCP tokiko SOCKS entzule batera birbideratzen da, eta aplikazioek ez dute inoiz jakiten proxy bat existitzen denik. Linuxen hori normalean redsocks da, nat taulako NAT REDIRECT arau batekin batera.

TCP soilik, berriro. HTTP soilik den proxy batek, privoxy bezala, ezin du protokolo arbitrariorik birbidali, eta diseinu honek ez die aplikazioei datagrama euskarririk gehitzen ere.

Aplikazio bakoitzari proxyaz zuzenean hitz egitea hobea izaten da normalean softwareak hori onartzen duenean. Errazagoa da auditoria egitea, eta benetan ikus dezakezun leku batean huts egiten du.

Non huts egiten duen aukera bakoitzak

A aukerak huts egiten du zerbitzariak TCP entzulerik ez duenean, proxyak CONNECT helburua ukatzen duenean, edo kanpoko jarioa tunelak behar duenaren azpitik mugatzen denean. Lehenengo biek erregistro bat uzten dute proxyaren logean; hirugarrenak ezarri eta gero oker sentitzen den konexio bat uzten du. Irakurri log hori profila editatu aurretik, baimen-arazo bat gaitasun-arazo batetik bereizten duelako. Amaitutako CONNECT batek ikerketa tunelaren barrualdera eramaten du.

B aukerak huts egiten du datagramak behar dituen edozertarako, proxyak ulertzen ez dituen protokoloetarako, eta isilik birbideratze-araua badagoen baina bideratzeak trafikoa haren ondotik bidaltzen duen ostalarietan.

Inongo aukerak ez du gailuaren baldintza aldatzen. Paketeek oraindik TUN edo TAP nodo bat behar dute kernelak bideratu aurretik, beraz prozesuak oraindik baimena behar du /dev/net/tun fitxategian. Bilgarri batek nodo hori ireki ondoren gertatzen dena aldatzen du, ez ea behar duzun.

Frogatu zein bide eraiki duzun

Begiratu socket-ei, ez erretiluko ikonoari. VPN prozesuak proxy helbiderako konexio ezarri bat mantendu behar du, eta proxyak eskatu zitzaion helburua erregistratu behar zuen:

ss -tnp | grep openvpn

Gero joan tunelak soilik zerbitza dezakeen helmuga batera, eta tunelaren ebazleak soilik erantzun dezakeen izen batera. Hildako tunel batekin amaitutako proxy konexioak esan ohi du urruneko aldeak ez zuela inoiz zure profilean aipatutako garraioa eskaini.

Idatzi garraioa eta onartzen duen proxya leku iraunkor batean. Profil berak beste sare batean huts egiten duenean, ohar horrek proxyaren aldeko edo kontrako erabakia segundotan ematen du.