Politikas maršrutēšana pret SOCKS: kurš slānis patiešām proksē datu plūsmu

Jūs pievienojāt politikas maršrutu, kas VPN klienta datu plūsmu sūta uz resursdatoru, kurā 1080 portā darbojas SOCKS klausītājs. Paketes ierodas, klausītājs neko nefiksē, un savienojums karājas. Ar maršrutu viss ir kārtībā: nākamais lēciens izvēlas, kur pakete iet, un SOCKS ir saruna, kas klientam jāsāk. Salīdziniet trīs arhitektūras, ko cilvēki parasti domā, sūtot datu plūsmu caur proksiju, un kļūs skaidrs, kura daļa jūsu iestatījumā trūkst.

Maršrutēšana, DNAT un SOCKS maina dažādas lietas

Politikas maršruts pārraksta L3 lēmumu. Divas rindas ir pietiekamas, lai viena klienta datu plūsmu nosūtītu uz izvēlēto nākamo lēcienu:

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

Pēc tam kodols nodod paketi 10.50.0.2, un sākotnējais galamērķis joprojām ir IP galvenē. Ja 10.50.0.2 ir maršrutētājs, tas pārsūta paketi. Ja tas ir resursdators ar SOCKS dēmonu 1080 portā, pakete nav adresēta nekam, kas to varētu pieņemt, un arī DNAT uz 1080 portu nepalīdz, jo pārveidotā pakete joprojām nes sākotnējo lietojumprogrammas kravu, nevis SOCKS sveicienu.

SOCKS5 sākas ar versijas baitu, metožu sarakstu, autentifikācijas apmaiņu un pieprasījumu, kas nosauc galamērķi. Tie ir lietojumprogrammas dati. Neviens maršrutēšanas ieraksts un neviens netfilter mērķis tos neģenerē, un tas ir salīdzinājums vienā rindā: maršrutēšana izvēlas ceļu, SOCKS lūdz serverim izveidot otru savienojumu.

Pirmais gadījums: lietojumprogramma pati prot runāt SOCKS

Kad programmai ir proksija iestatījums, tas ir īsākais ceļš, un tam nav vajadzīgas kodola izmaiņas. Norādiet to uz klausītāju, sniedziet akreditācijas datus, ja serveris tos prasa, un izlemiet, vai vārdi tiek atrisināti lokāli vai nodoti proksijam. Ar curl tie ir dažādi karodziņi, un atšķirība ir svarīga, kad galamērķis tiek atrisināts tikai proksija pusē:

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

Lietojumprogrammām, kas ignorē proksija vides mainīgos vai atver neapstrādātus ligzdas, šādi palīdzēt nevar. Pārlūki un lielākā daļa HTTP rīku ir kārtībā; spēles klients, pasta dēmons vai patvaļīgs piegādātāja binārs parasti nav. Robeža ir katrai lietojumprogrammai un katram protokolam, tāpēc šī iespēja ir lieliska testēšanai un vāja kā atbilde visam VPN.

Otrais gadījums: adapteris, kas IP plūsmas pārveido proksija sesijās

Programmām, kas nespēj runāt SOCKS, pārveidei jānotiek kaut kur, kas izbeidz IP datu plūsmu un to vārdā atver proksija sesijas. Šim komponentam pieder tuneļa saskarne, tas pieņem plūsmas, ko izvēlējusies politikas maršrutēšana, veic SOCKS rokasspiedienu katrai un atjauno atbildes. Maršruts virza datu plūsmu uz to; adapters ir tas, kas izveido sesiju.

Izlasiet tā dokumentāciju, pirms uzticat tam visu apakštīklu. Daudzi adapteri labi pārnēsā TCP un apstrādā UDP tikai caur SOCKS5 UDP asociāciju, un neviens no tiem nepārvērš ICMP proksija datu plūsmā, tāpēc veiksmīgs ping neko nepasaka par proksija ceļu. DNS ir otrs slazds: ja adapters vārdus atrisina lokāli, tikai iekšējie ieraksti tiek atrisināti uz nepareizu atbildi vai pavisam neko.

Cilpu novēršana ir tā operatīvā detaļa, kas kož. Paša adaptera savienojumi ar SOCKS serveri nedrīkst tikt maršrutēti atpakaļ adapterī, tāpēc tā datu plūsmai ir vajadzīgs izņēmums noteikumā vai atsevišķa avota adrese. Kļūdieties šeit, un proksija sesija mēģinās proksēt pati sevi.

Trešais gadījums: resursdators patiešām ir maršrutēta vārteja

Dažkārt strādājošajā iestatījumā SOCKS nav nemaz. Attālais resursdators pārsūta paketes vai veic tām NAT, un uz avotu balstītais noteikums vienkārši izvēlas to kā izeju. Šāds dizains ir likumīgs, un tas izskaidro, kāpēc nokopēta konfigurācija darbojas vienā tīklā un neizdodas citā: noteikums ir identisks, trūkstošā daļa ir pārsūtīšanas pakalpojums otrā pusē.

Trīs gadījumi ātri atšķiras. Pārbaudiet, kas patiešām klausās, pēc tam apskatiet pirmos baitus, kas sasniedz resursdatoru:

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

Īsta SOCKS klienta pirmais kravas baits ir 0x05, versija sveicienā. Ja uztveršana rāda sākotnējos lietojumprogrammas datus, neviens SOCKS dēmons neatbildēs, jo sarunas nekad nav sākušās. Ja 1080 portā nekas neklausās, resursdators ir vārteja, un jautājums kļūst par to, vai tas pārsūta un vai pastāv atgriešanās ceļš.

Izvēlieties slāni ar četriem jautājumiem

Vai programmai ir proksija iestatījums? Izmantojiet to un apstājieties. Vai datu plūsmā ir UDP vai ICMP, kam jāizdzīvo? ICMP pārnēsā tikai maršrutēta vai NAT vārteja, un UDP ir vajadzīga SOCKS5 asociācija, ko atbalsta abas puses. Vai jāaptver katrs datora process, tostarp tie, ko nevarat konfigurēt? Tad jums vajag adapteri, kam pieder saskarne un kas izbeidz plūsmas. Vai varat pārņemt arī tā maršrutēšanu, DNS un cilpu novēršanas izņēmumus? Ja ne, vienkāršā vārteja izmaksās mazāk ekspluatācijā.

Vienu atšķirību ir vērts turēt skaidru. VPN klienta paša socks-proxy opcija apraksta, kā ārējais tuneļa savienojums sasniedz savu serveri, un neko nepasaka par iekšējo klienta plūsmu pārveidošanu. Abus nemitīgi jauc vienā un tajā pašā biļetē. Izlemiet, kāda saistība jums vajadzīga, pirms aiztiecat maršrutu.