Poliitikapõhine marsruutimine vs SOCKS: milline kiht tegelikult liiklust puhverserveri kaudu suunab

Lisasite poliitikapõhise marsruudi, mis saadab VPN-kliendi liikluse hostile, kus jookseb SOCKS-kuulaja pordil 1080. Paketid saabuvad, kuulaja ei logi midagi ja ühendus jääb rippuma. Marsruudiga on kõik korras: järgmine hüpe valib, kuhu pakett läheb, ja SOCKS on vestlus, mille peab algatama klient. Võrrelge kolme arhitektuuri, mida inimesed tavaliselt silmas peavad, kui nad liiklust puhverserveri kaudu saadavad, ja selgub, milline osa teie seadistusest puudub.

Marsruutimine, DNAT ja SOCKS muudavad erinevaid asju

Poliitikapõhine marsruut kirjutab ümber L3-otsuse. Kahest reast piisab, et saata ühe kliendi liiklus valitud järgmisele hüppele:

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

Pärast seda annab kernel paketi 10.50.0.2-le, kusjuures algne sihtkoht on endiselt IP-päises. Kui 10.50.0.2 on ruuter, edastab see paketi edasi. Kui see on host, kus jookseb SOCKS-deemon pordil 1080, ei ole pakett adresseeritud millelegi, mis saaks selle vastu võtta, ja ka DNAT pordile 1080 ei aita, sest tõlgitud pakett kannab endiselt algset rakenduse kasulikku koormust, mitte SOCKS-tervitust.

SOCKS5 algab versioonibaidiga, meetodite loendiga, autentimisvahetusega ja päringuga, mis nimetab sihtkoha. See on rakenduse andmed. Ükski marsruudikirje ega netfilteri sihtmärk ei genereeri seda, ja see on võrdlus ühes reas: marsruutimine valib tee, SOCKS palub serveril teha teise ühenduse.

Esimene juhtum: rakendus oskab ise SOCKS-it rääkida

Kui programmil on puhverserveri säte, on see lühim tee ja see ei nõua kerneli muudatust. Suunake see kuulajale, esitage volitused, kui server neid küsib, ja otsustage, kas nimed lahendatakse kohapeal või antakse puhverserverile edasi. curl-i puhul on need erinevad lipud, ja vahe on oluline, kui sihtkoht lahendatakse ainult puhverserveri poolelt:

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

Rakendusi, mis eiravad puhverserveri keskkonnamuutujaid või avavad töötlemata sokleid, ei saa sel viisil aidata. Brauserid ja enamik HTTP-tööriistu on korras; mänguklient, postidaemon või suvaline tarnija binaarfail tavaliselt ei ole. Piir on rakenduse ja protokolli kaupa, seetõttu on see valik testimiseks suurepärane ja kogu VPN-i vastusena nõrk.

Teine juhtum: adapter, mis teisendab IP-voogusid puhverserveri seanssideks

Programmide puhul, mis ei oska SOCKS-it rääkida, peab teisendus toimuma milleski, mis lõpetab IP-liikluse ja avab nende nimel puhverserveri seansse. See komponent omab tunneliliidest, võtab vastu voogusid, mille poliitikapõhine marsruutimine valis, teeb igaühe jaoks SOCKS-käepigistuse ja koostab vastused uuesti. Marsruut suunab liikluse selle juurde; adapter on see, mis seansi loob.

Lugege selle dokumentatsiooni enne, kui usaldate sellele tervet alamvõrku. Paljud adapterid kannavad TCP-d hästi ja töötlevad UDP-d ainult SOCKS5 UDP-assotsiatsiooni kaudu, ja ükski neist ei muuda ICMP-d puhverserveri liikluseks, seega edukas ping ei ütle puhverserveri tee kohta midagi. DNS on teine lõks: kui adapter lahendab nimesid kohapeal, lahendatakse ainult sisemised kirjed vale vastuse või üldse mitte millegi vastu.

Silmuste vältimine on see operatiivne detail, mis hammustab. Adapteri enda ühendusi SOCKS-serveriga ei tohi marsruutida tagasi adapterisse, seega vajab selle liiklus reeglis erandit või eraldi lähteaadressi. Kui selle valesti teete, proovib puhverserveri seanss iseennast puhverserverina kasutada.

Kolmas juhtum: host on tegelikult marsruuditud lüüs

Mõnikord ei sisalda töötav seadistus üldse SOCKS-it. Kaugem host edastab pakette või teeb neile NAT-i, ja lähtepõhine reegel valib selle lihtsalt väljundiks. Selline lahendus on legitiimne ja selgitab, miks kopeeritud konfiguratsioon ühes võrgus töötab ja teises ebaõnnestub: reegel on identne, puudu on edastusteenus teisel pool.

Kolm juhtumit eralduvad kiiresti. Kontrollige, mis tegelikult kuulab, ja seejärel vaadake esimesi baite, mis hostini jõuavad:

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

Päris SOCKS-kliendi esimene kasuliku koormuse bait on 0x05, versioon tervituses. Kui püüdmine näitab selle asemel algseid rakenduse andmeid, ei vasta ükski SOCKS-deemon, sest läbirääkimised ei alanudki. Kui pordil 1080 ei kuula miski, on host lüüs, ja küsimuseks saab, kas see edastab pakette ja kas tagasitee on olemas.

Valige kiht nelja küsimusega

Kas programmil on puhverserveri säte? Kasutage seda ja lõpetage seal. Kas liikluses on UDP-d või ICMP-d, mis peavad üle elama? ICMP-d kannab ainult marsruuditud või NAT-lüüs, ja UDP vajab SOCKS5-assotsiatsiooni, mida mõlemad otsad toetavad. Kas kõik masina protsessid peavad olema kaetud, sealhulgas need, mida te ei saa seadistada? Siis vajate adapterit, mis omab liidest ja lõpetab voogusid. Kas saate üle võtta ka selle marsruutimise, DNS-i ja silmuste vältimise erandid? Kui ei, on tavaline lüüs odavam käitada.

Üht erinevust tasub selgelt hoida. VPN-kliendi enda socks-proxy valik kirjeldab, kuidas välimine tunnelühendus oma serverini jõuab, ja ei ütle midagi sisemiste kliendivoogude teisendamise kohta. Neid kahte aetakse samas piletis pidevalt segi. Otsustage, millist suhet vajate, enne kui marsruuti puutute.