Serverə bağlanmış profil TLS proksisinin arxasında uğursuz olur: hansı nəsil?

Bir istifadəçi qoşula bilir, digəri isə eyni portal, eyni gün vasitəsilə qoşula bilmir. Hər ikisinin serverə bağlanmış profili var, hər ikisi eyni Access Server buraxılışındadır və yeganə fərq profilin nə vaxt yaradıldığıdır. Bu, diqqətə layiq nümunədir, çünki "serverə bağlanmış" qoşulma ardıcıllığını deyil, siyasəti adlandırır. Access Server həmin artefaktın iki nəslini buraxıb və TLS tərs proksisi onların yollarından yalnız birinin qarşısında dayanır. Hansı budaqda olduğunuzu üç şərt müəyyən edir.

İki nəsil, iki qoşulma ardıcıllığı

Köhnə dizaynda, 2.8 daxil olmaqla, idxal edilən fayl psevdo-profildir. OpenVPN Connect ondan HTTPS üzərindən Access Server veb API-si qarşısında autentifikasiya üçün istifadə edir, müvəqqəti istifadəçiyə bağlanmış profil və sessiya tokeni alır və yalnız bundan sonra VPN qurur. İki nəqliyyat ardıcıl işləyir və birincisi adi veb sorğudur.

2.9 ilə təqdim edilən format həmin hər-əlaqə üçün ilkin yükləməni yerinə yetirmir. Bu, yalnız OpenVPN Connect üçün deyil, uyğun OpenVPN müştərilər üçün istifadə oluna bilən doğma profildir. Onu endirmək və ya URL ilə idxal etmək hələ də HTTPS tələb edə bilər — bu, nəşretmə addımıdır, hər-əlaqə üçün müvəqqəti profil gətirməsi deyil.

Yeniləmə artıq verilmiş profilləri mütləq yenidən yazmır, buna görə cari server versiyası hələ də köhnə artefaktı paylaya bilər. Server buraxılışı sizə nəyin mümkün olduğunu deyir, bu istifadəçinin nə idxal etdiyini deyil.

Budağınızı seçən üç şərt

Birinci şərt artefaktın nəslidir. Faylı istəyin, onun necə istehsal olunduğuna baxın və onu idxal edən müştəri versiyasını qeyd edin. Əgər nəsli fayldan müəyyən edə bilmirsinizsə, test hesabı üçün verilmiş yeni profil sizə serverin bugün nə istehsal etdiyini göstərəcək və bu, uğursuz olan istifadəçinin saxladığından fərqli məlumatdır.

İkincisi, ön hissənizin həqiqətən nəyi sonlandırdığıdır. TLS-i yükdən azad edən yeddinci qat HTTP tərs proksisi dördüncü qat TCP yönləndiricisi ilə eyni obyekt deyil və UDP yönləndiricisi də eyni deyil. Access Server-in 443 portundakı adi quruluşunda OpenVPN TCP demonu brauzer trafikini tanıyır və onu veb xidmətlərinə ötürür, buna görə qarşıya əlaqəsiz HTTPS sonlandırıcı qoymaq həmin demonun protokol emalını qorub saxlamır. 443 rəqəmini paylaşmaq iki dizaynı ekvivalent etmir.

Üçüncüsü, uğursuzluğun harada baş verməsidir. VPN-dən əvvəlki uğursuzluq və idarəetmə kanalı uğursuzluğu yalnız "qoşulur" deyən müştəridə oxşar görünür, lakin fərqli yerlərdə sübut qoyurlar. Əgər köhnə format işdədirsə, ilkin yükləmə namizəddir. Əgər yeni format işdədirsə, boş veb giriş jurnalı gözləniləndir və heç bir tərəfi sübut etmir.

Artefakt köhnə olduqda: ilkin yükləmə birinci uğursuz olur

Müştərinin son vəziyyətini deyil, faktiki xətasını oxuyun. Maraqlı sahələr HTTPS xətası, müştərinin gözlədiyi server kimliyi, sorğunun getdiyi təyinat və sertifikat yoxlamasının tamamlanıb-tamamlanmamasıdır. Sonra bunları server tərəfindəki veb xidməti və proksi jurnalları ilə uyğunlaşdırın.

Brauzerin giriş səhifəsinə çatması bu müştərinin API autentifikasiyasının uğurlu olduğuna sübut deyil. Bunlar fərqli sorğulardır, fərqli sertifikat gözləntiləri və çox vaxt fərqli host adları ilə. Əgər portal düzgün təqdim olunursa və müştəri hələ də uğursuz olursa, ziddiyyət ilkin yükləmə yolundadır, istifadəçinin parolunda deyil.

Müqayisəni TLS yoxlamasını söndürməklə və ya autentifikasiya siyasətini yumşaltmaqla keçirməyin. Bu, diaqnostika edilə bilən konfiqurasiya uyğunsuzluğunu işləyən-amna-yoxlanılmamış yola çevirir və məhz bu dəyişiklik müvəqqəti testi daimi deşiyə çevirir. Access Server əlaqə profili sənədləşməsi hər iki nəsli və müvəqqəti profil axınını təsvir edir və proksinin günahkar olduğunu fərz etməzdən əvvəl yoxlanmalı mənbədir.

Artefakt yeni olduqda: əvəzinə idarəetmə kanalını oxuyun

2.9 üslublu profil ilə müştəri birbaşa doğma VPN son nöqtəsinə gedir. Profildəki son nöqtələri, istifadə olunan nəqliyyatı və idarəetmə kanalı xətasını araşdırın. Əgər müştəri heç vaxt HTTP sorğusu göndərmirsə, bu dizayna uyğundur və simptom deyil.

Proksi sualı da burada forma dəyişir. HTTPS yükündən azad etmə heç vaxt görmədiyi yalnız-TCP axını poza bilməz, lakin profili nəşr edən endirməni poza bilər və yalnız-TCP yönləndirici UDP-ni ümumiyyətlə daşımaz. Ön hissənin əlaqəsiz olduğu qənaətinə gəlməzdən əvvəl profilin hansı nəqliyyatı tələb etdiyini yoxlayın.

Tək axın üçün TLS keçirmə dar bir tənzimləmədir. UDP yönləndirməsi təmin etmir və demonun 443-dəki öz xidmət yönləndirmə davranışını təkrar etmir. Əgər ön hissəniz bunlardan birini edirsə, hansını etdiyini deyin, çünki həll fərqlidir.

Dar qalan həll yolları

Ən az müdaxilə edən yoxlama test hesabı üçün yeni dəstəklənən profil yaratmaq və eyni autentifikasiya tələbləri ilə nəzərdə tutulan doğma son nöqtə vasitəsilə qoşulmaqdır. Əgər bu işləyirsə və saxlanılan köhnə profil işləmirsə, bir addımda artefaktı serverdən və proksidən ayırmısınız.

İstifadəçiyə bağlanmış profilin paylanması köhnə ilkin yükləmə asılılığını tamamilə aradan qaldırır, çünki uğursuz ola biləcək müvəqqəti profil mübadiləsi yoxdur. O, nəzərdə tutulan istifadəçi üçün verilməlidir, heç vaxt administratorun profilindən kopyalanmamalıdır və müştərinin nəyə icazəli olduğunu dəyişir, buna görə ona müvəqqəti həll deyil, siyasət qərarı kimi yanaşın.

Sonra nəşretmə tərtibatını hər tələb olunan yol mövcud olacaq şəkildə düzəldin: endirmələr və portal istifadəsi üçün veb yolu və profillərin gözlədiyi nəqliyyat üzərində doğma VPN yolu. Proksin işini bir qatda saxlayın. İşləyən istifadəçiyə bağlanmış tunel həmin yolun işlədiyini sübut edir; hər proksi tənzimləməsinin hər nəsli dəstəklədiyini sübut etmir və köhnə ilkin yükləmə uğursuzluğu daha yeni formatı məhkum etmir.

• Proksiyə toxunmazdan əvvəl artefaktın nəslini müəyyən edin.
• Uğursuzluğun tuneldən əvvəl və ya onun içində baş verdiyini müəyyənləşdirin.
• Ön hissənin nəyi sonlandırdığını təsdiqləyin: HTTP, TCP axını və ya UDP.
• Yeni verilmiş profili siyasət dəyişməz qalmaqla doğma son nöqtə qarşısında sınaqdan keçirin.