Redsocks lytter på loopback, men VPN-trafikken kommer aldri frem

En tunnel kommer opp, klienten kan pinge gatewayen, og hver nettforespørsel gjennom proxy-stien dør. redsocks-prosessen kjører og porten lytter, så tjenesten ser sunn ut fra gatewayen selv. Det som feiler, er leveringstrinnet: en pakke som omdirigeres fra tunnelen, lander ikke på socketen du startet. Bind-adressen og omdirigeringsmålet må stemme overens, og vanligvis kontrolleres bare én av dem.

Hvor en omdirigert pakke faktisk lander

Transparent proxy på en gateway bruker REDIRECT i nat-tabellen under PREROUTING for å skrive om destinasjonen til en innkommende forbindelse til en lokal port. Den omskrevne destinasjonen er en lokal adresse slik den ses fra grensesnittet pakken kom inn på, ikke loopback-adressen til en prosess som startet et annet sted. En lytter som bare er bundet til 127.0.0.1, godtar forbindelser som allerede var lokale på verten, og det er nettopp tilfellet som fortsetter å virke mens tunneltrafikken feiler. Klientens egen loopback er en tredje adresse og er aldri målet for gatewayens regel.

Så før du rører oppstrøms påloggingsinformasjon, fastslå to fakta: hvilken lokal adresse regelen skriver om til, og hvilken adresse proxy-socketen er bundet til.

Les lytteren og omdirigeringsregelen sammen

Skriv ut socket-tabellen og nat-reglene i samme gjennomkjøring, fordi en regel som peker på en port ingen eier, ser identisk ut med en regel som peker på feil adresse. sudo ss -ltnp | grep redsocks viser bind-adressen og den eide prosessen. sudo iptables -t nat -S PREROUTING viser REDIRECT-målet, og sudo iptables -t nat -L PREROUTING -v -n viser om noe samsvarte med det.

Et hopp til en brukerkjede kalt REDSOCKS oppnår ingenting med mindre den kjeden finnes og bærer de tiltenkte unntakene og REDIRECT-handlingen. Les kjeden den hopper til med sudo iptables -t nat -S REDSOCKS i stedet for å anta at navnet gjør arbeidet.

Sammenlign deretter de to verdiene. Hvis regelen omdirigerer til en gateway-adresse på port 12345 og lytteren rapporterer 127.0.0.1:12345, forklarer avviket feilen uten ytterligere diagnostikk.

Bind smalt, og begrens deretter hva som kan nå det

Eksempelkonfigurasjonen oppstrøms setter lytteren på loopback av en god grunn: en transparent proxy godtar forbindelser på vegne av alle som kan nå den. Å endre bindingen til 0.0.0.0 retter leveringen og åpner samtidig porten på alle grensesnitt, noe som er en sikkerhetsendring, ikke en nøytral reparasjon. Foretrekk å binde til den spesifikke lokale adressen omdirigeringen sikter mot, og hold porten lukket på ikke-klarerte grensesnitt. Hvis en bredere binding er uunngåelig, legg til en vertsbrannmurregel som bare tillater tunnelens kildeområde og gatewayens egen lokale trafikk.

Å åpne porten på det offentlige grensesnittet er aldri nødvendig for omdirigert VPN-trafikk, fordi forbindelsen avsluttes lokalt etter omskrivingen. Ikke eksponer proxyen for internett for å få en lokal omdirigering til å virke.

Bevis det med en ny forbindelse fra en klient

Test fra en ekte VPN-klient med en fersk TCP-forbindelse, ikke fra et skall på gatewayen. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com på klienten prøver den omdirigerte stien fra ende til annen.

Bekreft deretter at en direkte forbindelse til lytteren fra et ikke-klarert nettverk fortsatt avvises, og at proxyens egen oppstrømsforbindelse ikke fanges igjen av den samme regelen. Rekursiv fangst viser seg som en proxy som kobler til seg selv og aldri fullfører en forespørsel. Legg proxyens destinasjon til unntakssettet, eller merk de utgående pakkene dens slik at kjeden hopper over dem.

Til slutt, husk hva denne stien ikke dekker. Vanlig redsocks TCP-omdirigering gjør ikke UDP, QUIC eller DNS til SOCKS-trafikk, og private destinasjoner trenger vanligvis eksplisitte unntak. En vellykket lokal test beviser bare loopback-stien som aldri var problemet.