Käytäntöpohjainen reititys vs SOCKS: mikä kerros oikeasti välittää liikennettä

Lisäsit käytäntöpohjaisen reitin, joka lähettää VPN-asiakkaan liikenteen isäntään, jossa SOCKS-kuuntelija toimii portissa 1080. Paketit saapuvat, kuuntelija ei kirjaa mitään, ja yhteys jää jumiin. Reitissä ei ole mitään vikaa: seuraava hyppy valitsee, mihin paketti menee, ja SOCKS on keskustelu, jonka asiakkaan on aloitettava. Vertaa kolmea arkkitehtuuria, joita ihmiset yleensä tarkoittavat lähettäessään liikennettä välityspalvelimen kautta, ja selviää, mikä osa asetuksestasi puuttuu.

Reititys, DNAT ja SOCKS muuttavat eri asioita

Käytäntöpohjainen reitti kirjoittaa uudelleen L3-tason päätöksen. Kaksi riviä riittää siihen, että yhden asiakkaan liikenne lähetetään valitulle seuraavalle hypylle:

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

Sen jälkeen ydin luovuttaa paketin osoitteelle 10.50.0.2, ja alkuperäinen kohde on edelleen IP-otsikossa. Jos 10.50.0.2 on reititin, se välittää paketin eteenpäin. Jos se on isäntä, jossa on SOCKS-taustaohjelma portissa 1080, pakettia ei ole osoitettu millekään, mikä voisi vastaanottaa sen, eikä DNAT porttiin 1080 auta, koska käännetty paketti kantaa edelleen alkuperäisen sovelluksen hyötykuorman SOCKS-tervehdyksen sijaan.

SOCKS5 alkaa versiotavulla, menetelmäluettelolla, todennuksen vaihdolla ja pyynnöllä, joka nimeää kohteen. Se on sovellusdataa. Mikään reittimerkintä tai netfilter-kohde ei tuota sitä, ja siinä vertailu yhdellä rivillä: reititys valitsee polun, SOCKS pyytää palvelinta tekemään toisen yhteyden.

Tapaus yksi: sovellus osaa itse puhua SOCKSia

Kun ohjelmassa on välityspalvelinasetus, se on lyhin polku eikä vaadi ytimen muutosta. Osoita se kuuntelijaan, anna tunnistetiedot, jos palvelin pyytää niitä, ja päätä, ratkaistaanko nimet paikallisesti vai välitetäänkö ne välityspalvelimelle. curlissa ne ovat eri lippuja, ja ero on tärkeä, kun kohde ratkaistaan vain välityspalvelimen puolelta:

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

Sovelluksia, jotka jättävät välityspalvelimen ympäristömuuttujat huomiotta tai avaavat raakoja soketteja, ei voi auttaa tällä tavalla. Selaimet ja useimmat HTTP-työkalut ovat kunnossa; peliasiakas, sähköpostitaustaohjelma tai mielivaltainen toimittajan binääri ei yleensä ole. Raja on sovellus- ja protokollakohtainen, siksi tämä vaihtoehto on erinomainen testaukseen ja heikko vastaus koko VPN:lle.

Tapaus kaksi: adapteri, joka muuntaa IP-virrat välityspalvelinistunnoiksi

Ohjelmille, jotka eivät osaa puhua SOCKSia, muunnoksen on tapahduttava jossakin, mikä lopettaa IP-liikenteen ja avaa välityspalvelinistuntoja niiden puolesta. Tämä komponentti omistaa tunnelirajapinnan, ottaa vastaan käytäntöpohjaisen reitityksen valitsemat virrat, suorittaa SOCKS-kättelyn jokaiselle ja rakentaa vastaukset uudelleen. Reitti ohjaa liikenteen siihen; adapteri on se, mikä luo istunnon.

Lue sen dokumentaatio ennen kuin uskot sille kokonaisen aliverkon. Monet adapterit kuljettavat TCP:tä hyvin ja käsittelevät UDP:tä vain SOCKS5:n UDP-liiton kautta, eikä mikään niistä muunna ICMP:tä välityspalvelinliikenteeksi, joten onnistunut ping ei kerro mitään välityspalvelimen polusta. DNS on toinen ansa: jos adapteri ratkaisee nimet paikallisesti, vain sisäiset tietueet ratkeavat väärään vastaukseen tai eivät mihinkään.

Silmukoiden esto on se käytännön yksityiskohta, joka puree. Adapterin omia yhteyksiä SOCKS-palvelimeen ei saa reitittää takaisin adapteriin, joten sen liikenne tarvitsee poikkeuksen säännössä tai oman lähiosoitteen. Tee se väärin, ja välityspalvelinistunto yrittää välittää itseään.

Tapaus kolme: isäntä on oikeastaan reititetty yhdyskäytävä

Joskus toimiva asetus ei sisällä lainkaan SOCKSia. Etäisäntä välittää paketteja eteenpäin tai tekee niille NATin, ja lähdeperusteinen sääntö yksinkertaisesti valitsee sen uloskäynniksi. Sellainen suunnittelu on laillista, ja se selittää, miksi kopioitu kokoonpano toimii yhdessä verkossa ja epäonnistuu toisessa: sääntö on sama, puuttuva osa on välityspalvelu toisella puolella.

Kolme tapausta erottuvat nopeasti. Tarkista, mikä oikeasti kuuntelee, ja katso sitten ensimmäisiä tavuja, jotka saapuvat isäntään:

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

Todellisen SOCKS-asiakkaan ensimmäinen hyötykuormatavu on 0x05, tervehdyksen versio. Jos kaappaus näyttää sen sijaan alkuperäistä sovellusdataa, mikään SOCKS-taustaohjelma ei vastaa, koska neuvottelu ei koskaan alkanut. Jos portissa 1080 ei kuuntele mikään, isäntä on yhdyskäytävä, ja kysymykseksi tulee, välittääkö se ja onko paluupolkua.

Valitse kerros neljällä kysymyksellä

Onko ohjelmassa välityspalvelinasetus? Käytä sitä ja lopeta siihen. Sisältääkö liikenne UDP:tä tai ICMP:tä, jonka on selvittävä? Vain reititetty tai NAT-yhdyskäytävä kuljettaa ICMP:tä, ja UDP tarvitsee SOCKS5-liiton, jota molemmat päät tukevat. Pitääkö koneen jokainen prosessi kattaa, myös ne, joita et voi määrittää? Silloin tarvitset adapterin, joka omistaa rajapinnan ja lopettaa virrat. Voitko ottaa hoitaaksesi myös sen reitityksen, DNS:n ja silmukoiden eston poikkeukset? Jos et, tavallinen yhdyskäytävä maksaa vähemmän käyttää.

Yksi ero kannattaa pitää selvänä. VPN-asiakkaan oma socks-proxy-asetus kuvaa, miten ulompi tunneliyhteys saavuttaa palvelimeensa, eikä kerro mitään sisäisten asiakasvirtojen muuntamisesta. Nämä kaksi sekoitetaan jatkuvasti samassa tikissä. Päätä, mikä suhde tarvitset, ennen kuin kosket reittiin.