OpenVPN üçün SOCKS5 proksisi: TCP tuneli, yoxsa tətbiqləri proksidən keçirmək?

Yalnız proksi vasitəsilə çıxışa icazə verən şəbəkələr işlək profilin qəflətən öldüyü yerdir. Proksi ünvanı bu uğursuzluqdakı ən az maraqlı dəyişəndir. Hər şeyi müəyyən edən proksinin ötürəcəyi trafikin formasıdır, çünki bu proksilər bayt axını ötürür və UDP tuneli belə deyil. Bu, iki arxitektura qoyur və onlar fərqli yerlərdə sınır.

Dizaynı bir məhdudiyyət müəyyən edir

SOCKS5 həqiqətən UDP assosiasiya rejimini müəyyən edir. OpenVPN müştəri proksisi dəstəyi buna baxmayaraq axınlar üzərində qurulub: socks-proxy TCP profilləri üçün sənədləşdirilib və HTTP CONNECT proksisinin heç bir datagram yolu yoxdur. Bir sənəd sətri konfiqurasiya faylına toxunmadan əvvəl arxitekturanı həll edir.

Deməli, sual hansı proksini seçmək deyil. Sual tunelin axına çevrilməsi, yoxsa datagram olaraq qalıb proksiləşdirmənin başqa bir şey tərəfindən udulmasıdır.

Variant A: tuneli axına çevirin

Bu, TCP dinləyicisi olan server və proksini adlandıran müştəri profili tələb edir. Hər iki hissə mütləqdir və insanların unutduğu hissə server tərəfidir:

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

Son sətri http-proxy proxy.internal 8080 ilə əvəz edin, proksi HTTP danışdıqda və tələb edirsə etimad faylı əlavə edin. Proksi VPN portunuza CONNECT etməyə hazır olmalı, server isə TCP üzərində cavab verməlidir; yalnız UDP dinləyicisi cəhdi nəzərə almır. 443 seçmək praktik addımdır, çünki bir çox məhdudlaşdırıcı şəbəkə buna və az başqa şeyə icazə verir.

Xərc TCP-nin TCP üzərinə yığılmasıdır. Bir itirilmiş xarici seqment həmin bağlantını paylaşan hər daxili axını dayandırır, beləliklə normalda müstəqil olan bərpa paylaşılan olur. Quraşdırma da daha uzun çəkir və qeyri-sabit xarici yol yavaş tunel deyil, qeyri-sabit tunelə çevrilir.

Variant B: tuneli tək buraxın

Tunel UDP-də qalmalı olduqda, heç nəyi konfiqurasiya etdiyiniz yer tunel deyil. Əvəzində tətbiqlərdən çıxan TCP yerli SOCKS dinləyicisinə yönləndirilir və tətbiqlər proksinin mövcud olduğunu heç vaxt öyrənmir. Linux-da bu adətən redsocks və nat cədvəlində NAT REDIRECT qaydası ilə olur.

Yenə yalnız TCP. privoxy kimi yalnız HTTP proksisi ixtiyari protokolları ötürə bilməz və bu dizayn tətbiqlər üçün datagram dəstəyi də əlavə etmir.

Hər tətbiqə proksidən birbaşa danışmaq, proqram təminatı dəstəklədiyi yerdə adətən daha yaxşıdır. Onu yoxlamaq asandır və həqiqətən görə bildiyiniz yerdə sınır.

Hər variant harada sınır

Variant A serverdə TCP dinləyicisi olmadıqda, proksi CONNECT hədəfini rədd etdikdə və ya xarici axın tunelin ehtiyacından aşağı məhdudlaşdırıldıqda sınır. İlk ikisi proksi jurnalında bir giriş buraxır; üçüncüsü qurulan və sonra yanlış hiss olunan bir bağlantı buraxır. Profili redaktə etməzdən əvvəl o jurnalı oxuyun, çünki o, icazə problemini tutum problemindən ayırır. Tamamlanmış CONNECT araşdırmanı tunelin içinə keçirir.

Variant B datagram tələb edən hər şey üçün, proksinin anlamadığı protokollar üçün və yönləndirmə qaydasının mövcud olduğu, lakin marşrutlaşdırmanın trafiki onun yanından keçirdiyi hostlarda səssizcə sınır.

Heç bir variant cihaz tələbini dəyişmir. Paketlər hələ də kernel onları marşrutlaşdırmadan əvvəl TUN və ya TAP qovşağına ehtiyac duyur, buna görə proses hələ də /dev/net/tun üzərində icazəyə ehtiyac duyur. Qabıq həmin qovşaq açıldıqdan sonra nə baş verdiyini dəyişir, ona ehtiyac olub-olmadığını yox.

Hansı yolu qurduğunuzu sübut etmək

Lövbər nişanına deyil, soketlərə baxın. VPN prosesi proksi ünvanına qurulmuş bağlantı saxlamalı, proksi isə ona çatması xahiş olunan hədəfi jurnala yazmış olmalıdır:

ss -tnp | grep openvpn

Sonra yalnız tunelin xidmət edə biləcəyi bir təyinat seçin və yalnız tunel həlledicisinin cavab verə biləcəyi bir ad seçin. Ölü tunellə tamamlanmış proksi bağlantısı adətən uzaq tərəfin profilinizdə adlandırılan nəqliyyatı heç vaxt təklif etmədiyini bildirir.

Nəqliyyatı və qəbul edən proksini davamlı bir yerdə qeyd edin. Eyni profil başqa şəbəkədə sındıqda, bu qeyd proksini saniyələr içində kənarlaşdırır və ya təsdiqləyir.