A Redsocks a loopbacken figyel, de a VPN-forgalom soha nem érkezik meg
A csak loopbackre kötött figyelő soha nem látja a tun0-ról átirányított forgalmat. Olvassa el az átirányítási célt és a socket kötését, javítsa a kötést, majd teszteljen valódi kliensről.
Feljön egy alagút, a kliens pingelheti az átjárót, és minden webes kérés, amely a proxy útvonalán megy, meghal. A redsocks folyamat fut, és a portja figyel, tehát a szolgáltatás egészségesnek látszik magától az átjárótól. Ami meghiúsul, az a kézbesítési lépés: az alagútból átirányított csomag nem arra a socketre érkezik, amelyet Ön indított. A kötési címnek és az átirányítási célnak egyeznie kell, és általában csak az egyiket ellenőrzik.
Hová érkezik valójában egy átirányított csomag
Az átlátszó proxy az átjárón a nat tábla PREROUTING alatti REDIRECT szabályát használja, hogy egy bejövő kapcsolat célját helyi portra írja át. Az átírt cél az a helyi cím, ahogyan a csomagot fogadó interfész látja, nem pedig egy máshol indított folyamat loopback-címe. A csak 127.0.0.1-re kötött figyelő olyan kapcsolatokat fogad, amelyek már helyiek voltak a gazdagépen, és pontosan ez az az eset, amely továbbra is működik, miközben az alagút forgalma meghiúsul. A kliens saját loopbackje egy harmadik cím, és soha nem az átjáró szabályának célja.
Ezért mielőtt hozzányúlna a felső szintű hitelesítő adatokhoz, állapítsa meg két tényt: melyik helyi címre írja át a szabály, és melyik címre van kötve a proxy socketje.
Olvassa együtt a figyelőt és az átirányítási szabályt
Nyomtassa ki a socket táblát és a nat szabályokat egy menetben, mert egy olyan portra mutató szabály, amelynek nincs gazdája, pontosan úgy néz ki, mint egy rossz címre mutató szabály. sudo ss -ltnp | grep redsocks mutatja a kötési címet és a birtokló folyamatot. sudo iptables -t nat -S PREROUTING mutatja a REDIRECT célt, és sudo iptables -t nat -L PREROUTING -v -n mutatja, hogy illeszkedett-e hozzá bármi.
Egy REDSOCKS nevű felhasználói láncra ugrás semmit nem ér el, hacsak az a lánc nem létezik, és nem hordozza a szándékolt kizárásokat és a REDIRECT műveletet. Olvassa el a láncot, amelyre ugrik, a sudo iptables -t nat -S REDSOCKS segítségével, ahelyett hogy feltételezné, hogy a név elvégzi a munkát.
Ezután hasonlítsa össze a két értéket. Ha a szabály egy átjárócímre irányít a 12345 porton, és a figyelő 127.0.0.1:12345 jelent, az eltérés minden további diagnózis nélkül megmagyarázza a hibát.
Kössön szűken, majd korlátozza, mi érheti el
A felső szintű mintakonfiguráció jó okkal teszi a figyelőt loopbackre: az átlátszó proxy mindenki nevében fogad kapcsolatokat, aki el tudja érni. A kötés 0.0.0.0-ra változtatása javítja a kézbesítést, és egyidejűleg minden interfészen megnyitja a portot, ami biztonsági változás, nem semleges javítás. Inkább arra a konkrét helyi címre kössön, amelyet az átirányítás megcéloz, és tartsa zárva a portot a nem megbízható interfészeken. Ha a szélesebb kötés elkerülhetetlen, adjon hozzá egy gazdagép-tűzfal szabályt, amely csak az alagút forrás tartományát és az átjáró saját helyi forgalmát engedi.
A port megnyitása a nyilvános interfészen soha nem szükséges átirányított VPN-forgalomhoz, mert a kapcsolat az átírás után helyben fejeződik be. Ne tegye ki a proxyt az internetnek azért, hogy egy helyi átirányítás működjön.
Bizonyítsa új kapcsolattal egy kliensről
Teszteljen valódi VPN-kliensről friss TCP-kapcsolattal, ne az átjáró shelljéből. A curl -sS -o /dev/null -w '%{http_code}\n' http://example.com a kliensen végigpróbálja az átirányított útvonalat elejétől a végéig.
Ezután erősítse meg, hogy a figyelő felé irányuló közvetlen kapcsolat nem megbízható hálózatról továbbra is elutasításra kerül, és hogy a proxy saját felső kapcsolatát nem fogja el újra ugyanaz a szabály. A rekurzív elfogás olyan proxyként jelenik meg, amely önmagához kapcsolódik, és soha nem fejez be egy kérést. Adja hozzá a proxy célját a kizárási halmazhoz, vagy jelölje meg a kimenő csomagjait, hogy a lánc kihagyja őket.
Végül ne feledje, mit nem fed le ez az útvonal. A szokásos redsocks TCP-átirányítás nem alakítja az UDP-t, a QUIC-et vagy a DNS-t SOCKS-forgalommá, és a privát célok általában kifejezett kizárásokat igényelnek. Egy sikeres helyi teszt csak azt a loopback-útvonalat bizonyítja, amely soha nem volt a probléma.