SOCKS5 tarpinis serveris OpenVPN: TCP tunelis ar programų tarpininkavimas?

Tarpinis serveris perduoda srautą, o ne datagramą. Palyginkite TCP tunelį už socks-proxy su redsocks peradresavimu ir pamatykite, kur kiekvienas sprendimas pirmiausia lūžta.

Tinklai, leidžiantys išeiti tik per tarpinį serverį, yra vieta, kur veikiantis profilis staiga miršta. Tarpinio serverio adresas yra mažiausiai įdomus tos nesėkmės kintamasis. Viską lemia srauto, kurį tarpinis serveris perduos, forma, nes šie tarpiniai serveriai perduoda baitų srautą, o UDP tunelis toks nėra. Lieka dvi architektūros, ir jos lūžta skirtingose vietose.

Vienas apribojimas lemia sprendimą

SOCKS5 tikrai nurodo UDP asociacijos režimą. Vis dėlto OpenVPN kliento tarpinio serverio palaikymas sukurtas aplink srautus: socks-proxy dokumentuotas TCP profiliams, o HTTP CONNECT tarpinis serveris neturi jokio kelio datagramoms. Viena dokumentacijos eilutė nusprendžia architektūrą prieš jums paliečiant konfigūracijos failą.

Taigi klausimas ne kurį tarpinį serverį pasirinkti. Klausimas, ar tunelis tampa srautu, ar lieka datagrama ir leidžia kam nors kitam absorbuoti tarpininkavimą.

A variantas: paverskite tunelį srautu

Tam reikia serverio su TCP klausytoju ir kliento profilio, kuriame nurodytas tarpinis serveris. Abi dalys būtinos, o serverio pusė yra ta, kurią žmonės pamiršta:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Pakeiskite paskutinę eilutę į http-proxy proxy.internal 8080, kai tarpinis serveris kalba HTTP, ir pridėkite prisijungimo duomenų failą, jei jo reikalauja. Tarpinis serveris turi sutikti atlikti CONNECT į jūsų VPN prievadą, o serveris turi atsakyti TCP; tik UDP klausytojas šį bandymą ignoruoja. Pasirinkti 443 yra praktiškas žingsnis, nes daugelis ribojančių tinklų leidžia jį ir mažai ką kita.

Kaina yra TCP, sukrautas ant TCP. Vienas prarastas išorinis segmentas sustabdo kiekvieną vidinį srautą, kuris dalijasi tuo ryšiu, todėl atkūrimas, kuris paprastai būtų nepriklausomas, tampa bendras. Sąranka taip pat užtrunka ilgiau, o nepastovus išorinis kelias tampa nepastoviu tuneliu, o ne lėtu.

B variantas: palikite tunelį ramybėje

Kai tunelis turi likti UDP, tunelis nėra vieta, kur ką nors konfigūruojate. Vietoj to, išeinantis TCP iš programų peradresuojamas į vietinį SOCKS klausytoją, ir programos niekada nesužino, kad tarpinis serveris egzistuoja. Linux sistemoje tai paprastai redsocks ir NAT REDIRECT taisyklė nat lentelėje.

Vėl tik TCP. Tik HTTP tarpinis serveris, pavyzdžiui privoxy, negali perduoti savavališkų protokolų, ir šis sprendimas taip pat neprideda datagramų palaikymo programoms.

Kiekvienai programai tiesiogiai pasakyti apie tarpinį serverį paprastai yra geriau ten, kur programinė įranga tai palaiko. Tai lengviau audituoti, ir jis lūžta vietoje, kurią tikrai matote.

Kur kiekvienas variantas lūžta

A variantas lūžta, kai serveriui trūksta TCP klausytojo, kai tarpinis serveris atsisako CONNECT tikslo arba kai išorinis srautas apribojamas žemiau to, ko tuneliui reikia. Pirmieji du palieka įrašą tarpinio serverio žurnale; trečiasis palieka ryšį, kuris užmezgamas ir paskui atrodo neteisingai. Perskaitykite tą žurnalą prieš redaguodami profilį, nes jis atskiria leidimų problemą nuo pajėgumų problemos. Užbaigtas CONNECT perkelia tyrimą į tunelio vidų.

B variantas lūžta viskam, kam reikia datagramų, protokolams, kurių tarpinis serveris nesupranta, ir tyliai tuose hostuose, kur peradresavimo taisyklė yra, bet maršrutizavimas siunčia srautą pro šalį.

Nė vienas variantas nekeičia įrenginio reikalavimo. Paketams vis dar reikia TUN arba TAP mazgo, kol branduolys juos maršrutizuos, todėl procesui vis dar reikia leidimo /dev/net/tun. Apvalkalas keičia tai, kas vyksta atidarius tą mazgą, o ne tai, ar jums jo reikia.

Įrodykite, kurį kelią sukūrėte

Žiūrėkite į lizdus, o ne į dėklo piktogramą. VPN procesas turi palaikyti užmegztą ryšį su tarpinio serverio adresu, o tarpinis serveris turėjo įrašyti tikslą, į kurį buvo paprašytas patekti:

ss -tnp | grep openvpn

Tada eikite į paskirties vietą, kurią gali aptarnauti tik tunelis, ir vardą, į kurį gali atsakyti tik tunelio sprendiklis. Užbaigtas tarpinio serverio ryšys su mirusiu tuneliu paprastai reiškia, kad tolimoji pusė niekada nepasiūlė jūsų profilyje nurodyto transporto.

Užsirašykite transportą ir priimantį tarpinį serverį ilgalaikėje vietoje. Kai tas pats profilis nepavyksta kitame tinkle, ta pastaba per kelias sekundes atmeta arba patvirtina tarpinį serverį.

Susiję straipsniai