Redsocks klausosi loopback adresu, bet VPN srautas niekada neateina

Tunelis pakyla, klientas gali pinginti tinklų sietuvą, o kiekviena žiniatinklio užklausa per proxy kelią miršta. redsocks procesas veikia ir jo prievadas klausosi, todėl paslauga atrodo sveika iš paties tinklų sietuvo. Kas nepavyksta, tai pristatymo žingsnis: iš tunelio peradresuotas paketas nenusileidžia ant socket, kurį paleidote. Priskyrimo adresas ir peradresavimo tikslas turi sutapti, o paprastai tikrinamas tik vienas iš jų.

Kur iš tikrųjų nusileidžia peradresuotas paketas

Skaidrusis proxy tinklų sietuve naudoja REDIRECT nat lentelėje prie PREROUTING, kad perrašytų gaunamo ryšio paskirties vietą į vietinį prievadą. Perrašyta paskirties vieta yra vietinis adresas, matomas iš sąsajos, kuria atėjo paketas, o ne kitur paleisto proceso loopback adresas. Klausytojas, pririštas tik prie 127.0.0.1, priima ryšius, kurie jau buvo vietiniai pagrindiniame kompiuteryje, ir būtent šis atvejis toliau veikia, kai tunelio srautas nepavyksta. Paties kliento loopback yra trečiasis adresas ir niekada nėra tinklų sietuvo taisyklės tikslas.

Todėl prieš liedami viršutinio lygio prisijungimo duomenis, nustatykite du faktus: į kurį vietinį adresą taisyklė perrašo ir prie kurio adreso prijungtas proxy socket.

Skaitykite klausytoją ir peradresavimo taisyklę kartu

Išspausdinkite socket lentelę ir nat taisykles vienu ėjimu, nes taisyklė, rodanti į prievadą, kurio niekas neturi, atrodo visiškai taip pat, kaip taisyklė, rodanti į neteisingą adresą. sudo ss -ltnp | grep redsocks rodo priskyrimo adresą ir jį turintį procesą. sudo iptables -t nat -S PREROUTING rodo REDIRECT tikslą, o sudo iptables -t nat -L PREROUTING -v -n rodo, ar kas nors jam atitiko.

Šuolis į vartotojo grandinę, pavadintą REDSOCKS, nieko nepasiekia, jei ta grandinė neegzistuoja ir neturi numatytų išimčių bei REDIRECT veiksmo. Skaitykite grandinę, į kurią jis šokinėja, su sudo iptables -t nat -S REDSOCKS, o ne manykite, kad pavadinimas atlieka darbą.

Tada palyginkite dvi reikšmes. Jei taisyklė peradresuoja į tinklų sietuvo adresą prievade 12345, o klausytojas praneša 127.0.0.1:12345, neatitikimas paaiškina gedimą be jokios papildomos diagnostikos.

Pririškite siaurai, tada apribokite, kas gali jį pasiekti

Viršutinio lygio pavyzdinė konfigūracija numatytai pririša klausytoją prie loopback dėl geros priežasties: skaidrusis proxy priima ryšius bet kieno, kas gali jį pasiekti, naudai. Priskyrimo pakeitimas į 0.0.0.0 pataiso pristatymą ir kartu atveria prievadą kiekvienoje sąsajoje, o tai saugumo pokytis, ne neutralus remontas. Verčiau pririškite prie konkretaus vietinio adreso, kurį peradresavimas taiko, ir laikykite prievadą uždarytą nepatikimose sąsajose. Jei platesnis priskyrimas neišvengiamas, pridėkite pagrindinio kompiuterio ugniasienės taisyklę, kuri leidžia tik tunelio šaltinio diapazoną ir paties tinklų sietuvo vietinį srautą.

Prievado atidarymas viešoje sąsajoje niekada nereikalingas peradresuotam VPN srautui, nes ryšys baigiasi vietiškai po perrašymo. Neatidarykite proxy internetui, kad vietinis peradresavimas veiktų.

Įrodykite tai nauju ryšiu iš kliento

Testuokite iš tikro VPN kliento su nauju TCP ryšiu, o ne iš apvalkalo tinklų sietuve. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com kliente išbando peradresuotą kelią nuo pradžios iki pabaigos.

Tada patvirtinkite, kad tiesioginis ryšys į klausytoją iš nepatikimo tinklo vis dar atmetamas, ir kad paties proxy viršutinis ryšys vėl nepagavauamas ta pačia taisykle. Rekursyvus gaudymas pasireiškia kaip proxy, kuris jungiasi prie savęs ir niekada neužbaigia užklausos. Pridėkite proxy paskirties vietą į išimčių rinkinį arba pažymėkite jo išeinančius paketus, kad grandinė juos praleistų.

Galiausiai atsiminkite, ko šis kelias neapima. Įprastas redsocks TCP peradresavimas nepaverčia UDP, QUIC ar DNS į SOCKS srautą, o privačios paskirties vietos paprastai reikalauja aiškių išimčių. Sėkmingas vietinis testas įrodo tik loopback kelią, kuris niekada nebuvo problema.