Beleidsroetering teenoor SOCKS: watter laag proxieer die verkeer werklik

Jy het ’n beleidsroete bygevoeg wat die verkeer van ’n VPN-kliënt na ’n gasheer stuur waarop ’n SOCKS-luisteraar op poort 1080 loop. Die pakkette kom aan, die luisteraar teken niks aan, en die verbinding hang. Niks is verkeerd met die roete nie: ’n volgende sprong kies waarheen ’n pakket gaan, en SOCKS is ’n gesprek wat ’n kliënt self moet begin. Vergelyk die drie argitekture wat mense gewoonlik bedoel wanneer hulle verkeer deur ’n proxy stuur, en dit word duidelik watter stuk jou opstelling mis.

Roetering, DNAT en SOCKS verander verskillende dinge

’n Beleidsroete herskryf ’n laag-3-beslissing. Twee reëls is genoeg om die verkeer van een kliënt na ’n gekose volgende sprong te stuur:

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

Daarna gee die kernel die pakket aan 10.50.0.2 oor, met die oorspronklike bestemming nog in die IP-kop. As 10.50.0.2 ’n roeteerder is, stuur dit die pakket verder. As dit ’n gasheer met ’n SOCKS-daemon op 1080 is, is die pakket nie aan iets geadresseer wat dit kan aanvaar nie, en DNAT na poort 1080 help ook nie, want ’n omgeskakelde pakket dra steeds die oorspronklike toepassingsvrag in plaas van ’n SOCKS-groet.

SOCKS5 begin met ’n weergawebyte, ’n lys metodes, ’n verifikasie-uitruiling en ’n versoek wat die bestemming benoem. Dit is toepassingsdata. Geen roeteringsinskrywing en geen netfilter-teiken genereer dit nie, en dit is die vergelyking in een reël: roetering kies ’n pad, SOCKS vra ’n bediener om ’n tweede verbinding te maak.

Geval een: die toepassing kan self SOCKS praat

Wanneer die program ’n proxy-instelling het, is dit die kortste pad en dit verg geen kernelverandering nie. Wys dit na die luisteraar, gee geloofsbriewe as die bediener daarom vra, en besluit of name plaaslik opgelos word of aan die proxy oorgedra word. By curl is dit verskillende vlae, en die verskil maak saak wanneer die bestemming net van die proxy se kant af oplos:

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

Toepassings wat proxy-omgewingsveranderlikes ignoreer, of wat rou sockette oopmaak, kan nie so gehelp word nie. Blaaiers en die meeste HTTP-gereedskap is goed; ’n speletjiekliënt, ’n posdaemon of ’n willekeurige verskaffer-binêre lêer is gewoonlik nie. Die grens is per toepassing en per protokol, en daarom is hierdie opsie uitstekend vir toetsing en swak as ’n antwoord vir die hele VPN.

Geval twee: ’n aanpasser wat IP-strome in proxy-sessies omskakel

Vir programme wat nie SOCKS kan praat nie, moet die omskakeling gebeur in iets wat IP-verkeer beëindig en namens hulle proxy-sessies oopmaak. Daardie komponent besit ’n tonnelkoppelvlak, aanvaar die strome wat beleidsroetering gekies het, voer die SOCKS-handdruk vir elkeen uit en bou die antwoorde weer op. Die roete wys verkeer daarheen; die aanpasser is wat die sessie skep.

Lees die dokumentasie voordat jy dit met ’n hele subnet vertrou. Baie aanpassers dra TCP goed en hanteer UDP net deur ’n SOCKS5 UDP-assosiasie, en nie een van hulle skakel ICMP na proxy-verkeer om nie, so ’n suksesvolle ping sê niks oor die proxy-pad nie. DNS is die ander lokval: as die aanpasser name plaaslik oplos, los slegs-interne rekords op die verkeerde antwoord op, of glad niks.

Lusvoorkoming is die operasionele detail wat byt. Die aanpasser se eie verbindings na die SOCKS-bediener moet nie weer in die aanpasser ingeroeteer word nie, so sy verkeer het ’n uitsondering in die reël of ’n toegewyde bronadres nodig. Kry dit verkeerd en die proxy-sessie probeer homself proxieer.

Geval drie: die gasheer is eintlik ’n geroteerde deurgang

Soms bevat die werkende opstelling glad geen SOCKS nie. Die afgeleë gasheer stuur pakkette verder of NAT dit, en die brongebaseerde reël kies dit bloot as die uitgang. Daardie ontwerp is wettig, en dit verduidelik waarom ’n gekopieerde konfigurasie op een netwerk werk en op ’n ander faal: die reël is identies, die ontbrekende stuk is ’n diens wat pakkette aanstuur aan die ander kant.

Die drie gevalle skei vinnig. Kyk wat werklik luister, en kyk dan na die eerste grepe wat die gasheer bereik:

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

Die eerste vragbyte van ’n regte SOCKS-kliënt is 0x05, die weergawe in die groet. As die opname eerder oorspronklike toepassingsdata wys, sal geen SOCKS-daemon antwoord nie, want die onderhandeling het nooit begin nie. As niks op 1080 luister nie, is die gasheer ’n deurgang, en die vraag word of dit aanstuur en of daar ’n terugpad bestaan.

Kies die laag met vier vrae

Het die program ’n proxy-instelling? Gebruik dit en stop daar. Is daar UDP of ICMP in die verkeer wat moet oorleef? Net ’n geroteerde of NAT-deurgang dra ICMP, en UDP benodig ’n SOCKS5-assosiasie wat albei kante ondersteun. Moet elke proses op die masjien gedek word, ook dié wat jy nie kan opstel nie? Dan het jy ’n aanpasser nodig wat die koppelvlak besit en strome beëindig. Kan jy ook die roetering, DNS en lusvoorkomings-uitsonderings daarvan oorneem? Indien nie, sal die gewone deurgang goedkoper wees om te bedryf.

Een onderskeid is die moeite werd om reg te hou. ’n VPN-kliënt se eie socks-proxy-opsie beskryf hoe die buitenste tonnelverbinding sy bediener bereik, en sê niks oor die omskakeling van die binneste kliëntstrome nie. Die twee word voortdurend in dieselfde kaartjie verwar. Besluit watter verhouding jy nodig het voordat jy aan ’n roete raak.