stunnel arxasında OpenVPN: port 1194-ü yox, sarğıcı yönləndirin

TLS sarğıcını OpenVPN qarşısına qoyun və quraşdırma ikinci bir dinləyici qazanır; bunlardan yalnız biri heç vaxt internetə baxmalıdır. Tunel eyni maşından işləyib kənardan uğursuz olduqda, yönləndirmə adətən ikisindən səhv olanına tuşlanır. Düzülməli olan bir zəncirdir: ümumi qayda sarğıcya çatır, sarğıcın öz backend bağlantısı isə həqiqi VPN soketinə çatır. Bu zənciri dörd addım daşıyır və onlardan hər hansı biri araşdırmanı erkən bitirə bilər.

İki soket, iki sahib, biri ümumi

Sarğıc xarici bağlantı üçün TLS-i sonlandırır və deşifrə edilmiş bayt axınını adi OpenVPN TCP dinləyicisinə ötürür. Bunlar ayrı konfiqurasiya faylları olan ayrı soketlərdir, ona görə birini redaktə etmək digərini toxunulmaz və zahirən sağlam qoyur. Bu həm də o deməkdir ki, biri digəri olmadan dəyişdirildikdə ikisi bir-birindən uzaqlaşa bilər.

Maşının özündən işləmək buna görə ümumi yol haqqında çox az şey sübut edir. Doğma porta birbaşa qoşulma sarğıcı atlayır, sarğıcya onun LAN ünvanından qoşulma tərcüməni atlayır və yalnız tam müştəri tərəfi quruluşu kənar istifadəçinin etdiklərini sınaqdan keçirir. Adları da diqqətlə oxumaq lazımdır, çünki localhost həmin komponenti işlədən host deməkdir, təsadüfən yazdığınız host yox. Bu fərqi qeydlərinizdə saxlayın, çünki əhatə etdiyi addım olmadan qeyd edilmiş test iki fərqli şeyin müqayisəsinə dəvət edir.

Yönləndirmə əslində hara düşür

Zənciri üç port nömrəsi kimi deyil, dörd addım kimi yadda saxlamaq asandır, çünki eyni nömrə hər ucda fərqli şeylər ifadə edə bilər. Cədvəli sətir-sətir oxuyun: hər sətir əvvəlcə bağlantı qəbul etməli, sonra növbətini açmalı olan bir soketdir. Bir sətir səhv həmsöhbətə yönəldildikdə, istifadəçinin bildirdiyi şey son sütundakı simptomdur.

Sarğıc yerinə doğma VPN portunu hədəfləyən qayda TLS sonlandırmasını tamamilə atlayır; bu səhvin ən çox yayılmış variantı budur: müştəri OpenVPN kadrlaşdırması gözləyən dinləyici ilə əl sıxışması açır, ona görə bağlantı açıla və sonra dayana bilər. Tərcümə olunmuş portu yaddaşa deyil, sarğıcın konfiqurasiya faylına qarşı təsdiqləyin, çünki həmin faylı növbəti dəfə redaktə edən fərqli nömrə seçmiş ola bilər. Aşağıdakı iki əmr bu sualın hər iki tərəfini eyni anda göstərir.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Sizi rədd edən bağlanma ünvanı

127.0.0.1 ünvanına bağlanmış accept sətri yalnız hostun özünə cavab verir, ona görə LAN ünvanına gələn yönləndirmə qoşula bilmir və müştəri paket süzgəci problemi kimi görünən bir rədd cavabı görür. Firewall-a toxunmazdan əvvəl soketə baxın, çünki soket daha ucuz cavabdır. Ya sarğıcı yönləndirmənin hədəflədiyi interfeysə bağlayın, ya da onu loopback-də saxlayıb yönləndirmənin loopback-ə həqiqətən işləyən bir şey vasitəsilə çatmasını təmin edin. Bunlar iki dizayndır və hər birinin öz qaydası lazımdır.

Onları qarışdırmaq işlək sarğıcın hər fayl düzgün görünərkən kənardan əlçatmaz olmasına gətirib çıxarır. Aşağıdakı yoxlama bir əmrdir və firewall qaydalarının nəzərdən keçirilməsinin cavab verə bilmədiyi suala cavab verir. Çıxış loopback ünvanı göstərirsə, yönləndirmə isə LAN ünvanını hədəfləyirsə, düzəliş accept sətrinə aiddir, paket süzgəcinə yox.

ss -lntp '( sport = :8443 )'

Yerli test əslində nəyi sübut etdi

Keçdiyi addım qeyd olunmadan yazılmış uğur digər addımlar haqqında sübut deyil. Testin hansı ünvandan istifadə etdiyini və hansı prosesin cavab verdiyini qeyd edin. Sonra şəbəkədən kənardan təkrarlayın, eyni Wi-Fi-dakı telefondan yox, çünki hairpin davranışı routerlər arasında dəyişir və LAN-dan heç vaxt çıxmayan bağlantı yönləndirmə heç iştirak etmədən müştərini qane edə bilər. Yalnız o ikinci cəhd kənar adamın getdiyi yolu sınaqdan keçirir.

Cəhd uğursuz olduqda, hər iki jurnalda tək bir bağlantını izləyin: sarğıcın qəbul və qoşulma sətirləri, sonra VPN demonunun öz sessiya jurnalı. Heç nə qeyd etməyən ilk sərhəd növbəti dəyişikliyin yeridir. OpenVPN həmsöhbət seçimlərini müqayisə etməyə başladıqdan sonra o mesajları həmin tətbiqin qaydaları ilə qiymətləndirin. link-mtu uyğunsuzluğu xəbərdarlığı avtomatik ölümcül deyil, link-mtu-nu 1500-ə bərkitmək fraqmentasiyanın dayandığını sübut etmir və şifr danışıqları routerin yönləndirməsinə deyil, daxili OpenVPN konfiqurasiyasına aiddir.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Bu zondlar backend soketini və sarğıc jurnalını əhatə edir, bu da rədd edilmiş backend-i rədd edilmiş əl sıxışmasından ayırır. Onları sonra deyil, tək cəhd davam edərkən işlədin. Etibarlı müqayisəni bir cəhdin zaman damğaları təmin edir.

İki kimlik, iki uğursuzluq sırası

Xarici sertifikat sarğıcya, daxili kimlik isə OpenVPN-ə məxsusdur və onlar fərqli orqanlardan gələ bilər. Yolu sağlam göstərmək üçün yoxlamalardan birini söndürmək real müdafiəni kosmetik nəticə ilə dəyişir. Hər iki yoxlamanı saxlayın və onları sıra ilə ayıklayın, çünki mesajların ardıcıllığı təbəqəni adlandırır: sarğıc sertifikatı problemi hər hansı VPN seçimi danışılmazdan əvvəl görünür, daxili kimlik uğursuzluğu isə yalnız axın qurulduqdan sonra üzə çıxır.

stunnel təlimatı accept, connect və client rejimini dəqiq müəyyənləşdirir və həmin bölmələr soket sualına təxmindən daha sürətli cavab verir. Hansı təbəqənin cavab verdiyini hələ də müəyyən edə bilmirsinizsə, aşağıdakı əmrlə ümumi portun təqdim etdiyi sertifikatı oxuyun. Çıxışda sarğıc sertifikatı yönləndirmənin sarğıcya çatdığını bildirir, sükut və ya protokol xətası isə çatmadığını. Bu tək fərq buradakı hər hansı digər yoxlamadan daha çox vaxt qazandırır.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer