Redsocks klausās uz loopback, bet VPN trafiks nekad neienāk

Tunelis paceļas, klients var pingot vārteju, un katrs tīmekļa pieprasījums pa starpniekservera ceļu nomirst. redsocks process darbojas un tā ports klausās, tāpēc pakalpojums izskatās vesels no pašas vārtejas. Tas, kas neizdodas, ir piegādes solis: no tuneļa novirzīts pakets nenokļūst uz socket, kuru jūs palaidāt. Piesaistes adresei un novirzīšanas mērķim ir jāsakrīt, un parasti tiek pārbaudīts tikai viens no tiem.

Kur novirzīts pakets patiešām nokļūst

Caurspīdīgs starpniekserveris uz vārtejas izmanto REDIRECT nat tabulā pie PREROUTING, lai pārrakstītu ienākošā savienojuma galamērķi uz lokālu portu. Pārrakstītais galamērķis ir lokāla adrese, kā to redz saskarne, pa kuru pakets ienāca, nevis citur palaista procesa loopback adrese. Klausītājs, kas piesaistīts tikai 127.0.0.1, pieņem savienojumus, kas jau bija lokāli uz resursdatora, un tieši šis gadījums turpina darboties, kamēr tuneļa trafiks neizdodas. Paša klienta loopback ir trešā adrese, un tā nekad nav vārtejas noteikuma mērķis.

Tāpēc pirms augšupējās puses akreditācijas datu aizskaršanas noskaidrojiet divus faktus: uz kuru lokālo adresi noteikums pārraksta un kurai adresei ir piesaistīts starpniekservera socket.

Lasiet klausītāju un novirzīšanas noteikumu kopā

Izdrukājiet socket tabulu un nat noteikumus vienā piegājienā, jo noteikums, kas norāda uz portu, kam neviena nav, izskatās tieši tāpat kā noteikums, kas norāda uz nepareizu adresi. sudo ss -ltnp | grep redsocks parāda piesaistes adresi un to īpašo procesu. sudo iptables -t nat -S PREROUTING parāda REDIRECT mērķi, un sudo iptables -t nat -L PREROUTING -v -n parāda, vai kaut kas tam atbilda.

Lēciens uz lietotāja ķēdi ar nosaukumu REDSOCKS neko nesasniedz, ja vien šī ķēde neeksistē un nesatur paredzētos izņēmumus un REDIRECT darbību. Lasiet ķēdi, uz kuru tas lec, ar sudo iptables -t nat -S REDSOCKS, nevis pieņemiet, ka nosaukums paveic darbu.

Pēc tam salīdziniet abas vērtības. Ja noteikums novirza uz vārtejas adresi portā 12345 un klausītājs ziņo 127.0.0.1:12345, neatbilstība izskaidro kļūmi bez jebkādas papildu diagnostikas.

Piesaistiet šauri, pēc tam ierobežojiet, kas tam var piekļūt

Augšupējās puses parauga konfigurācija pēc noklusējuma liek klausītāju uz loopback laba iemesla dēļ: caurspīdīgs starpniekserveris pieņem savienojumus jebkura vārdā, kas tam var piekļūt. Piesaistes maiņa uz 0.0.0.0 izlabo piegādi un vienlaikus atver portu katrā saskarnē, kas ir drošības izmaiņa, nevis neitrāls remonts. Labāk piesaistiet konkrētajai lokālajai adresei, uz kuru mērķē novirzīšana, un turiet portu aizvērtu neuzticamās saskarnēs. Ja plašāka piesaiste ir neizbēgama, pievienojiet resursdatora ugunsmūra noteikumu, kas atļauj tikai tuneļa avota diapazonu un pašas vārtejas lokālo trafiku.

Porta atvēršana publiskajā saskarnē nekad nav nepieciešama novirzītam VPN trafikam, jo savienojums beidzas lokāli pēc pārrakstīšanas. Nepakļaujiet starpniekserveri internetam, lai lokāla novirzīšana darbotos.

Pierādiet to ar jaunu savienojumu no klienta

Pārbaudiet no īsta VPN klienta ar svaigu TCP savienojumu, nevis no čaulas uz vārtejas. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com klientā izmēģina novirzīto ceļu no sākuma līdz beigām.

Pēc tam apstipriniet, ka tiešs savienojums ar klausītāju no neuzticama tīkla joprojām tiek noraidīts, un ka paša starpniekservera augšupējais savienojums netiek atkal uztverts ar to pašu noteikumu. Rekursīva uztveršana izpaužas kā starpniekserveris, kas savienojas ar sevi un nekad nepabeidz pieprasījumu. Pievienojiet starpniekservera galamērķi izņēmumu kopai vai atzīmējiet tā izejošos paketus, lai ķēde tos izlaistu.

Visbeidzot, atcerieties, ko šis ceļš neaptver. Parastā redsocks TCP novirzīšana nepārvērš UDP, QUIC vai DNS SOCKS trafikā, un privātiem galamērķiem parasti ir vajadzīgi skaidri izņēmumi. Veiksmīgs lokāls tests pierāda tikai loopback ceļu, kas nekad nebija problēma.