Redsocks kuuntelee loopbackissa, mutta VPN-liikenne ei koskaan saavu perille

Tunneli nousee, asiakas voi pingata yhdyskäytävää, ja jokainen proxy-polun kautta kulkeva verkkopyyntö kuolee. redsocks-prosessi on käynnissä ja sen portti kuuntelee, joten palvelu näyttää terveeltä yhdyskäytävän itsensä näkökulmasta. Epäonnistuva vaihe on toimitus: tunnelista uudelleenohjattu paketti ei laskeudu käynnistämällesi socketille. Sidontaosoitteen ja uudelleenohjauksen kohteen on täsmättävä, ja yleensä niistä tarkistetaan vain toinen.

Minne uudelleenohjattu paketti todella laskeutuu

Läpinäkyvä proxy yhdyskäytävässä käyttää PREROUTINGin nat-taulun REDIRECTiä saapuvan yhteyden kohteen uudelleenkirjoittamiseen paikalliseen porttiin. Uudelleenkirjoitettu kohde on paikallinen osoite siltä rajapinnalta nähtynä, jolle paketti saapui, ei muualla käynnistetyn prosessin loopback-osoite. Vain 127.0.0.1:een sidottu kuuntelija hyväksyy yhteydet, jotka olivat jo paikallisia isännässä, ja juuri tämä tapaus jatkaa toimintaa, kun tunnelin liikenne epäonnistuu. Asiakkaan oma loopback on kolmas osoite eikä ole koskaan yhdyskäytävän säännön kohde.

Niinpä ennen kuin kosket ylävirran tunnistetietoihin, varmista kaksi tosiasiaa: mihin paikalliseen osoitteeseen sääntö kirjoittaa uudelleen ja mihin osoitteeseen proxyn socket on sidottu.

Lue kuuntelija ja uudelleenohjaussääntö yhdessä

Tulosta socket-taulukko ja nat-säännöt samalla kierroksella, koska sääntö, joka osoittaa porttiin, jota kukaan ei omista, näyttää täsmälleen samalta kuin sääntö, joka osoittaa väärään osoitteeseen. sudo ss -ltnp | grep redsocks näyttää sidontaosoitteen ja omistavan prosessin. sudo iptables -t nat -S PREROUTING näyttää REDIRECT-kohteen, ja sudo iptables -t nat -L PREROUTING -v -n näyttää osuiko siihen jotain.

Hyppy käyttäjän ketjuun nimeltä REDSOCKS ei saavuta mitään, ellei kyseinen ketju ole olemassa ja kanna aiottuja poissulkemisia ja REDIRECT-toimintoa. Lue ketju, johon se hyppää, komennolla sudo iptables -t nat -S REDSOCKS sen sijaan, että olettaisit nimen tekevän työn.

Vertaa sitten kahta arvoa. Jos sääntö ohjaa uudelleen yhdyskäytävän osoitteeseen portissa 12345 ja kuuntelija ilmoittaa 127.0.0.1:12345, eroavuus selittää epäonnistumisen ilman mitään lisädiagnostiikkaa.

Sido kapeasti ja rajoita sitten, mikä voi tavoittaa sen

Ylävirran esimerkkikonfiguraatio asettaa kuuntelijan loopbackiin hyvästä syystä: läpinäkyvä proxy hyväksyy yhteyksiä kenen tahansa puolesta, joka voi tavoittaa sen. Sidonnan vaihtaminen 0.0.0.0:aan korjaa toimituksen ja avaa samalla portin jokaisella rajapinnalla, mikä on turvallisuusmuutos, ei neutraali korjaus. Sido mieluummin siihen tiettyyn paikalliseen osoitteeseen, jota uudelleenohjaus tavoittelee, ja pidä portti suljettuna epäluotetuilla rajapinnoilla. Jos laajempi sidonta on välttämätön, lisää isännän palomuurisääntö, joka sallii vain tunnelin lähde-alueen ja yhdyskäytävän oman paikallisen liikenteen.

Portin avaaminen julkisella rajapinnalla ei ole koskaan tarpeen uudelleenohjatulle VPN-liikenteelle, koska yhteys päättyy paikallisesti uudelleenkirjoituksen jälkeen. Älä altista proxya internetille, jotta paikallinen uudelleenohjaus toimisi.

Todista se uudella yhteydellä asiakkaalta

Testaa oikealta VPN-asiakkaalta tuoreella TCP-yhteydellä, älä yhdyskäytävän komentotulkista. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com asiakkaalla käy uudelleenohjatun polun läpi päästä päähän.

Vahvista sitten, että suora yhteys kuuntelijaan epäluotetusta verkosta hylätään edelleen, ja ettei proxyn omaa ylävirran yhteyttä kaapata uudelleen samalla säännöllä. Rekursiivinen kaappaus näkyy proxyna, joka yhdistää itseensä eikä koskaan suorita pyyntöä loppuun. Lisää proxyn kohde poissulkemisjoukkoon tai merkitse sen lähtevät paketit, jotta ketju ohittaa ne.

Muista lopuksi, mitä tämä polku ei kata. Tavallinen redsocksin TCP-uudelleenohjaus ei muuta UDP:tä, QUICia tai DNS:ää SOCKS-liikenteeksi, ja yksityiset kohteet tarvitsevat yleensä nimenomaisia poissulkemisia. Onnistunut paikallinen testi todistaa vain loopback-polun, joka ei ollut koskaan ongelma.