Policy-ruting kontra SOCKS: kva lag som faktisk proxyar trafikken

Du la til ei policy-rute som sender trafikken frå ein VPN-klient til ein vert som køyrer ein SOCKS-lyttar på port 1080. Pakkane kjem fram, lyttaren loggar ingenting, og sambandet heng. Det er ingenting gale med ruta: eit neste hopp vel kvar ein pakke går, og SOCKS er ein samtale som klienten må starte. Samanlikn dei tre arkitektura som folk vanlegvis meiner når dei sender trafikk gjennom ein proxy, og det blir tydeleg kva del oppsettet ditt manglar.

Ruting, DNAT og SOCKS endrar ulike ting

Ei policy-rute skriv om ei avgjerd på lag 3. To linjer er nok til å sende trafikken frå éin klient til eit valt neste hopp:

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

Etterpå overleverer kjernen pakken til 10.50.0.2, medan den opphavlege destinasjonen framleis står i IP-hovudet. Viss 10.50.0.2 er ein ruter, sender han pakken vidare. Viss det er ein vert med ein SOCKS-demon på 1080, er pakken ikkje adressert til noko som kan ta imot han, og DNAT til port 1080 hjelper heller ikkje, fordi ein omsett pakke framleis ber den opphavlege applikasjonslasta i staden for ein SOCKS-helsing.

SOCKS5 byrjar med ein versjonsbyte, ei metodelliste, ein autentiseringsutveksling og ein førespurnad som namngjev destinasjonen. Det er applikasjonsdata. Korkje ei rutingoppføring eller eit netfilter-mål genererer det, og det er samanlikninga på éi linje: ruting vel ein veg, SOCKS ber tenaren lage eit andre samband.

Sak éin: applikasjonen kan sjølv snakke SOCKS

Når programmet har ei proxyinnstilling, er det den kortaste vegen, og han krev inga endring i kjernen. Peik han mot lyttaren, oppgi legitimasjon viss tenaren spør etter det, og avgjer om namn blir slått opp lokalt eller sende til proxyen. Med curl er det ulike flagg, og skilnaden tel når destinasjonen berre blir slått opp frå proxy-sida:

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

Applikasjonar som ignorerer proxy-miljøvariablar, eller som opnar rå sockets, kan ikkje hjelpast på denne måten. Nettlesarar og dei fleste HTTP-verktøy er greie; ein speleklient, ein postdemon eller ein vilkårleg leverandørbinær er det vanlegvis ikkje. Grensa er per applikasjon og per protokoll, og difor er dette alternativet framifrå for testing og svakt som svar for heile VPN-et.

Sak to: ein adapter som konverterer IP-straumar til proxy-økter

For program som ikkje kan snakke SOCKS, må konverteringa skje i noko som avsluttar IP-trafikk og opnar proxy-økter på deira vegner. Den komponenten eig eit tunellgrensesnitt, tek imot straumane som policy-ruting valde, utfører SOCKS-handtrykket for kvar av dei og byggjer opp svara igjen. Ruta peikar trafikken mot han; adapteren er det som lagar økta.

Les dokumentasjonen før du betror han eit heilt subnett. Mange adapterar ber TCP godt og handsamar UDP berre gjennom ein SOCKS5 UDP-assosiasjon, og ingen av dei gjer ICMP om til proxytrafikk, så ein vellukka ping seier ingenting om proxyvegen. DNS er den andre fella: viss adapteren slår opp namn lokalt, blir interne oppføringar slått opp til feil svar, eller til ingenting.

Løkkeførebygging er den operative detaljen som bit. Adapteren sine eigne samband til SOCKS-tenaren må ikkje rutast tilbake i adapteren, så trafikken hans treng eit unntak i regelen eller ei eiga kjeldeadresse. Går det gale, prøver proxy-økta å proxy seg sjølv.

Sak tre: verten er faktisk ein ruta gateway

Nokre gonger inneheld det fungerande oppsettet ingen SOCKS i det heile. Den eksterne verten sender pakkar vidare eller gjer NAT på dei, og den kjeldebaserte regelen vel han rett og slett som utgang. Det designet er legitimt, og det forklarar kvifor ein kopiert konfigurasjon virkar på eitt nettverk og feilar på eit anna: regelen er identisk, den manglande delen er ein vidaresendingsteneste på den andre sida.

Dei tre sakene skil seg raskt. Sjekk kva som faktisk lyttar, og sjå deretter på dei første byta som når verten:

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

Den første nyttelastbyten i ein ekte SOCKS-klient er 0x05, versjonen i helsinga. Viss opptaket viser opphavlege applikasjonsdata i staden, vil ingen SOCKS-demon svare, fordi forhandlinga aldri byrja. Viss ingenting lyttar på 1080, er verten ein gateway, og spørsmålet blir om han sender vidare og om det finst ein returveg.

Vel laget med fire spørsmål

Har programmet ei proxyinnstilling? Bruk ho og stopp der. Inneheld trafikken UDP eller ICMP som må overleve? Berre ein ruta gateway eller NAT-gateway ber ICMP, og UDP treng ein SOCKS5-assosiasjon som begge endar støttar. Må kvar prosess på maskinen dekkjast, også dei du ikkje kan konfigurere? Då treng du ein adapter som eig grensesnittet og avsluttar straumar. Kan du også ta over rutinga, DNS og unntaka for løkkeførebygging? Viss ikkje, kostar den vanlege gatewayen mindre å drive.

Éin skilnad er verdt å halde rett. Ei VPN-klient si eiga socks-proxy-innstilling skildrar korleis den ytre tunellsambandet når tenaren sin, og seier ingenting om å konvertere dei indre klientstraumane. Dei to blir stadig blanda saman i same sak. Bestem kva forhold du treng før du rører ei rute.