OpenVPN və ya IKEv2: protokol seçməzdən əvvəl dörd yoxlama

OpenVPN ilə IKEv2 arasındakı seçim adətən protokol sualı kimi müzakirə olunur və bu yanaşma qərarı israf edir. Qərarı verən odur ki, serveriniz və cihazlarınız eyni tam profili dəstəkləyirmi və bu profil şəbəkələr arasında keçid tərzinizə tab gətirirmi. İki yığın bir-birinə çevrilmir: OVPN faylı fərqli sintaksisli IKEv2 profili deyil. Ardıcıllıqla aparılan dörd yoxlama sualı hər hansı funksiya cədvəlindən daha sürətli cavablandırır.

Müştəri olmadıqda müzakirə bitir

Windows və macOS IKEv2 müştərisi ilə gəlir, ona görə orada IKEv2 profili yerləşdirmək əlavə heç nəyə başa gəlmir və əməliyyat sisteminin artıq təqdim etdiyi təminat seçimlərini miras alır. OpenVPN eyni maşınlarda quraşdırılmalı, yenilənməli və dəstəklənməli üçüncü tərəf müştərisi deməkdir və həmin müştəri profilin istifadə etdiyi hər seçimi qəbul etməlidir. Başqa heç nəyi müqayisə etməzdən əvvəl əhatə etməli olduğunuz platformaları sayın, çünki işlək müştərisi olmayan platforma ümumiyyətlə müqayisə nöqtəsi deyil.

Windows-da bir əmr artıq mövcud olan profilləri sadalayır və hər birinin hansı tip olduğunu göstərir. Çap etdiyi ad sonrakı yoxlamaların istifadə etdiyi addır.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

Müştəri quraşdırma təklifi həmin platformalarda OpenVPN sütunu üçün real cavabdır və o, protokol məhdudiyyəti deyil, yerləşdirmə tapşırığıdır. Heç bir variant etimad yoxlamalarını, kimlik təsdiqini və ya texniki xidməti aradan qaldırmır. Profillərin necə paylandığını, etimad məlumatlarının necə yeniləndiyini və itirilmiş cihazın necə çıxarıldığını öhdəlik götürməzdən əvvəl soruşun. Sadə quraşdırma həftə sonu heç kimin işlətmək istəmədiyi bərpa prosesini də gizlədə bilər.

Mobillik protokol vədi deyil, birgə ayardır

IKEv2 MOBIKE-dən istifadə edə bilər, o şərtlə ki, hər iki tərəf onu dəstəkləsin və aktivləşdirsin; bu, müştəriyə ünvanı dəyişərkən tunelini saxlamağa imkan verir. RFC 4555 bu uzantını müəyyən edir və şərti ifadə vacibdir: qabiliyyəti nəzərə almayan server bunun əvəzinə yenidən razılaşır. Nəticə fayl ötürülməsində eyni görünə, canlı zəngdə isə tamamilə fərqli ola bilər.

Həqiqətən əhəmiyyət verdiyiniz keçidi, izləyə biləcəyiniz bir şey işləyərkən sınaqdan keçirin. Windows-da ping -t <internal-host> işlətməyə davam edin və ya adi ping başqa yerdə, sonra Wi-Fi-dən mobil şəbəkəyə keçin və fasilələri izləyin. MOBIKE nasazlığı müştəri jurnalında sakit ünvan yeniləməsi kimi deyil, tam yenidən autentifikasiya kimi görünür. Ölçdüyünüz şey tunelin dəyişikliyə tab gətirib-gətirməməsidir, protokolun dəstəyi reklam edib-etməməsi deyil.

OpenVPN müştəriləri öz platforma davranışlarına və profil taymerlərinə görə yenidən qoşulur, ona görə eyni sınaq fərqli fasilə forması yarada bilər. Protokolun üzərindəki etiketi deyil, istifadəçiləriniz üçün əhəmiyyətli olan hadisəni müqayisə edin.

Etimad məlumatları yığına deyil, xidmətə aiddir

Sertifikatlar və digər giriş qurğuları bağlantını sonlandıran xidmətə aiddir. Bir müştəridəki parol tələbi digəri ilə uyğunluq barədə heç nə demir və fərqli şlüz qarşısında işləyən profil bu şlüz barədə heç nə demir. İki yığını müqayisə edərkən server kimliyi qaydalarını toxunulmaz saxlayın. Nasazlığı müəyyən etməzdən əvvəl protokolu dəyişmək adətən ikinci uyğunsuz profil yaradır.

Protokollardan birini günahlandırmazdan əvvəl müştərinin təqdim edəcəyi etimad məlumatını yoxlayın, çünki vaxtı keçmiş və ya səhv verilmiş sertifikat hər ikisində eyni şəkildə uğursuz olur. Aşağıdakı çıxış şəxsi açarı oxumadan subyekti, verəni və etibarlılıq tarixlərini göstərir.

openssl x509 -in client.crt -noout -subject -issuer -dates

Şirkət bağlantısı üçün şirkətin dərc etdiyi üsuldan istifadə edin və müqayisəni təcrübə kimi görməyi dayandırın. İkisini özünüz üçün müqayisə edirsinizsə, əvvəlcə hər iki variantın bir şlüzdə bitib-bitmədiyini yoxlayın, çünki bu tək detal nəticənizin nə qədərinin protokolla bağlı olduğunu həll edir. Etimad məlumatını adlandıran rədd etmə etimad məlumatı problemidir və heç bir protokol dəyişikliyi onu düzəltməyəcək.

Tunelin həqiqətən nəyə marşrutlaşdırdığını yoxlayın

Qoşulduqdan sonra lazım olan marşrutun mövcud olduğunu və adların həll olunduğunu təsdiqləyin. Daxili resurslar üçün mövcud olan profil adi gəzintini dizayn üzrə yerli yolda buraxa bilər və bu, nasazlıq deyil, siyasət qərarıdır. Əhəmiyyətli olan komandanızın istifadə etdiyi təyinatların tuneldən keçərək əlçatan olub-olmamasıdır.

Windows-da iki əmr marşrutu və ad axtarışını əhatə edir. Linux ekvivalentləri bunlardır: ip route show default və resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Qalxıb faydalı heç nəyi marşrutlaşdırmayan tunel, profil xidmətlər arasında köçürüldükdə tez-tez rast gəlinən nəticədir və ümumi bağlantı testi bunu göstərməyəcək, çünki interfeys işləkdir. İstifadəçilərinizin ilk açdığı resursu sınayın, istənilən yolun çata biləcəyi açıq ünvanı deyil. Ad açıq ünvana həll olunursa, marşrut isə tunelin içinə işarə edirsə, DNS cavabı və marşrut fərqli qərarlara aiddir və hər ikisi düzəldilməlidir.

Yoxlamalardan sonra texniki xidməti çəkin

Protokollardan heç biri mücərrəd şəkildə daha çox saxlanıla bilən deyil. Texniki xidmət şlüzü kimin idarə etdiyindən, profillərin cihazlara necə çatdığından və itirilmiş cihazın girişi nə qədər tez itirdiyindən asılıdır. Sadə son nöqtə müştərisi idarə edilməsi daha çətin serverin qarşısında dura bilər və əksi də olur. Komandanızın onu quran şəxs getdikdən sonra hansını işlək saxlaya biləcəyini soruşun.

İşi əhatə edən dəstəklənən bağlantını seçin, sonra onu funksiya siyahısına deyil, həqiqətən lazım olan girişə qarşı sınayın. Hər variantın hansı şlüzdə bitdiyini qeyd edin, çünki iki fərqli şlüz müqayisəni protokollar qədər marşrutlar barədə edir. Dörd yoxlamanı həqiqətən daşıyacağınız cihazda təkrarlayın və onun üzərində keçən profili saxlayın.