Redsocks aŭskultas sur loopback, sed VPN-trafiko neniam alvenas

Tunelo ekfunkcias, la kliento povas pingsi la enirejon, kaj ĉiu reta peto tra la prokura vojo mortas. La redsocks-procezo funkcias kaj ĝia pordo aŭskultas, do la servo aspektas sana de la enirejo mem. Kio malsukcesas estas la transdona paŝo: paketo redirektita de la tunelo ne surteriĝas sur la soketon, kiun vi lanĉis. La liga adreso kaj la redirekta celo devas kongrui, kaj kutime nur unu el ili estas kontrolata.

Kien redirektita paketo efektive surteriĝas

Travidebla prokurado sur enirejo uzas REDIRECT en la nat-tabelo ĉe PREROUTING por reverki la celon de alvenanta konekto al loka pordo. La reverkita celo estas loka adreso vidata de la interfaco, sur kiu la paketo alvenis, ne la loopback-adreso de procezo lanĉita aliloke. Aŭskultanto ligita nur al 127.0.0.1 akceptas konektojn, kiuj jam estis lokaj sur la gastiganto, kaj ĝuste tiu kazo daŭre funkcias dum la tunela trafiko malsukcesas. La propra loopback de la kliento estas tria adreso kaj neniam estas la celo de la enireja regulo.

Do antaŭ ol tuŝi la legitimilojn de la supra fluo, starigu du faktojn: al kiu loka adreso la regulo reverkas, kaj al kiu adreso la prokura soketo estas ligita.

Legu la aŭskultanton kaj la redirektan regulon kune

Presu la soketan tabelon kaj la nat-regulojn en la sama eniro, ĉar regulo montranta al pordo, kiun neniu posedas, aspektas idente al regulo montranta al la malĝusta adreso. sudo ss -ltnp | grep redsocks montras la ligan adreson kaj la posedantan procezon. sudo iptables -t nat -S PREROUTING montras la celon REDIRECT, kaj sudo iptables -t nat -L PREROUTING -v -n montras, ĉu io kongruis kun ĝi.

Salti al uzantoĉeno nomata REDSOCKS atingas nenion, se tiu ĉeno ne ekzistas kaj ne portas la celitajn esceptojn kaj la agon REDIRECT. Legu la ĉenon, al kiun ĝi saltas, per sudo iptables -t nat -S REDSOCKS anstataŭ supozi, ke la nomo faras la laboron.

Poste komparu la du valorojn. Se la regulo redirektas al enireja adreso sur pordo 12345 kaj la aŭskultanto raportas 127.0.0.1:12345, la malkongruo klarigas la fiaskon sen ajna plua diagnozo.

Ligu mallarĝe, poste limigu, kio povas atingi ĝin

La supra ekzempla agordo defaŭltigas la aŭskultanton al loopback pro bona kialo: travidebla prokuro akceptas konektojn nome de ĉiu ajn, kiu povas atingi ĝin. Ŝanĝi la ligon al 0.0.0.0 riparas la transdonon kaj samtempe malfermas la pordon sur ĉiu interfaco, kio estas sekureca ŝanĝo, ne neŭtrala riparo. Preferu ligi al la specifa loka adreso, kiun la redirekto celas, kaj tenu la pordon fermita sur nefidindaj interfacoj. Se pli larĝa ligo neeviteblas, aldonu gastigantan fajroŝirmilan regulon, kiu permesas nur la fontan intervalon de la tunelo kaj la propran lokan trafikon de la enirejo.

Malfermi la pordon sur la publika interfaco neniam necesas por redirektita VPN-trafiko, ĉar la konekto finiĝas loke post la reverko. Ne elmetu la prokuron al la interreto por igi lokan redirekton funkcii.

Pruvu ĝin per nova konekto de kliento

Testu de reala VPN-kliento per freŝa TCP-konekto, ne de ŝelo sur la enirejo. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com sur la kliento ekzercas la redirektitan vojon de komenco ĝis fino.

Poste konfirmu, ke rekta konekto al la aŭskultanto de nefidinda reto estas ankoraŭ rifuzata, kaj ke la propra supra konekto de la prokuro ne estas denove kaptata de la sama regulo. Rikura kaptado montriĝas kiel prokuro, kiu konektiĝas al si mem kaj neniam finas peton. Aldonu la celon de la prokuro al la escepta aro, aŭ marku ĝiajn elirantajn paketojn, por ke la ĉeno preterpasu ilin.

Fine, memoru, kion ĉi tiu vojo ne kovras. Ordinara redsocks TCP-redirekto ne igas UDP, QUIC aŭ DNS en SOCKS-trafikon, kaj privataj celoj kutime bezonas eksplicitajn esceptojn. Sukcesa loka testo pruvas nur la loopback-vojon, kiu neniam estis la problemo.