Taisyklėmis pagrįstas maršrutizavimas prieš SOCKS: kuris sluoksnis iš tikrųjų proxy'ina srautą

Pridėjote taisyklėmis pagrįstą maršrutą, kuris VPN kliento srautą siunčia į prieglobos serverį, kuriame 1080 prievade veikia SOCKS klausytojas. Paketai atvyksta, klausytojas nieko neregistruoja, o ryšys pakimba. Su maršrutu viskas gerai: kitas šuolis parenka, kur paketas eina, o SOCKS yra pokalbis, kurį turi pradėti klientas. Palyginkite tris architektūras, kurias žmonės paprastai turi omenyje siųsdami srautą per proxy, ir paaiškės, kurios dalies jūsų konfigūracijoje trūksta.

Maršrutizavimas, DNAT ir SOCKS keičia skirtingus dalykus

Taisyklėmis pagrįstas maršrutas perrašo 3 sluoksnio sprendimą. Dviejų eilučių pakanka, kad vieno kliento srautas būtų nusiųstas pasirinktu kitu šuoliu:

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

Po to branduolys perduoda paketą 10.50.0.2, o pradinė paskirtis vis dar yra IP antraštėje. Jei 10.50.0.2 yra maršrutizatorius, jis persiunčia paketą. Jei tai prieglobos serveris su SOCKS tarnyba 1080 prievade, paketas nėra adresuotas niekam, kas galėtų jį priimti, ir DNAT į 1080 prievadą taip pat nepadeda, nes konvertuotas paketas vis dar neša pradinį programos naudingąjį krovinį, o ne SOCKS pasveikinimą.

SOCKS5 prasideda versijos baitu, metodų sąrašu, autentifikavimo mainais ir užklausa, kuri įvardija paskirtį. Tai programos duomenys. Joks maršrutizavimo įrašas ir joks netfilter tikslas jų negeneruoja, ir tai palyginimas vienoje eilutėje: maršrutizavimas parenka kelią, SOCKS prašo serverio sukurti antrą ryšį.

Pirmas atvejis: programa pati moka kalbėti SOCKS

Kai programa turi proxy nustatymą, tai trumpiausias kelias ir jam nereikia branduolio pakeitimų. Nukreipkite jį į klausytoją, pateikite prisijungimo duomenis, jei serveris jų prašo, ir nuspręskite, ar vardai sprendžiami vietoje, ar perduodami proxy. Su curl tai skirtingos vėliavėlės, ir skirtumas svarbus, kai paskirtis sprendžiama tik proxy pusėje:

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

Programoms, kurios nepaiso proxy aplinkos kintamųjų arba atidaro neapdorotus lizdus, šiuo būdu padėti negalima. Naršyklės ir dauguma HTTP įrankių yra gerai; žaidimo klientas, pašto tarnyba ar bet kokia tiekėjo binarija paprastai ne. Riba yra kiekvienai programai ir kiekvienam protokolui, todėl ši parinktis puiki testavimui ir silpna kaip atsakymas visam VPN.

Antras atvejis: adapteris, kuris IP srautus paverčia proxy sesijomis

Programoms, kurios nemoka kalbėti SOCKS, konversija turi vykti tame, kas užbaigia IP srautą ir jų vardu atidaro proxy sesijas. Tas komponentas turi tunelio sąsają, priima srautus, kuriuos parinko taisyklėmis pagrįstas maršrutizavimas, atlieka SOCKS rankos paspaudimą kiekvienam ir atkuria atsakymus. Maršrutas nukreipia srautą į jį; adapteris yra tai, kas sukuria sesiją.

Perskaitykite jo dokumentaciją, prieš patikėdami jam visą potinklį. Daugelis adapterių gerai perneša TCP, o UDP apdoroja tik per SOCKS5 UDP asociaciją, ir nė vienas jų nepaverčia ICMP proxy srautu, todėl sėkmingas ping nieko nesako apie proxy kelią. DNS yra kita spąstai: jei adapteris vardus sprendžia vietoje, tik vidiniai įrašai išsprendžiami į neteisingą atsakymą arba visai nieko.

Kilpų prevencija yra ta operacinė detalė, kuri kandžiojasi. Paties adapterio ryšiai su SOCKS serveriu neturi būti maršrutizuojami atgal į adapterį, todėl jo srautui reikia išimties taisyklėje arba atskiro šaltinio adreso. Suklyskite čia, ir proxy sesija bandys proxy'inti pati save.

Trečias atvejis: prieglobos serveris iš tikrųjų yra maršrutizuotas šliuzas

Kartais veikianti konfigūracija visai neturi SOCKS. Nuotolinis prieglobos serveris persiunčia paketus arba jiems atlieka NAT, o šaltiniu pagrįsta taisyklė tiesiog parenka jį kaip išėjimą. Tokia konstrukcija yra teisėta, ir ji paaiškina, kodėl nukopijuota konfigūracija veikia viename tinkle, o kitame nepavyksta: taisyklė ta pati, trūkstama dalis yra persiuntimo tarnyba kitoje pusėje.

Trys atvejai atsiskiria greitai. Patikrinkite, kas iš tikrųjų klausosi, tada pažiūrėkite į pirmuosius baitus, pasiekiančius prieglobos serverį:

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

Tikro SOCKS kliento pirmasis naudingojo krovinio baitas yra 0x05, versija pasveikinime. Jei įrašas rodo pradinius programos duomenis, jokia SOCKS tarnyba neatsakys, nes derybos taip ir neprasidėjo. Jei 1080 prievade niekas neklausosi, prieglobos serveris yra šliuzas, ir kyla klausimas, ar jis persiunčia ir ar egzistuoja grįžimo kelias.

Pasirinkite sluoksnį keturiais klausimais

Ar programa turi proxy nustatymą? Naudokitės juo ir sustokite. Ar sraute yra UDP ar ICMP, kurie turi išlikti? ICMP perneša tik maršrutizuotas arba NAT šliuzas, o UDP reikia SOCKS5 asociacijos, kurią palaiko abi pusės. Ar reikia aprėpti kiekvieną kompiuterio procesą, įskaitant tuos, kurių negalite sukonfigūruoti? Tada reikia adapterio, kuris valdo sąsają ir užbaigia srautus. Ar galite prisiimti ir jo maršrutizavimą, DNS bei kilpų prevencijos išimtis? Jei ne, paprastas šliuzas kainuos mažiau eksploatuoti.

Vieną skirtumą verta išlaikyti aiškiai. VPN kliento savoji socks-proxy parinktis aprašo, kaip išorinis tunelio ryšys pasiekia savo serverį, ir nieko nesako apie vidinių kliento srautų konvertavimą. Abu nuolat painiojami tame pačiame biliete. Nuspręskite, kokio ryšio jums reikia, prieš liesdami maršrutą.