AWS Client VPN: server sertifikatı və müştəri sertifikatının rolu

Client VPN son nöqtəsinə həmişə TLS server sertifikatı lazımdır. Bu, idarə olunan son nöqtənin müştəri qoşularkən təqdim etdiyi şəxsiyyətdir. Bu, qarşılıqlı autentifikasiya istifadə edildikdə ayrı-ayrı müştərilərin təqdim etdiyi sertifikatlardan fərqli obyektdir. Bu ikisini qarışdırmaq, digər cəhətdən düzgün ACM konfiqurasiyasının ilk qoşulmada yenə də uğursuz olmasının ən geniş yayılmış səbəbidir.

Aşağıda konsoldan bayıra doğru, əlaqənin həqiqətən keçdiyi ardıcıllıqla bir baxış verilir.

İki rol, bir son nöqtə

Son nöqtənin server şəxsiyyəti və istəyə bağlı olaraq müştərilərin şəxsiyyətini yoxlamaq üsulu var. Bunlar ayrıca konfiqurasiya edilir. Biri müştərinin xidmətə etibar edə bilib-bilmədiyini müəyyən edir; digəri xidmətin müştərini qəbul edib-etmədiyini müəyyən edir.

Cədvəli bir sertifikat kimi deyil, üç müstəqil tələb kimi oxuyun. Server sertifikatı və onun şəxsi açarı xidmətdə qalır. Müştəri sertifikatı və ona uyğun şəxsi açar cihazda olur. CA materialı yoxlayıcının zəncirı yoxlamaq üçün istifadə etdiyi şeydir. Yalnız orta sətir noutbuka aiddir.

ACM server sertifikatı nə edir

Son nöqtəni yaradarkən server sertifikatı ACM-də son nöqtə ilə eyni regionda mövcud olmalıdır. Konsol ARN tələb edir və həmin ARN orada həll olunmalıdır. ACM domen təsdiqi ilə əldə etdiyiniz sertifikatı və ya açarı və zənciri ilə birlikdə idxal etdiyiniz sertifikatı saxlaya bilər. Hər ikisi bu rolda işləyir; onlar yenilənmə və şəxsi açarın kimdə olması ilə fərqlənir.

Sertifikatı kimin yeniləyə bilməsinə uyğun təminat yolunu seçin, təsadüfən düzgün görünən fayl yaradan yolu deyil.

Qarşılıqlı autentifikasiya nə əlavə edir

Sertifikata əsaslanan müştəri autentifikasiyasını seçmək ikinci sualı əlavə edir: hansı müştərilər ümumiyyətlə qoşula bilər. Hər müştəri öz sertifikatını təqdim edir və uyğun şəxsi açarı saxladığını sübut edir. Məhz ayrı-ayrı şəxsiyyətlər sonradan seçmə ləğvini mümkün edir. Bir müştəri açarını hər cihaza köçürmək bu xassəni səssizcə atır, hətta server sertifikatı qüsursuz əldə edilsə belə.

Son nöqtənin autentifikasiya üsulu seçimdir, ümumi tələb deyil.

Active Directory və federativ autentifikasiya eyni suala başqa vasitələrlə cavab verir. Qarşılıqlı sertifikat resepti həmin yerləşdirmələr üçün avtomatik giriş dizaynı olmur və serverin TLS yoxlaması istifadəçinin necə buraxılmasından asılı olmayaraq qalır.

Niyə eyni CA ARN açar paylaşımı deyil

AWS sənədləşdirir ki, server və müştəri sertifikatları eyni CA tərəfindən verildikdə server sertifikatının ARN-i müştəri sertifikatının seçilməsi üçün də istifadə oluna bilər. O cümlə son nöqtənin yoxlama zamanı hansı zəncirə etibar etdiyi barədədir. O, müştərilərə serverin şəxsi açarını işlətməyi demir. Noutbuk yenə də öz müştəri sertifikatına və öz uyğun açarına ehtiyac duyur.

Müştərinin CA-sı başqa verən olduqda, sənədləşdirilmiş yol həmin CA-nı ACM-ə idxal edib müştəri rolu üçün seçməkdir.

Nasazlığı mərhələyə qaytarın

Nəyisə dəyişməzdən əvvəl hansı mərhələnin uğursuz olduğunu müəyyənləşdirin. Müştəri son nöqtəni rədd edirsə, şübhəli server ARN-i və ya onun zənciridir. Son nöqtə müştərini rədd edirsə, müştəri sertifikatına, onun verəninə və seçilmiş autentifikasiya üsuluna baxın. Tunel qalxır və trafik hələ də uğursuz olursa, siz artıq sertifikatları keçmisiniz.

Bir dəfəyə bir obyekt dəyişdirin, çünki hər iki ucu birlikdə dəyişmək başladığınız qeyri-müəyyənliyi yenidən yaradır.

Həmçinin konkret rol üçün xidmətin dəstəklədiyi açar alqoritmlərini və tələb olunan genişləndirmələrini yoxlayın. İctimai vebsaytı qane edən sertifikat Client VPN-in bütün şəxsiyyət tələblərinin yerinə yetirildiyini sübut etmir.

Hər sahənin hansı ARN saxladığını, müştəri sertifikatını hansı CA-nın verdiyini və son nöqtənin həqiqətən hansı autentifikasiya üsulunu işlətdiyini yazın. Üç sətir qeyd növbəti yenilənməni araşdırma deyil, tapşırıq edir.