Beliedsrûtearing tsjin SOCKS: hokker laach proxyt it ferkear echt

Jo hawwe in beliedsrûte tafoege dy't it ferkear fan in VPN-klant nei in host stjoert dêr't in SOCKS-harker op poarte 1080 draait. De pakketten komme oan, de harker logt neat, en de ferbining hinget. Der is neat mis mei de rûte: in folgjende hop kiest wêr't in pakket hinne giet, en SOCKS is in petear dat in klant sels begjinne moat. Fergelykje de trije arsjitektueren dy't minsken meast bedoele as se ferkear troch in proxy stjoere, en it wurdt dúdlik hokker part jo ynstelling mist.

Rûtearing, DNAT en SOCKS feroarje ferskille ord saken

In beliedsrûte skriuwt in beslissing op laach 3 oer. Twa rigels binne genôch om it ferkear fan ien klant nei in keazen folgjende hop te stjoeren:

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

Dêrnei jout de kernel it pakket oan 10.50.0.2, wylst de oarspronklike bestimming noch yn 'e IP-kop stiet. As 10.50.0.2 in router is, stjoert dy it pakket troch. As it in host is mei in SOCKS-daemon op 1080, is it pakket net adressearre oan eat dat it oannimme kin, en DNAT nei poarte 1080 helpt ek net, om't in oerset pakket noch altiten de oarspronklike applikaasjelading draacht ynstee fan in SOCKS-groetnis.

SOCKS5 begjint mei in ferzje-byte, in list mei metoaden, in autentikaasje-útwikseling en in fersyk dat de bestimming neamt. Dat binne applikaasjegegevens. Gjin rûtearing-yngong en gjin netfilter-doel generearret it, en dat is de fergeliking yn ien rigel: rûtearing kiest in paad, SOCKS freget in server om in twadde ferbining te meitsjen.

Gefal ien: de applikaasje kin sels SOCKS sprekke

As it programma in proxy-ynstelling hat, is dat it koartste paad en it fereasket gjin kernelwiziging. Wys it nei de harker, jou bewiisstikken as de server dêr om freget, en beslút oft nammen lokaal oplost wurde of oan de proxy trochjûn wurde. By curl binne dat ferskate flaggen, en it ferskil is wichtich as de bestimming allinnich fan 'e proxy-kant ôf oplost:

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

Applikaasjes dy't proxy-omjouwingsfariabelen negearje, of dy't rûge sockets iepenje, kinne sa net holpen wurde. Browsers en de measte HTTP-ark binne goed; in spielklant, in maildaemon of in willekeurige leveransierbinêr is dat meastal net. De grins is per applikaasje en per protokol, dêrom is dizze opsje poerbêst foar testen en swak as antwurd foar de hiele VPN.

Gefal twa: in adapter dy't IP-streamen yn proxy-sesjes omsettet

Foar programma's dy't gjin SOCKS sprekke kinne, moat de omsetting barre yn eat dat IP-ferkear beëiniget en proxy-sesjes foar har iepenet. Dat ûnderdiel besit in tunnel-yngongsflak, akseptearret de streamen dy't beliedsrûtearing keas, docht de SOCKS-hânskutting foar elk en bout de antwurden wer op. De rûte rjochtet ferkear dêrhinne; de adapter is wat de sesje makket.

Lês de dokumintaasje foardat jo der in hiel subnet oan tabetrouwe. In soad adapters drage TCP goed en behannelje UDP allinnich fia in SOCKS5 UDP-assosjaasje, en gjinien fan har makket ICMP ta proxy-ferkear, dus in slagge ping seit neat oer it proxy-paad. DNS is de oare fal: as de adapter nammen lokaal oplost, wurde allinnich-ynterne records oplost ta it ferkearde antwurd, of ta hielendal neat.

Lusprevinsje is it operasjonele detail dat byt. De eigen ferbiningen fan 'e adapter nei de SOCKS-server meie net werom yn 'e adapter rûte wurde, dus it ferkear hat in útsûndering yn 'e regel of in eigen boarne-adres nedich. Doch dat ferkeard en de proxy-sesje besiket himsels te proxien.

Gefal trije: de host is eins in rûtearele gateway

Soms befettet de wurkjende ynstelling hielendal gjin SOCKS. De fiere host stjoert pakketten troch of docht NAT, en de boarne-basearre regel kiest him gewoan as útgong. Dat ûntwerp is legitiem, en it ferklearret wêrom't in kopiearre konfiguraasje op it iene netwurk wurket en op it oare net: de regel is identyk, it ûntbrekkende part is in trochstjoertsjinst oan 'e oare kant.

De trije gefallen skiede har fluch. Kontrolearje wat eins harket, en sjoch dan nei de earste bytes dy't de host berikke:

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

De earste ladingbyte fan in echte SOCKS-klant is 0x05, de ferzje yn 'e groetnis. As de opname ynstee dêrfan oarspronklike applikaasjegegevens sjen lit, sil gjin SOCKS-daemon antwurdzje, om't de ûnderhanneling nea begûn is. As der neat op 1080 harket, is de host in gateway, en wurdt de fraach oft er trochstjoert en oft der in werompaad bestiet.

Kies de laach mei fjouwer fragen

Hat it programma in proxy-ynstelling? Brûk dy en stop dêr. Befettet it ferkear UDP of ICMP dat oerlibje moat? Allinnich in rûtearele of NAT-gateway draacht ICMP, en UDP hat in SOCKS5-assosjaasje nedich dy't beide kanten stypje. Moat elk proses op 'e masine dutsen wurde, ek dy't jo net ynstelle kinne? Dan hawwe jo in adapter nedich dy't it yngongsflak besit en streamen beëiniget. Kinne jo ek syn rûtearing, DNS en lusprevinsje-útsûnderingen oernimme? Sa net, dan kostet de gewoane gateway minder om te betsjinjen.

Ien ûnderskie is it wurdich rjocht te hâlden. De eigen socks-proxy-opsje fan in VPN-klant beskriuwt hoe't de bûtentunnelferbining syn server berikt, en seit neat oer it omsetten fan 'e binnenste klantstreamen. De beide wurde hieltyd yn itselde ticket trochinoar helle. Beslút hokker relaasje jo nedich hawwe foardat jo in rûte oanreitsje.