Redsocks posluša na loopbacku, a promet VPN nikoli ne prispe

Predor se dvigne, odjemalec lahko pinga prehod, in vsaka spletna zahteva po poti proxy umre. Proces redsocks teče in njegova vrata poslušajo, zato je storitev videti zdrava s samega prehoda. Kar spodleti, je korak dostave: paket, preusmerjen iz predora, ne pristane na vtičnici, ki ste jo zagnali. Naslov vezave in cilj preusmeritve se morata ujemati, običajno pa se preveri le eden od njiju.

Kam preusmerjeni paket v resnici prispe

Pregledni proxy na prehodu uporablja REDIRECT v tabeli nat pri PREROUTING, da prepiše cilj dohodne povezave na lokalna vrata. Prepisani cilj je lokalni naslov, kot ga vidi vmesnik, po katerem je paket prispel, ne pa loopback naslov procesa, zagnanega drugje. Poslušalec, vezan samo na 127.0.0.1, sprejema povezave, ki so bile že lokalne na gostitelju, in to je natanko tisti primer, ki še naprej deluje, medtem ko promet predora spodleti. Loopback odjemalca samega je tretji naslov in nikoli ni cilj pravila prehoda.

Zato pred posegom v poverilnice zgornje ravni ugotovite dve dejstvi: na kateri lokalni naslov pravilo prepisuje in na kateri naslov je vezana vtičnica proxyja.

Berite poslušalca in pravilo preusmeritve skupaj

Natisnite tabelo vtičnic in pravila nat v enem prehodu, ker je pravilo, ki kaže na vrata, ki jih nihče ne poseduje, videti enako kot pravilo, ki kaže na napačen naslov. sudo ss -ltnp | grep redsocks prikaže naslov vezave in proces, ki ga ima. sudo iptables -t nat -S PREROUTING prikaže cilj REDIRECT, sudo iptables -t nat -L PREROUTING -v -n pa prikaže, ali se je kaj ujemalo z njim.

Skok v uporabniško verigo z imenom REDSOCKS ne doseže ničesar, razen če ta veriga obstaja in nosi predvidene izjeme in dejanje REDIRECT. Preberite verigo, v katero skače, z sudo iptables -t nat -S REDSOCKS, namesto da bi domnevali, da ime opravi delo.

Nato primerjajte obe vrednosti. Če pravilo preusmerja na naslov prehoda na vratih 12345 in poslušalec poroča 127.0.0.1:12345, neskladje pojasni napako brez vsakršne dodatne diagnostike.

Vežite ozko, nato omejite, kaj lahko pride do njega

Vzorne konfiguracije zgornje ravni privzeto postavijo poslušalca na loopback z dobrim razlogom: pregledni proxy sprejema povezave v imenu vsakogar, ki lahko pride do njega. Sprememba vezave na 0.0.0.0 popravi dostavo in hkrati odpre vrata na vsakem vmesniku, kar je varnostna sprememba, ne nevtralno popravilo. Raje vežite na točen lokalni naslov, ki ga preusmeritev cilja, in imejte vrata zaprta na nezaupljivih vmesnikih. Če je širša vezava neizogibna, dodajte pravilo požarnega zidu gostitelja, ki dovoli le obseg vira predora in lasten lokalni promet prehoda.

Odpiranje vrat na javnem vmesniku za preusmerjeni promet VPN ni nikoli potrebno, ker se povezava po prepisu konča lokalno. Proxyja ne izpostavljajte internetu, da bi lokalna preusmeritev delovala.

Dokažite to z novo povezavo z odjemalca

Preizkusite s pravega odjemalca VPN z novo povezavo TCP, ne iz lupine na prehodu. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com na odjemalcu preizkusi preusmerjeno pot od začetka do konca.

Nato potrdite, da je neposredna povezava do poslušalca iz nezaupljivega omrežja še vedno zavrnjena in da odhodna povezava proxyja samega ni znova ujeta z istim pravilom. Rekurzivno prestrezanje se pokaže kot proxy, ki se povezuje sam s sabo in nikoli ne dokonča zahteve. Dodajte cilj proxyja v množico izjem ali označite njegove odhodne pakete, da jih veriga preskoči.

Nazadnje pomnite, česa ta pot ne pokriva. Običajna preusmeritev TCP v redsocks ne spremeni UDP, QUIC ali DNS v promet SOCKS, zasebni cilji pa običajno zahtevajo izrecne izjeme. Uspešen lokalni preizkus dokaže le pot skozi loopback, ki nikoli ni bila težava.