Policy routing kontra SOCKS: hvilket lag proxyer faktisk trafikken

Du tilføjede en policy-rute, der sender en VPN-klients trafik til en vært, som kører en SOCKS-lytter på port 1080. Pakkerne ankommer, lytteren logger intet, og forbindelsen hænger. Der er intet galt med ruten: et næste hop vælger, hvor en pakke skal hen, og SOCKS er en samtale, som en klient skal starte. Sammenlign de tre arkitekturer, folk normalt mener med at sende trafik gennem en proxy, og det bliver tydeligt, hvilken del din opsætning mangler.

Routing, DNAT og SOCKS ændrer forskellige ting

En policy-rute omskriver en beslutning på lag 3. To linjer er nok til at sende én klients trafik til et valgt næste hop:

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

Derefter giver kernen pakken til 10.50.0.2, mens den oprindelige destination stadig står i IP-headeren. Hvis 10.50.0.2 er en router, videresender den pakken. Hvis det er en vært med en SOCKS-dæmon på 1080, er pakken ikke adresseret til noget, der kan acceptere den, og DNAT til port 1080 hjælper heller ikke, fordi en oversat pakke stadig bærer den oprindelige applikationsnyttelast i stedet for en SOCKS-hilsen.

SOCKS5 begynder med en versionsbyte, en metodeliste, en autentificeringsudveksling og en anmodning, der navngiver destinationen. Det er applikationsdata. Hverken en routingpost eller et netfilter-mål genererer det, og det er sammenligningen på én linje: routing vælger en vej, SOCKS beder en server om at lave en anden forbindelse.

Sag et: applikationen kan selv tale SOCKS

Når programmet har en proxyindstilling, er det den korteste vej, og den kræver ingen ændring i kernen. Peg den på lytteren, angiv legitimationsoplysninger, hvis serveren spørger efter dem, og beslut, om navne slås op lokalt eller sendes videre til proxyen. Med curl er det forskellige flag, og forskellen betyder noget, når destinationen kun slås op 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

Applikationer, der ignorerer proxy-miljøvariabler, eller som åbner rå sockets, kan ikke hjælpes på denne måde. Browsere og de fleste HTTP-værktøjer er fine; en spilklient, en maildæmon eller en vilkårlig leverandørbinær er det normalt ikke. Grænsen er per applikation og per protokol, og derfor er denne mulighed fremragende til test og svag som svar for hele VPN'et.

Sag to: en adapter, der konverterer IP-strømme til proxy-sessioner

For programmer, der ikke kan tale SOCKS, skal konverteringen ske i noget, der afslutter IP-trafik og åbner proxy-sessioner på deres vegne. Den komponent ejer en tunnelgrænseflade, accepterer de strømme, policy-routing valgte, udfører SOCKS-håndtrykket for hver af dem og genopbygger svarene. Ruten peger trafikken mod den; adapteren er det, der skaber sessionen.

Læs dens dokumentation, før du betror den et helt subnet. Mange adaptere bærer TCP godt og håndterer UDP kun gennem en SOCKS5 UDP-association, og ingen af dem laver ICMP om til proxytrafik, så en vellykket ping siger intet om proxyvejen. DNS er den anden fælde: hvis adapteren slår navne op lokalt, slås interne poster op til det forkerte svar eller slet intet.

Loopforebyggelse er den operationelle detalje, der bider. Adapterens egne forbindelser til SOCKS-serveren må ikke routes tilbage i adapteren, så dens trafik kræver en undtagelse i reglen eller en dedikeret kildeadresse. Går det galt, forsøger proxy-sessionen at proxy sig selv.

Sag tre: værten er faktisk en routet gateway

Nogle gange indeholder den fungerende opsætning slet ingen SOCKS. Den eksterne vært videresender pakker eller NAT'er dem, og den kildebaserede regel vælger den blot som udgang. Det design er legitimt, og det forklarer, hvorfor en kopieret konfiguration virker på ét netværk og fejler på et andet: reglen er identisk, det manglende stykke er en videresendelsestjeneste på den anden side.

De tre tilfælde skilles hurtigt. Kontroller, hvad der faktisk lytter, og se derefter på de første bytes, der når værten:

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

Den første nyttelastbyte i en rigtig SOCKS-klient er 0x05, versionen i hilsenen. Hvis optagelsen viser oprindelige applikationsdata i stedet, svarer ingen SOCKS-dæmon, fordi forhandlingen aldrig begyndte. Hvis intet lytter på 1080, er værten en gateway, og spørgsmålet bliver, om den videresender, og om der findes en returvej.

Vælg laget med fire spørgsmål

Har programmet en proxyindstilling? Brug den og stop der. Indeholder trafikken UDP eller ICMP, der skal overleve? Kun en routet gateway eller NAT-gateway bærer ICMP, og UDP kræver en SOCKS5-association, som begge ender understøtter. Skal hver proces på maskinen dækkes, også dem du ikke kan konfigurere? Så har du brug for en adapter, der ejer grænsefladen og afslutter strømme. Kan du også overtage dens routing, DNS og undtagelser til loopforebyggelse? Hvis ikke, koster den almindelige gateway mindre at drive.

Én sondring er værd at holde styr på. En VPN-klients egen socks-proxy-indstilling beskriver, hvordan den ydre tunnelforbindelse når sin server, og siger intet om at konvertere de indre klientstrømme. De to blandes konstant sammen i den samme sag. Beslut, hvilket forhold du har brug for, før du rører en rute.