Redsocks lyttar på loopback, men VPN-trafikken kjem aldri fram

Ein tunnel kjem opp, klienten kan pinga gatewayen, og kvar nettførespurnad gjennom proxy-stien døyr. redsocks-prosessen køyrer og porten lyttar, så tenesta ser sunn ut frå gatewayen sjølv. Det som feilar, er leveringstrinnet: ein pakke som blir omdirigert frå tunnelen, landar ikkje på socketen du starta. Bind-adressa og omdirigeringsmålet må stemma overeins, og vanlegvis blir berre éin av dei kontrollert.

Kvar ein omdirigert pakke faktisk landar

Transparent proxy på ein gateway brukar REDIRECT i nat-tabellen under PREROUTING for å skriva om destinasjonen til ei innkommande tilknyting til ein lokal port. Den omskrivne destinasjonen er ei lokal adresse slik ho blir sett frå grensesnittet pakken kom inn på, ikkje loopback-adressa til ein prosess som starta ein annan stad. Ein lyttar som berre er bunden til 127.0.0.1, godtek tilknytingar som allereie var lokale på verten, og det er nettopp tilfellet som held fram med å verka medan tunneltrafikken feilar. Klienten si eiga loopback er ei tredje adresse og er aldri målet for regelen til gatewayen.

Så før du rører oppstraums påloggingsinformasjon, fastslå to fakta: kva lokal adresse regelen skriv om til, og kva adresse proxy-socketen er bunden til.

Les lyttaren og omdirigeringsregelen saman

Skriv ut socket-tabellen og nat-reglane i same gjennomkøyring, fordi ein regel som peikar på ein port ingen eig, ser identisk ut med ein regel som peikar på feil adresse. sudo ss -ltnp | grep redsocks viser bind-adressa og prosessen som eig ho. sudo iptables -t nat -S PREROUTING viser REDIRECT-målet, og sudo iptables -t nat -L PREROUTING -v -n viser om noko samsvara med det.

Eit hopp til ei brukarkjede kalla REDSOCKS oppnår ingenting med mindre den kjeda finst og ber dei tiltenkte unntaka og REDIRECT-handlinga. Les kjeda ho hoppar til med sudo iptables -t nat -S REDSOCKS i staden for å anta at namnet gjer arbeidet.

Samanlikn deretter dei to verdiane. Viss regelen omdirigerer til ei gateway-adresse på port 12345 og lyttaren rapporterer 127.0.0.1:12345, forklarar avviket feilen utan noko vidare diagnostikk.

Bind smalt, og avgrens deretter kva som kan nå det

Dømeoppsettet oppstraums set lyttaren på loopback av ei god grunn: ein transparent proxy godtek tilknytingar på vegner av alle som kan nå han. Å endra bindinga til 0.0.0.0 rettar leveringa og opnar samstundes porten på alle grensesnitt, noko som er ei sikkerheitsendring, ikkje ein nøytral reparasjon. Føretrekk å binda til den spesifikke lokale adressa omdirigeringa siktar mot, og hald porten lukka på grensesnitt ein ikkje stolar på. Viss ei breiare binding er uunngåeleg, legg til ein vertsbrannmurregel som berre tillèt kjeldeområdet til tunnelen og gatewayen sin eigen lokale trafikk.

Å opna porten på det offentlege grensesnittet er aldri naudsynt for omdirigert VPN-trafikk, fordi tilknytinga blir avslutta lokalt etter omskrivinga. Ikkje eksponer proxyen for internett for å få ei lokal omdirigering til å verka.

Prov det med ei ny tilknyting frå ein klient

Test frå ein ekte VPN-klient med ei fersk TCP-tilknyting, ikkje frå eit skal på gatewayen. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com på klienten prøver den omdirigerte stien frå ende til annan.

Stadfest deretter at ei direkte tilknyting til lyttaren frå eit nettverk ein ikkje stolar på framleis blir avvist, og at oppstraumstilknytinga til proxyen sjølv ikkje blir fanga igjen av den same regelen. Rekursiv fangst viser seg som ein proxy som koplar til seg sjølv og aldri fullfører ein førespurnad. Legg destinasjonen til proxyen til unntakssettet, eller merk dei utgåande pakkane hans slik at kjeda hoppar over dei.

Til slutt, hugse kva denne stien ikkje dekkjer. Vanleg redsocks TCP-omdirigering gjer ikkje UDP, QUIC eller DNS til SOCKS-trafikk, og private destinasjonar treng vanlegvis eksplisitte unntak. Ein vellukka lokal test beviser berre loopback-stien som aldri var problemet.