Policy-ruting kontra SOCKS: hvilket lag proxyer faktisk trafikken

Du la til en policy-rute som sender trafikken til en VPN-klient til en vert som kjører en SOCKS-lytter på port 1080. Pakkene ankommer, lytteren logger ingenting, og tilkoblingen henger. Det er ingenting galt med ruten: et neste hopp velger hvor en pakke går, og SOCKS er en samtale som en klient må starte. Sammenlign de tre arkitekturene folk vanligvis mener når de sender trafikk gjennom en proxy, og det blir tydelig hvilken del oppsettet ditt mangler.

Ruting, DNAT og SOCKS endrer forskjellige ting

En policy-rute skriver om en beslutning på lag 3. To linjer er nok til å sende trafikken til én klient til et valgt 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, mens den opprinnelige destinasjonen fortsatt står i IP-headeren. Hvis 10.50.0.2 er en ruter, videresender den pakken. Hvis det er en vert med en SOCKS-demon på 1080, er pakken ikke adressert til noe som kan ta imot den, og DNAT til port 1080 hjelper heller ikke, fordi en oversatt pakke fortsatt bærer den opprinnelige applikasjonsnyttelasten i stedet for en SOCKS-hilsen.

SOCKS5 begynner med en versjonsbyte, en metodeliste, en autentiseringsutveksling og en forespørsel som navngir destinasjonen. Det er applikasjonsdata. Verken en rutingoppføring eller et netfilter-mål genererer det, og det er sammenligningen på én linje: ruting velger en vei, SOCKS ber en server lage en andre tilkobling.

Sak én: applikasjonen kan snakke SOCKS selv

Når programmet har en proxyinnstilling, er det den korteste veien, og den krever ingen endring i kjernen. Pek den mot lytteren, oppgi legitimasjon hvis serveren spør etter det, og avgjør om navn slås opp lokalt eller sendes til proxyen. Med curl er det forskjellige flagg, og forskjellen betyr noe når destinasjonen bare slås opp fra proxyens side:

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

Applikasjoner som ignorerer proxy-miljøvariabler, eller som åpner rå sockets, kan ikke hjelpes på denne måten. Nettlesere og de fleste HTTP-verktøy er fine; en spillklient, en postdemon eller en vilkårlig leverandørbinær er det vanligvis ikke. Grensen er per applikasjon og per protokoll, og derfor er dette alternativet utmerket for testing og svakt som svar for hele VPN-et.

Sak to: en adapter som konverterer IP-strømmer til proxy-økter

For programmer som ikke kan snakke SOCKS, må konverteringen skje i noe som avslutter IP-trafikk og åpner proxy-økter på deres vegne. Den komponenten eier et tunellgrensesnitt, godtar strømmene policy-ruting valgte, utfører SOCKS-håndtrykket for hver av dem og bygger opp svarene igjen. Ruten peker trafikken mot den; adapteren er det som lager økten.

Les dokumentasjonen før du betror den et helt subnett. Mange adaptere bærer TCP godt og håndterer UDP bare gjennom en SOCKS5 UDP-assosiasjon, og ingen av dem gjør ICMP om til proxytrafikk, så en vellykket ping sier ingenting om proxyveien. DNS er den andre fellen: hvis adapteren slår opp navn lokalt, slås interne oppføringer opp til feil svar, eller til ingenting.

Løkkeforbygging er den operative detaljen som biter. Adapterens egne tilkoblinger til SOCKS-serveren må ikke rutes tilbake i adapteren, så trafikken dens trenger et unntak i regelen eller en egen kildeadresse. Går det galt, prøver proxy-økten å proxy seg selv.

Sak tre: verten er faktisk en rutet gateway

Noen ganger inneholder det fungerende oppsettet ingen SOCKS i det hele tatt. Den eksterne verten videresender pakker eller gjør NAT på dem, og den kildebaserte regelen velger den rett og slett som utgang. Det designet er legitimt, og det forklarer hvorfor en kopiert konfigurasjon virker på ett nettverk og feiler på et annet: regelen er identisk, den manglende delen er en videresendingstjeneste på den andre siden.

De tre sakene skilles raskt. Sjekk hva som faktisk lytter, og se deretter på de første bytene som når verten:

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

Den første nyttelastbyten i en ekte SOCKS-klient er 0x05, versjonen i hilsenen. Hvis opptaket viser opprinnelige applikasjonsdata i stedet, vil ingen SOCKS-demon svare, fordi forhandlingen aldri begynte. Hvis ingenting lytter på 1080, er verten en gateway, og spørsmålet blir om den videresender og om det finnes en returvei.

Velg laget med fire spørsmål

Har programmet en proxyinnstilling? Bruk den og stopp der. Inneholder trafikken UDP eller ICMP som må overleve? Bare en rutet gateway eller NAT-gateway bærer ICMP, og UDP trenger en SOCKS5-assosiasjon som begge ender støtter. Må hver prosess på maskinen dekkes, også de du ikke kan konfigurere? Da trenger du en adapter som eier grensesnittet og avslutter strømmer. Kan du også ta over rutingen, DNS og unntakene for løkkeforbygging? Hvis ikke, koster den vanlige gatewayen mindre å drive.

Én forskjell er verdt å holde rett. En VPN-klients egen socks-proxy-innstilling beskriver hvordan den ytre tunelltilkoblingen når serveren sin, og sier ingenting om å konvertere de indre klientstrømmene. De to blandes stadig sammen i samme sak. Bestem hvilket forhold du trenger før du rører en rute.