Yalnız parolla işləyən OpenVPN profilində hansı CA faylı olmalıdır?

Dörd sualı ardıcıl işləsəniz, CA dialoqu qeyri-müəyyən olmaqdan çıxır. Operator əslində hansı materialı verib, profildə artıq nə var, hansı sahə soruşur və fayl yükləndikdən sonra nə baş verir? Operatorun öz təlimatlarından cavab verə bilmədiyiniz ilk sualda dayanın, çünki oradan təxmin etmək ictimai CA sertifikatının heç vaxt serverdən çıxmamalı olan şəxsi açarla birləşdirilməsinin yoludur.

Sıra vacibdir: son iki sual yalnız hansı materialın mövcud olmalı olduğunu bildikdən sonra məna kəsb edir.

Profilin artıq daşıdığı ilə başlayın

Profili mətn redaktorunda açın və fayl axtarmazdan əvvəl ca blokuna baxın. Operatorun ictimai CA-sını saxlayan daxili ca bloku profilin özünü təmin etdiyini bildirir və hələ də CA faylı istəyən müştəri başqa profil və ya natamam idxal oxuyur ola bilər. Əvəzində profildə yol göstərən ca sətri varsa, bu yol bəzi inteqrasiyalarda müştərinin iş qovluğuna nisbidir, digərlərində isə mütləqdir. Nəyisə dəyişməzdən əvvəl hansı formada olduğunu qeyd edin.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Təqdim olunan paketdə profilin istinad etdiyi faylları yoxlayın: CA sertifikatı, bəzən ayrı müştəri sertifikatı və açarı, bəlkə də tls-auth və ya tls-crypt faylı. Dörd fayla istinad edən profilin iki faylla gəlməsi natamamdır və heç bir sahə göstərmə bunu düzəltmir. Əlinizdə olan sertifikatı əvəz etmək əvəzinə operatordan çatışmayan hissəni istəyin.

Dörd material növünü ayırın

CA sertifikatı serverin şəxsiyyətini yoxlamaq üçün istifadə olunan ictimai materialdır. Müştəri sertifikatı istifadəçini və ya cihazı serverə tanıdır. Şəxsi açar həmin müştəri sertifikatının gizli yarısıdır və heç vaxt CA-nın imza açarı və ya server açarı olmamalıdır. tls-auth və ya tls-crypt materialı idarəetmə kanalını qoruyan ayrıca ortaq sirdir. Bu dördü bir-birini əvəz etmir və CA sahəsini müştəri sertifikatına yönəltmək etibar problemi kimi görünən yoxlama xətası yaradır.

Yalnız parolla autentifikasiya dördündən hansına ehtiyacınız olduğunu dəyişir, mənasını yox. auth-user-pass və remote-cert-tls server ilə müştəri hələ də serveri CA-ya qarşı yoxlayır, buna görə heç bir müştəri sertifikatı olmadıqda belə CA sahəsi görünür. Müştəri sertifikatının da tələb olunub-olunmadığını operatorun siyasəti həll edir və heç bir dialoq bunu sizə deyə bilməz.

Müştərini etibar faylına yönəldin

CA sertifikat faylının özünü seçin, onu ehtiva edən qovluğu yox və müştəri kimliyini saxlayan .p12 paketini yox. Windows-da yol sintaksisi və fayl seçicisi əksər təlimatdakı Linux nümunələrindən fərqli davranır, ona görə quraşdırılmış müştərinin qəbul etdiyini istifadə edin və faylın onu işlədən hesab tərəfindən oxuna bildiyini təsdiqləyin. İcazə problemi ilə çatışmayan fayl dialoqda eyni görünür, lakin fərqli jurnal sətirləri yaradır. Seçdikdən sonra müştərinin seçimi saxladığını təsdiqləmək üçün profil parametrlərini yenidən açın.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

Müştəri daxili blokları dəstəkləyirsə, əl ilə yığılmış profil əvəzinə operatorun daxili profilini üstün tutun. Daxili material profil ilə birlikdə gedir və yenidən idxaldan sağ çıxır, mütləq yol isə profil başqa maşına köçən anda pozulur.

Eyni xətanı deyil, növbəti xətanı oxuyun

Düzgün CA verməyin məqsədi xətanı dəyişməkdir, onu yox etmək deyil. CA yükləndikdən sonra server şəxsiyyəti xətası sertifikatın gözlənilən ada və ya remote-cert-tls gözləntisinə uyğun gəlmədiyini bildirir və bu, parol rəddindən fərqli bir düzəlişdir. Parol rəddi TLS qatının uğur qazandığını və etimad məlumatının səhv olduğunu bildirir. İlk yeni mesajı saxlayın; faydalı olan odur.

Qoşulan lakin heç bir yerə çata bilməyən müştəri etibarı tamamilə keçib və indi marşrutlaşdırma və ya DNS sualı ilə üzləşir.

Həmin dialoqu keçmək üçün yoxlamanı heç vaxt söndürməyin. Hər hansı sertifikatı qəbul edən müştərinin CA istəməyə heç bir səbəbi yoxdur və qurduğu tunel operatorun nəzərdə tutduğu tunel deyil.