Redsocks lytter på loopback, men VPN-trafikken når aldrig frem

En tunnel kommer op, klienten kan pinge gatewayen, og hver webanmodning gennem proxy-stien dør. redsocks-processen kører, og dens port lytter, så tjenesten ser sund ud fra gatewayen selv. Det, der fejler, er leveringstrinnet: en pakke, der omdirigeres fra tunnelen, lander ikke på den socket, du startede. Bind-adressen og omdirigeringsmålet skal passe sammen, og normalt kontrolleres kun ét af dem.

Hvor en omdirigeret pakke faktisk lander

Transparent proxy på en gateway bruger REDIRECT i nat-tabellen under PREROUTING til at omskrive destinationen for en indgående forbindelse til en lokal port. Den omskrevne destination er en lokal adresse set fra det interface, pakken ankom på, ikke loopback-adressen for en proces, der startede et andet sted. En lytter, der kun er bundet til 127.0.0.1, accepterer forbindelser, der allerede var lokale på værten, og det er netop det tilfælde, der bliver ved med at virke, mens tunneltrafikken fejler. Klientens egen loopback er en tredje adresse og er aldrig målet for gatewayens regel.

Så før du rører upstream-legitimationsoplysningerne, fastslå to fakta: hvilken lokal adresse reglen omskriver til, og hvilken adresse proxy-socketen er bundet til.

Læs lytteren og omdirigeringsreglen sammen

Udskriv socket-tabellen og nat-reglerne i samme gennemløb, fordi en regel, der peger på en port, ingen ejer, ser identisk ud med en regel, der peger på den forkerte adresse. sudo ss -ltnp | grep redsocks viser bind-adressen og den ejende proces. sudo iptables -t nat -S PREROUTING viser REDIRECT-målet, og sudo iptables -t nat -L PREROUTING -v -n viser, om noget matchede det.

Et spring til en brugerskabt kæde ved navn REDSOCKS opnår intet, medmindre den kæde findes og bærer de tilsigtede undtagelser og REDIRECT-handlingen. Læs den kæde, den springer til, med sudo iptables -t nat -S REDSOCKS i stedet for at antage, at navnet gør arbejdet.

Sammenlign derefter de to værdier. Hvis reglen omdirigerer til en gateway-adresse på port 12345, og lytteren rapporterer 127.0.0.1:12345, forklarer uoverensstemmelsen fejlen uden yderligere diagnosticering.

Bind snævert, og begræns derefter, hvad der kan nå det

Eksempelkonfigurationen fra upstream sætter som standard lytteren på loopback af en god grund: en transparent proxy accepterer forbindelser på vegne af enhver, der kan nå den. At ændre bindingen til 0.0.0.0 retter leveringen og åbner samtidig porten på alle interfaces, hvilket er en sikkerhedsændring, ikke en neutral reparation. Foretræk at binde til den specifikke lokale adresse, som omdirigeringen peger på, og hold porten lukket på utroværdige interfaces. Hvis en bredere binding er uundgåelig, tilføj en værts-firewallregel, der kun tillader tunnelens kildeområde og gatewayens egen lokale trafik.

Det er aldrig nødvendigt at åbne porten på det offentlige interface for omdirigeret VPN-trafik, fordi forbindelsen afsluttes lokalt efter omskrivningen. Udsæt ikke proxyen for internettet for at få en lokal omdirigering til at virke.

Bevis det med en ny forbindelse fra en klient

Test fra en rigtig VPN-klient med en frisk TCP-forbindelse, ikke fra en shell på gatewayen. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com på klienten gennemprøver den omdirigerede sti fra ende til anden.

Bekræft derefter, at en direkte forbindelse til lytteren fra et utroværdigt netværk stadig afvises, og at proxyens egen upstream-forbindelse ikke fanges igen af den samme regel. Rekursiv indfangning viser sig som en proxy, der forbinder til sig selv og aldrig fuldfører en anmodning. Føj proxyens destination til undtagelsessættet, eller markér dens udgående pakker, så kæden springer dem over.

Husk til sidst, hvad denne sti ikke dækker. Almindelig redsocks TCP-omdirigering gør ikke UDP, QUIC eller DNS til SOCKS-trafik, og private destinationer kræver normalt eksplicitte undtagelser. En vellykket lokal test beviser kun loopback-stien, som aldrig var problemet.