Rrugëtimi me politikë kundrejt SOCKS: cila shtresë bën realisht proxy

Keni shtuar një rrugë politike që dërgon trafikun e një klienti VPN drejt një hosti që ekzekuton një dëgjues SOCKS në portën 1080. Paketat mbërrijnë, dëgjuesi nuk regjistron asgjë, dhe lidhja mbetet e varur. Rruga nuk ka asgjë të gabuar: kërcyesi tjetër zgjedh ku shkon një paketë, dhe SOCKS është një bisedë që klienti duhet ta nisë. Krahasoni tre arkitekturat që njerëzit zakonisht nënkuptojnë kur dërgojnë trafik përmes një proxy, dhe do të bëhet e qartë cila pjesë mungon në konfigurimin tuaj.

Rrugëtimi, DNAT dhe SOCKS ndryshojnë gjëra të ndryshme

Një rrugë politike rishkruan një vendim të shtresës 3. Dy rreshta mjaftojnë për të dërguar trafikun e një klienti drejt një kërcyesi tjetër të zgjedhur:

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

Pas kësaj, kerneli ia dorëzon paketën 10.50.0.2, ndërsa destinacioni origjinal është ende në kokën IP. Nëse 10.50.0.2 është një ruter, ai e përcjell paketën. Nëse është një host me një demon SOCKS në 1080, paketa nuk është adresuar drejt asgjëje që mund ta pranojë, dhe DNAT drejt portës 1080 nuk ndihmon as, sepse një paketë e përkthyer ende mbart ngarkesën origjinale të aplikacionit në vend të një përshëndetjeje SOCKS.

SOCKS5 fillon me një bajt versioni, një listë metodash, një shkëmbim vërtetimi dhe një kërkesë që emërton destinacionin. Këto janë të dhëna aplikacioni. Asnjë hyrje rrugëtimi dhe asnjë objektiv netfilter nuk i gjeneron ato, dhe ky është krahasimi në një rresht: rrugëtimi zgjedh një shteg, SOCKS i kërkon një serveri të bëjë një lidhje të dytë.

Rasti i parë: aplikacioni mund të flasë vetë SOCKS

Kur programi ka një cilësim proxy, kjo është rruga më e shkurtër dhe nuk kërkon ndryshim në kernel. Drejtojeni atë drejt dëgjuesit, jepni kredencialet nëse serveri i kërkon, dhe vendosni nëse emrat zgjidhen lokalisht ose i kalohen proxy-t. Me curl këto janë flamuj të ndryshëm, dhe ndryshimi ka rëndësi kur destinacioni zgjidhet vetëm nga ana e proxy-t:

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

Aplikacionet që injorojnë variablat e mjedisit të proxy-t, ose që hapin soketa të papërpunuara, nuk mund të ndihmohen në këtë mënyrë. Shfletuesit dhe shumica e mjeteve HTTP janë në rregull; një klient loje, një demon poste ose një binar arbitrar i një furnizuesi zakonisht nuk janë. Kufiri është për çdo aplikacion dhe çdo protokoll, prandaj ky opsion është i shkëlqyer për testim dhe i dobët si përgjigje për të gjithë VPN-në.

Rasti i dytë: një përshtatës që konverton rrjedhat IP në sesione proxy

Për programet që nuk mund të flasin SOCKS, konvertimi duhet të ndodhë në diçka që përfundon trafikun IP dhe hap sesione proxy në emrin e tyre. Ai komponent zotëron një ndërfaqe tuneli, pranon rrjedhat që zgjodhi rrugëtimi me politikë, kryen shtrëngimin e duarve SOCKS për secilën dhe rindërton përgjigjet. Rruga e drejton trafikun drejt tij; përshtatësi është ai që krijon sesionin.

Lexoni dokumentacionin e tij përpara se t'i besoni një nënrrjet të tërë. Shumë përshtatës e mbajnë mirë TCP-në dhe e trajtojnë UDP-në vetëm përmes një asociacioni UDP të SOCKS5, dhe asnjëri prej tyre nuk e kthen ICMP-në në trafik proxy, kështu që një ping i suksesshëm nuk thotë asgjë për shtegun e proxy-t. DNS është kurthi tjetër: nëse përshtatësi i zgjidh emrat lokalisht, regjistrimet vetëm të brendshme zgjidhen në përgjigjen e gabuar, ose në asgjë.

Parandalimi i sytheve është detaji operativ që të kafshon. Lidhjet e vetë përshtatësit drejt serverit SOCKS nuk duhet të rrugëtohen përsëri në përshtatës, prandaj trafiku i tij ka nevojë për një përjashtim në rregull ose një adresë burimi të dedikuar. Gabojeni këtë dhe sesioni proxy do të përpiqet të bëjë proxy vetveten.

Rasti i tretë: hosti është në të vërtetë një portë e rrugëtuar

Ndonjëherë konfigurimi që funksionon nuk përmban fare SOCKS. Hosti i largët i përcjell paketat ose u bën NAT, dhe rregulli i bazuar në burim thjesht e zgjedh atë si dalje. Ai dizajn është legjitim dhe shpjegon përse një konfigurim i kopjuar funksionon në një rrjet dhe dështon në një tjetër: rregulli është identik, pjesa që mungon është një shërbim përcjelljeje në anën tjetër.

Tre rastet ndahen shpejt. Kontrolloni çfarë dëgjon realisht, pastaj shikoni bajtët e parë që arrijnë në host:

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

Bajti i parë i ngarkesës së një klienti SOCKS të vërtetë është 0x05, versioni në përshëndetje. Nëse kapja tregon në vend të tij të dhëna origjinale të aplikacionit, asnjë demon SOCKS nuk do të përgjigjet, sepse negociatat nuk filluan kurrë. Nëse asgjë nuk dëgjon në 1080, hosti është një portë, dhe pyetja bëhet nëse përcjell dhe nëse ekziston një shteg kthimi.

Zgjidhni shtresën me katër pyetje

A ka programi një cilësim proxy? Përdoreni dhe ndaloni aty. A përfshin trafiku UDP ose ICMP që duhet të mbijetojnë? Vetëm një portë e rrugëtuar ose me NAT mbart ICMP, dhe UDP kërkon një asociacion SOCKS5 që të dy skajet e mbështesin. A duhet të mbulohet çdo proces në makinë, përfshirë ata që nuk mund t'i konfiguroni? Atëherë ju nevojitet një përshtatës që zotëron ndërfaqen dhe përfundon rrjedhat. A mund të merrni përsipër edhe rrugëtimin, DNS-në dhe përjashtimet e parandalimit të sytheve? Nëse jo, porta e thjeshtë do të kushtojë më pak për t'u operuar.

Një dallim ia vlen të mbahet drejt. Opsioni socks-proxy i vetë klientit VPN përshkruan si lidhja e tunelit të jashtëm arrin serverin e tij, dhe nuk thotë asgjë për konvertimin e rrjedhave të brendshme të klientit. Të dyja ngatërrohen vazhdimisht në të njëjtin tiketë. Vendosni çfarë marrëdhënieje ju nevojitet përpara se të prekni një rrugë.