Politika bidezko bideratzea SOCKS-en aurka: zein geruzak egiten du benetan proxy

VPN bezero baten trafikoa 1080 portuan SOCKS entzule bat duen ostalari batera bidaltzen duen politika-ibilbide bat gehitu duzu. Paketeak iristen dira, entzuleak ez du ezer erregistratzen, eta konexioa zintzilik geratzen da. Ibilbidean ez dago ezer gaizki: hurrengo jauziak pakete bat nora doan aukeratzen du, eta SOCKS bezeroak hasi behar duen elkarrizketa bat da. Konparatu jendeak proxy baten bidez trafikoa bidaltzean normalean esan nahi dituen hiru arkitekturak, eta argi geratuko da zure ezarpenari zein pieza falta zaion.

Bideratzeak, DNATek eta SOCKSek gauza desberdinak aldatzen dituzte

Politika-ibilbide batek L3 geruzako erabakia berridazten du. Bi lerro nahikoa dira bezero baten trafikoa aukeratutako hurrengo jaukira bidaltzeko:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Horren ondoren, kernelak paketea 10.50.0.2ri ematen dio, jatorrizko helmuga IP goiburuan oraindik dagoela. 10.50.0.2 bideratzaile bat bada, paketea aurrera bidaltzen du. 1080n SOCKS deabru bat duen ostalari bat bada, paketea ez dago onar dezakeen ezeri zuzenduta, eta 1080 porturako DNATek ere ez du laguntzen, itzulitako pakete batek jatorrizko aplikazioaren karga erabilgarria daramalako SOCKS agur baten ordez.

SOCKS5 bertsio byte batekin, metodo zerrenda batekin, autentifikazio truke batekin eta helmuga izendatzen duen eskaera batekin hasten da. Aplikazio datuak dira horiek. Inongo bideratze-sarrerak eta netfilter helburuak ez du hori sortzen, eta horra konparazioa lerro bakarrean: bideratzeak bide bat aukeratzen du, SOCKSek zerbitzari bati bigarren konexio bat egiteko eskatzen dio.

Lehen kasua: aplikazioak berak SOCKS hitz egin dezake

Programak proxy ezarpen bat duenean, hau da biderik laburrena eta ez du kernel aldaketarik behar. Eraman ezazu entzulera, eman kredentzialak zerbitzariak eskatzen baditu, eta erabaki izenak tokian bertan ebazten diren edo proxyari pasatzen zaizkion. curl-ekin bandera desberdinak dira, eta aldea garrantzitsua da helmuga proxyaren aldetik bakarrik ebazten denean:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Proxy ingurune-aldagaiak ez dituzten aplikazioek, edo socket gordinak irekitzen dituztenek, ezin dute honela laguntzarik jaso. Nabigatzaileak eta HTTP tresna gehienak ondo daude; joko bezero bat, posta deabru bat edo hornitzaile baten edozein bitar ez, normalean. Muga aplikazio bakoitzeko eta protokolo bakoitzeko da, eta horregatik aukera hau bikaina da probetarako eta ahula VPN osoarentzako erantzun gisa.

Bigarren kasua: IP fluxuak proxy saio bihurtzen dituen egokitzailea

SOCKS hitz egin ezin duten programetarako, bihurketak IP trafikoa amaitzen duen eta haien izenean proxy saioak irekitzen dituen zerbaitetan gertatu behar du. Osagai horrek tunel interfaze bat dauka, politika bidezko bideratzeak hautatutako fluxuak onartzen ditu, bakoitzeko SOCKS esku-ematea egiten du eta erantzunak berreraikitzen ditu. Ibilbideak trafikoa berarengana bideratzen du; egokitzailea da saioa sortzen duena.

Irakurri haren dokumentazioa azpisare oso bat fidatu aurretik. Egokitzaile askok TCP ondo eramaten dute eta UDP soilik SOCKS5 UDP elkarte baten bidez lantzen dute, eta batek ere ez du ICMP proxy trafiko bihurtzen, beraz ping arrakastatsu batek ez du ezer esaten proxy bideari buruz. DNS da beste tranpa: egokitzaileak izenak tokian bertan ebazten baditu, barne-erregistro soilak erantzun okerrera edo ezer ezera ebazten dira.

Begiztak saihestea da hozka egiten duen ustiapen xehetasuna. Egokitzailearen beraren SOCKS zerbitzarirako konexioak ezin dira egokitzaile horretara bideratu, beraz haren trafikoak salbuespen bat behar du arauan edo iturburu-helbide dedikatu bat. Gaizki eginez gero, proxy saioak bere burua proxiatzen saiatuko da.

Hirugarren kasua: ostalaria benetan bideratutako atebide bat da

Batzuetan funtzionatzen duen ezarpenean ez dago SOCKSik batere. Urruneko ostalariak paketeak aurrera bidaltzen ditu edo NAT egiten die, eta iturburuan oinarritutako arauak, besterik gabe, irteera gisa hautatzen du. Diseinu hori zilegi da, eta azaltzen du zergatik konfigurazio kopiatu batek sare batean funtzionatzen duen eta bestean huts egiten duen: araua berbera da, falta den pieza beste aldeko birbidaltze zerbitzu bat da.

Hiru kasuak azkar bereizten dira. Egiaztatu zer ari den entzuten, eta gero begiratu ostalarira iristen diren lehen byteak:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Benetako SOCKS bezero baten lehen karga bytea 0x05 da, agurreko bertsioa. Harrapaketak jatorrizko aplikazio datuak erakusten baditu horren ordez, inongo SOCKS deabruk ez du erantzungo, negoziazioa ez baitzen inoiz hasi. 1080n ezer entzuten ez badu, ostalaria atebide bat da, eta galdera bihurtzen da aurrera bidaltzen duen eta itzultzeko bide bat badagoen.

Aukeratu geruza lau galderarekin

Programak proxy ezarpenik badu? Erabili eta gelditu hor. Trafikoak bizirik iraun behar duen UDP edo ICMP badauka? Bideratutako edo NAT atebide batek bakarrik darama ICMP, eta UDPk bi muturrek onartzen duten SOCKS5 elkarte bat behar du. Makinako prozesu guztiak estali behar dira, konfiguratu ezin dituzunak barne? Orduan interfazea daukan eta fluxuak amaitzen dituen egokitzaile bat behar duzu. Haren bideratzea, DNSa eta begiztak saihesteko salbuespenak ere har ditzakezu zure gain? Hala ez bada, atebide arruntak gutxiago kostako du ustiatzeko.

Bereizketa bat argi mantentzea merezi du. VPN bezero baten socks-proxy aukerak deskribatzen du nola kanpoko tunel konexioak bere zerbitzarira iristen den, eta ez du ezer esaten barneko bezero fluxuen bihurketari buruz. Biak etengabe nahasten dira tiket berean. Erabaki zein harreman behar duzun ibilbide bat ukitu aurretik.