Redsocks lyssnar på loopback men VPN-trafiken kommer aldrig fram

En tunnel kommer upp, klienten kan pinga gatewayen, och varje webbförfrågan genom proxyvägen dör. redsocks-processen kör och dess port lyssnar, så tjänsten ser frisk ut från gatewayen själv. Det som misslyckas är leveranssteget: ett paket som omdirigeras från tunneln landar inte på den socket du startade. Bindadressen och omdirigeringsmålet måste stämma överens, och vanligtvis kontrolleras bara en av dem.

Var ett omdirigerat paket faktiskt landar

Transparent proxy på en gateway använder REDIRECT i nat-tabellen vid PREROUTING för att skriva om destinationen för en inkommande anslutning till en lokal port. Den omskrivna destinationen är en lokal adress sedd från det gränssnitt paketet kom in på, inte loopback-adressen för en process som startades någon annanstans. En lyssnare som bara är bunden till 127.0.0.1 accepterar anslutningar som redan var lokala på värden, och det är just det fallet som fortsätter att fungera medan tunneltrafiken misslyckas. Klientens egen loopback är en tredje adress och är aldrig målet för gatewayens regel.

Så innan du rör uppströms inloggningsuppgifter, fastställ två fakta: vilken lokal adress regeln skriver om till, och vilken adress proxy-socketen är bunden till.

Läs lyssnaren och omdirigeringsregeln tillsammans

Skriv ut socket-tabellen och nat-reglerna i samma genomgång, eftersom en regel som pekar på en port som ingen äger ser identisk ut med en regel som pekar på fel adress. sudo ss -ltnp | grep redsocks visar bindadressen och den ägande processen. sudo iptables -t nat -S PREROUTING visar REDIRECT-målet, och sudo iptables -t nat -L PREROUTING -v -n visar om något matchade det.

Ett hopp till en användarkedja som heter REDSOCKS åstadkommer ingenting om inte den kedjan finns och bär de avsedda undantagen och REDIRECT-åtgärden. Läs kedjan den hoppar till med sudo iptables -t nat -S REDSOCKS i stället för att anta att namnet gör jobbet.

Jämför sedan de två värdena. Om regeln omdirigerar till en gateway-adress på port 12345 och lyssnaren rapporterar 127.0.0.1:12345, förklarar avvikelsen felet utan någon ytterligare diagnostik.

Bind smalt och begränsa sedan vad som kan nå det

Exempelkonfigurationen uppströms sätter lyssnaren på loopback av goda skäl: en transparent proxy accepterar anslutningar för alla som kan nå den. Att ändra bindningen till 0.0.0.0 rättar leveransen och öppnar samtidigt porten på varje gränssnitt, vilket är en säkerhetsändring, inte en neutral reparation. Föredra att binda till den specifika lokala adress som omdirigeringen riktar sig mot, och håll porten stängd på icke betrodda gränssnitt. Om en bredare bindning är oundviklig, lägg till en brandväggsregel på värden som bara tillåter tunnelns källområde och gatewayens egen lokala trafik.

Att öppna porten på det offentliga gränssnittet är aldrig nödvändigt för omdirigerad VPN-trafik, eftersom anslutningen avslutas lokalt efter omskrivningen. Exponera inte proxyn mot internet för att få en lokal omdirigering att fungera.

Bevisa det med en ny anslutning från en klient

Testa från en riktig VPN-klient med en färsk TCP-anslutning, inte från ett skal på gatewayen. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com på klienten genomför den omdirigerade vägen från början till slut.

Bekräfta sedan att en direkt anslutning till lyssnaren från ett icke betrott nätverk fortfarande avvisas, och att proxyens egen uppströmsanslutning inte fångas igen av samma regel. Rekursiv fångst visar sig som en proxy som ansluter till sig själv och aldrig slutför en förfrågan. Lägg till proxyens destination i undantagsmängden, eller markera dess utgående paket så att kedjan hoppar över dem.

Slutligen, kom ihåg vad den här vägen inte täcker. Vanlig redsocks TCP-omdirigering gör inte UDP, QUIC eller DNS till SOCKS-trafik, och privata destinationer kräver vanligtvis uttryckliga undantag. Ett lyckat lokalt test bevisar bara loopback-vägen som aldrig var problemet.