SOCKS5 üzərindən OpenVPN: versiya, ötürmə və DNS uyğunlaşdırması

Bu iş stansiyasından çıxan yollardan biri SOCKS proxy-sidir və onun arxasındakı OpenVPN heç bir faydalı təfərrüat olmadan bağlantı vaxtının bitdiyini bildirir. Eyni maşındakı brauzer həmin proxy ilə işləyir, etimad məlumatları düzdür və port cavab verir. Üç şey əvvəlcə yoxlanılacaq qədər tez-tez fərqlənir: proxy-nin danışdığı SOCKS versiyası, müştərinin seçdiyi ötürmə və ad həllinin baş verdiyi yer. Firewall-u günahlandırmadan əvvəl hər birini təsdiqləyin.

Firewall-dan əvvəl SOCKS versiyasını uyğunlaşdırın

İcma OpenVPN socks-proxy üçün SOCKS5 danışır. Onu yalnız SOCKS4 təklif edən proxy-yə yönəldin, TCP bağlantısı açılır və sonra dayanır, çünki müştəri qarşı tərəfin heç vaxt təhlil etmədiyi salamlamaya cavab gözləyir. Kənardan bu dayanma filtrlənmiş port kimi görünür, buna görə versiya sualı hər hansı firewall qaydasından əvvəl gəlir. SOCKS bilən bir gətirmə bunu bir əmrlə həll edir.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

Tamamlanmış sorğu eyni anda iki şeyi sübut edir: proxy SOCKS sorğusunu qəbul etdi və adı həll etdi. URL sxemi lazım deyil, çünki curl çılpaq hostu HTTP kimi qəbul edir və bu, bu test üçün kifayətdir.

Həmin gətirmə müştəri jurnalının gizlətdiyi nasazlığı da istisna edir. Proxy brauzerə icazə verib yenə də VPN təyinatını rədd edə bilər, o zaman rədd CONNECT mərhələsində, hər hansı VPN autentifikasiyasından əvvəl olur. OpenVPN yalnız vaxt bitməsini bildirir, buna görə proxy-nin öz cavabı sizə lazım olan sübutdur.

Ötürmə hər iki tərəfdə TCP olmalıdır

Burada SOCKS5 TCP axını daşıyır, buna görə tunelin özü proto tcp-client tələb edir. Hələ UDP-də qurulmuş profil bu yolla işləməyəcək, çünki müştəri protokolun UDP assosiasiya rejimindən istifadə etmir. Profili çevirmək formal deyil, real dəyişiklikdir: uzaq tərəf eyni portda TCP dinləməlidir. Sonra yük TCP içində TCP olur, itirilmiş seqment iki dəfə yenidən göndərilir və temp pisləşir, bunu interaktiv sessiyalar böyük ötürmələrdən qat-qat çox hiss edir.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

Bu direktiv proxy hostunu, istəyə bağlı portu və istəyə bağlı etimad faylını alır. Onları profilin özünə qoyun ki, başqa yerdəki kopya eyni cür davransın.

Bütün zənciri bir konteynerə qapadın

Zənciri hostda etmək onun standart marşrutunu ələ keçirmək və həlledicini sonradan heç kimin izah edə bilməyəcəyi vəziyyətdə qoymaq deməkdir. Əvəzində ad məkanı və ya konteyner onu məhdudlaşdırır, beləliklə host öz yolunu saxlayır, SOCKS addımı və tunel birlikdə yaşayır. İçəridə tunel qurğusu, onu konfiqurasiya etmək hüququ və əlçatan proxy olmadan heç nə qalxmır. Compose xidməti bunu cap_add: NET_ADMIN və bind ilə bərkidilmiş /dev/net/tun ilə alır.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Bu cüt konteyneri imtiyazlı işlətməkdən daha dardır və qurğuya çıxışın bütün lazımi hissəsi budur. Tor müştərisi və ya ayrı proxy konteyneri dinləyicini təmin edə bilər. Hər iki halda onu loopback-ə bağlayın və proxy-ni şəbəkəyə açmaq əvəzinə ad məkanından host vasitəsilə ona çatın.

Ad həlli təcridin pozulduğu yerdir

Paketləri daşıyıb yenə də hostun həlledicisindən soruşan tunel heç nəyi təcrid etməmişdir. İki şey təcridi real edir: ad məkanının öz həlledicisi var və sorğuları proxy və ya tunel vasitəsilə gedir, heç vaxt fiziki interfeysdən getmir. Test üçün iki ad istifadə edin: biri yalnız tunelin arxasında mövcuddur, digəri eyni yolla getməli olan ümumi addır.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

Uzaq ad həll olunub ümumi ad olunmursa, zəncir sınıq deyil, seçicidir və fərq hər sorğunun hansı yolu getdiyini söyləyir. İkisi də hostdan həll olunub konteyner içində heç biri olunmursa, konteyner hələ də hostun həlledicisini borc alır. Tapdığınız həlledici faylını qeyd edin, çünki dəyişdirilməli ayar elə odur.

Hər addımı sıra ilə sübut edin

Siyahı qısadır. SOCKS5 sorğusu cavab alır, tunel proxy vasitəsilə dinləyicisinə çatır və ad məkanından çıxan paketlər uzaq tərəfin gözlədiyi ünvanı daşıyır. Daha çox konfiqurasiya yığmaq əvəzinə hər birini ayrı-ayrı təsdiqləyin. Müştəri bağlandı deyib heç nə tərpənmirsə, qırılma demək olar ki, həmişə ikinci və ya üçüncü faktdadır.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

İşləyən kombinasiyanı yazın: SOCKS versiyası, ötürmə, həlledici və ad məkanı ayarları. Bu zənciri ikinci dəfə yaddaşdan həll etmək qeyddən bahadır. O dörd faktı söhbətdə deyil, biletdə saxlayın.

Bağlandığını bildirib heç nə keçirməyən zəncir adətən hələ sübut etmədiyiniz addımda uğursuz olub. Başqa qat əlavə etməzdən əvvəl o addımı sınayın.