Policy-routing kontra SOCKS: vilket lager proxar faktiskt trafiken

Du lade till en policy-rutt som skickar trafiken från en VPN-klient till en värd som kör en SOCKS-lyssnare på port 1080. Paketen anländer, lyssnaren loggar ingenting och anslutningen hänger. Det är inget fel på rutten: nästa hopp väljer vart ett paket tar vägen, och SOCKS är ett samtal som en klient måste starta. Jämför de tre arkitekturer som folk vanligen menar när de skickar trafik genom en proxy, och det blir tydligt vilken del din uppsättning saknar.

Routing, DNAT och SOCKS ändrar olika saker

En policy-rutt skriver om ett beslut på lager 3. Två rader räcker för att skicka en klients trafik till ett valt nästa hopp:

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

Därefter lämnar kärnan paketet till 10.50.0.2, medan den ursprungliga destinationen fortfarande står i IP-huvudet. Om 10.50.0.2 är en router vidarebefordrar den paketet. Om det är en värd med en SOCKS-demon på 1080 är paketet inte adresserat till något som kan ta emot det, och DNAT till port 1080 hjälper inte heller, eftersom ett översatt paket fortfarande bär den ursprungliga applikationsnyttolasten i stället för en SOCKS-hälsning.

SOCKS5 börjar med en versionsbyte, en metodlista, ett autentiseringsutbyte och en begäran som namnger destinationen. Det är applikationsdata. Varken en routingpost eller ett netfilter-mål genererar det, och det är jämförelsen på en rad: routing väljer en väg, SOCKS ber en server att göra en andra anslutning.

Fall ett: applikationen kan själv tala SOCKS

När programmet har en proxyinställning är det den kortaste vägen och den kräver ingen ändring i kärnan. Peka den mot lyssnaren, ange uppgifter om servern frågar efter dem, och avgör om namn slås upp lokalt eller skickas vidare till proxyn. Med curl är det olika flaggor, och skillnaden spelar roll när destinationen bara slås upp från proxyns sida:

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

Applikationer som ignorerar proxy-miljövariabler, eller som öppnar råa sockets, kan inte hjälpas på detta sätt. Webbläsare och de flesta HTTP-verktyg är okej; en spelklient, en maildemon eller en godtycklig leverantörsbinär är det vanligen inte. Gränsen går per applikation och per protokoll, och därför är det här alternativet utmärkt för testning och svagt som svar för hela VPN:et.

Fall två: en adapter som konverterar IP-strömmar till proxy-sessioner

För program som inte kan tala SOCKS måste konverteringen ske i något som avslutar IP-trafik och öppnar proxy-sessioner i deras ställe. Den komponenten äger ett tunnelgränssnitt, tar emot de strömmar som policy-routing valde, utför SOCKS-handskakningen för var och en och bygger upp svaren igen. Rutten pekar trafiken mot den; adaptern är det som skapar sessionen.

Läs dess dokumentation innan du anförtror den ett helt subnät. Många adaptrar bär TCP bra och hanterar UDP bara genom en SOCKS5 UDP-association, och ingen av dem gör ICMP till proxytrafik, så en lyckad ping säger inget om proxyvägen. DNS är den andra fällan: om adaptern slår upp namn lokalt slås interna poster upp till fel svar, eller till ingenting.

Slingförebyggande är den operativa detalj som biter. Adapterns egna anslutningar till SOCKS-servern får inte routas tillbaka in i adaptern, så dess trafik behöver ett undantag i regeln eller en egen källadress. Gör man fel försöker proxy-sessionen proxa sig själv.

Fall tre: värden är faktiskt en routad gateway

Ibland innehåller den fungerande uppsättningen ingen SOCKS alls. Den fjärranslutna värden vidarebefordrar paket eller gör NAT på dem, och den källbaserade regeln väljer den helt enkelt som utgång. Den designen är legitim, och den förklarar varför en kopierad konfiguration fungerar på ett nätverk och misslyckas på ett annat: regeln är identisk, den saknade delen är en vidarebefordringstjänst på andra sidan.

De tre fallen skiljs snabbt. Kontrollera vad som faktiskt lyssnar, och titta sedan på de första byten som når värden:

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

Den första nyttolastbyten i en riktig SOCKS-klient är 0x05, versionen i hälsningen. Om inspelningen visar ursprungliga applikationsdata i stället kommer ingen SOCKS-demon att svara, eftersom förhandlingen aldrig började. Om ingenting lyssnar på 1080 är värden en gateway, och frågan blir om den vidarebefordrar och om det finns en returväg.

Välj lagret med fyra frågor

Har programmet en proxyinställning? Använd den och stanna där. Innehåller trafiken UDP eller ICMP som måste överleva? Bara en routad gateway eller NAT-gateway bär ICMP, och UDP behöver en SOCKS5-association som båda ändar stöder. Måste varje process på maskinen täckas, även de du inte kan konfigurera? Då behöver du en adapter som äger gränssnittet och avslutar strömmar. Kan du också ta över dess routing, DNS och undantag för slingförebyggande? Om inte kostar den vanliga gatewayen mindre att driva.

En skillnad är värd att hålla rak. En VPN-klients egen socks-proxy-inställning beskriver hur den yttre tunnelanslutningen når sin server, och säger ingenting om att konvertera de inre klientströmmarna. De två blandas ständigt ihop i samma ärende. Bestäm vilken relation du behöver innan du rör en rutt.