Redsocks dëgjon në loopback, por trafiku VPN nuk arrin kurrë

Një tunel ngrihet, klienti mund të bëjë ping në gateway dhe çdo kërkesë web nëpër rrugën e proxy vdes. Procesi redsocks është duke punuar dhe porta e tij po dëgjon, kështu që shërbimi duket i shëndetshëm nga vetë gateway. Ajo që dështon është hapi i dorëzimit: një paketë e ridrejtuar nga tuneli nuk ulet në socket-in që keni nisur. Adresa e lidhjes dhe objektivi i ridrejtimit duhet të përputhen, dhe zakonisht kontrollohet vetëm njëri prej tyre.

Ku ulet në të vërtetë një paketë e ridrejtuar

Proxy transparence në një gateway përdor REDIRECT në tabelën nat në PREROUTING për të rishkruar destinacionin e një lidhjeje hyrëse në një port lokal. Destinacioni i rishkruar është një adresë lokale siç e sheh ndërfaqja në të cilën mbërriti paketa, jo adresa loopback e një procesi të nisur diku tjetër. Një dëgjues i lidhur vetëm me 127.0.0.1 pranon lidhje që ishin tashmë lokale në host, dhe pikërisht ky është rasti që vazhdon të funksionojë ndërsa trafiku i tunelit dështon. Loopback-u i vetë klientit është një adresë e tretë dhe nuk është kurrë objektivi i rregullit të gateway.

Prandaj, përpara se të prekni kredencialet e nivelit të sipërm, vërtetoni dy fakte: në cilën adresë lokale rishkruan rregulli dhe në cilën adresë është lidhur socket-i i proxy.

Lexoni dëgjuesin dhe rregullin e ridrejtimit së bashku

Shtypni tabelën e socket-ëve dhe rregullat nat në të njëjtin kalim, sepse një rregull që tregon një port që askush nuk e zotëron duket njësoj si një rregull që tregon adresën e gabuar. sudo ss -ltnp | grep redsocks tregon adresën e lidhjes dhe procesin që e zotëron. sudo iptables -t nat -S PREROUTING tregon objektivin REDIRECT, dhe sudo iptables -t nat -L PREROUTING -v -n tregon nëse diçka përputhej me të.

Një kërcim në një zinxhir përdoruesi të quajtur REDSOCKS nuk arrin asgjë nëse ai zinxhir nuk ekziston dhe nuk mbart përjashtimet e synuara dhe veprimin REDIRECT. Lexoni zinxhirin në të cilin kërcen me sudo iptables -t nat -S REDSOCKS në vend që të supozoni se emri e bën punën.

Më pas krahasoni dy vlerat. Nëse rregulli ridrejton në një adresë gateway në portën 12345 dhe dëgjuesi raporton 127.0.0.1:12345, mospërputhja e shpjegon dështimin pa asnjë diagnostikim të mëtejshëm.

Lidhni ngushtë, më pas kufizoni çfarë mund t'i arrijë

Konfigurimi shembull i nivelit të sipërm e vendos dëgjuesin në loopback për një arsye të mirë: një proxy transparence pranon lidhje në emër të kujtdo që mund t'i arrijë. Ndryshimi i lidhjes në 0.0.0.0 rregullon dorëzimin dhe njëkohësisht hap portën në çdo ndërfaqe, gjë që është një ndryshim sigurie, jo një riparim neutral. Preferoni lidhjen me adresën specifike lokale që synon ridrejtimi dhe mbani portën të mbyllur në ndërfaqet e pabesuara. Nëse një lidhje më e gjerë është e pashmangshme, shtoni një rregull firewall-i në host që lejon vetëm gamën e burimit të tunelit dhe trafikun lokal të vetë gateway.

Hapja e portës në ndërfaqen publike nuk kërkohet kurrë për trafikun VPN të ridrejtuar, sepse lidhja përfundon lokalisht pas rishkrimit. Mos e ekspozoni proxy-n në internet për të bërë të funksionojë një ridrejtim lokal.

Provoni atë me një lidhje të re nga një klient

Provoni nga një klient VPN i vërtetë me një lidhje të re TCP, jo nga një shell në gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com në klient ushtron rrugën e ridrejtuar nga fillimi në fund.

Më pas konfirmoni që një lidhje e drejtpërdrejtë me dëgjuesin nga një rrjet i pabesuar refuzohet ende, dhe që lidhja e sipërme e vetë proxy nuk kapet përsëri nga i njëjti rregull. Kapja rekursive shfaqet si një proxy që lidhet me veten dhe nuk përfundon kurrë një kërkesë. Shtoni destinacionin e proxy në grupin e përjashtimeve, ose shënoni paketat e tij dalëse që zinxhiri t'i anashkalojë.

Së fundi, mbani mend çfarë nuk mbulon kjo rrugë. Ridrejtimi normal TCP i redsocks nuk i kthen UDP, QUIC ose DNS në trafik SOCKS, dhe destinacionet private zakonisht kërkojnë përjashtime të qarta. Një test lokal i suksesshëm provon vetëm rrugën e loopback që nuk ishte kurrë problemi.