İstifadəçini VPN qrupuna əlavə etmək özlüyündə giriş vermir
Qrup üzvlüyü bir şərtdir, icazə deyil. Şlüzün həqiqətən nəyi uyğunlaşdırdığına baxın, qəbul və ya rədd qeydini oxuyun, hər iki nəticəni sınayın.
Hesabı doğru qrupa əlavə etdiniz, giriş uğurlu oldu, amma bağlantı yenə rədd edilir və ya qoşulur və faydalı heç nəyə çatmır. Adi reaksiya nə isə dəyişənə qədər istifadəçini daha çox qrupa əlavə etməkdir və təşkilatlar biletdə tələb olunandan qat-qat artıq icazə verir. Qrup üzvlüyü avtorizasiya qərarına bir girişdir, heç vaxt qərarın özü deyil: şlüz sessiya haqqında bir neçə faktı toplayır, onları sıralanmış siyasətlə uyğunlaşdırır və yalnız sonra sessiyanın nəyə toxuna biləcəyini qərarlaşdırır. Başqa bir şərt yerinə yetməyibsə, qrupu dəyişmək məruz qalmanızdan başqa heç nəyi dəyişmir.
Qrup üzvlüyü şərtdir, icazə deyil
RADIUS-da qrup avtorizasiya atributu kimi gəlir və atributlar sessiyanı təsvir edir, ona icazə vermir. Server Access-Accept və ya Access-Reject ilə cavab verir; qəbul zamanı Filter-Id, Class və ya RFC 2868-dəki tunel atributlarını əlavə edə bilər və qarşı tərəfdəki şəbəkə avadanlığı bunları istehsalçının qərarı ilə şərh edir. Protokolda qrupu tam girişə çevirən heç nə yoxdur; bu uyğunluğu şlüzdə və ya şəbəkə giriş serverində siyasəti quran şəxs yazır və o, bir host qədər dar ola bilər.
Ona görə eyni qrup adı iki sistemdə fərqli davranır. Microsoft NPS şəbəkə siyasətlərini şərtlər, məhdudiyyətlər və parametrlərdən yığır və müəyyən edilmiş ardıcıllıqla qiymətləndirir. OpenVPN Access Server-in öz qrup və giriş qaydası modeli var, icma OpenVPN serveri isə bütün məsələni çox vaxt client-connect skriptinə və ya client-config-dir faylına həvalə edir. Hər biri qrupdan istifadə edir; heç biri digərinin prioritet məntiqini paylaşmır.
Qərar verən uyğunlaşan qaydadır, gözlədiyiniz qrup deyil
Əksər mühərriklər ilk uyğun gələn siyasətdə və ya ən konkret olanda dayanır. Siyasət 3 rədd edirsə və siyasət 7 icazə verirsə, sessiya onu buraxa biləcək qaydaya çatmadan uğursuz ola bilər. Sıralama NPS-də və əksər şəbəkə girişinə nəzarət məhsullarında real parametrdir və illər boyu sürüşür.
Qrupla birlikdə gedən şərtlər işin digər yarısıdır. Cihaz vəziyyəti, autentifikasiya üsulu, MFA tamamlanması, mənbə şəbəkəsi, sertifikat subyekti və ya vaxt pəncərəsi eyni siyasətdə ola bilər. Bunlardan biri yerinə yetməyəndə siyasət uyğunlaşmır, mühərrik aşağı düşür və standart rədd tətbiq olunur. İstifadəçi baxımından qrup görməzdən gəlinmiş görünür; mühərrik baxımından qrupa heç müraciət olunmayıb.
Kataloq detalları eyni illüziyanı yaradır. Windows qrup üzvlüyünə uyğunlaşan siyasət istifadəçi tokenindəki SID-ləri oxuyur və orada yalnız təhlükəsizlik qrupları sadalanır, paylama qrupu heç vaxt görünmür. İstifadəçinin əsas qrupu ayrı sahədə daşınır, sadalanan siyahıda deyil, ona görə həmin qrupa bağlanmış siyasət səssizcə uğursuz ola bilər.
Qrupa toxunmazdan əvvəl qəbul və ya rədd qeydini oxuyun
Əvvəlcə bir sual verin: sorğu ümumiyyətlə avtorizasiya mərhələsinə çatdımı? NPS-də cavab hadisə jurnalındadır: 6272 girişin verildiyini, 6273 rəddi, 6274 isə serverin siyasəti qiymətləndirməzdən əvvəl atdığı sorğunu qeyd edir. Bu üç rəqəm problemi üç fərqli araşdırmaya bölür və yalnız biri qruplarla bağlıdır.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
Jurnal əlçatmaz olduqda serveri birbaşa sorğulayın və qaytardığını oxuyun. Filter-Id və tunel atributları olmayan cavab serverin sessiyanı adi saydığını və şlüzün öz qaydalarını tətbiq etdiyini bildirir. Tətbiq nöqtəsinin həyata keçirmədiyi atributları daşıyan cavab isə başqa nasazlıqdır: avtorizasiya keçdi, nəticəni tətbiq etməli olan cihaz onu görməzdən gəldi.
radtest alice 'password' 10.0.0.5 0 testing123Qaytarılan atributları şlüzün sənədləşdirdiyi ilə müqayisə edin, qrup adının ima etdiyi ilə deyil. Bu müqayisə adətən siyasət problemini tətbiq probleminə qarışmadan ayırır.
Qrup dəyişikliyi geriyə işləmir
Avtorizasiya atributları sessiya autentifikasiya olunanda bir dəfə qaytarılır. Şlüz onları sessiyada saxlayır və hər paket üçün kataloqu yenidən oxumur, buna görə kimsəni qrupdan çıxardıqdan sonra qurulmuş sessiya işləməyə davam edir, yeni sessiya isə uğursuz ola bilər.
Dəyişikliyin qüvvəyə minməsi üçün yeni avtorizasiya qərarı lazımdır, sadəcə yeni açarlar yox. Server RFC 5176 dinamik avtorizasiyanı dəstəkləyirsə, UDP 3799-a Disconnect-Request və ya CoA-Request sessiyanı yenidən qiymətləndirməyə məcbur edir; əks halda müştərini ayırın və yenidən qoşulsun. Yenidən danışıq tunel açarlarını yeniləyir və avtorizasiya nəticəsini adətən toxunmadan qoyur.
Şərti düzəldin, qrupu yox
HanSI siyasətin işə düşdüyünü bildikdən sonra düzəliş adətən kiçik olur: nəzərdə tutulan icazəni kölgədə qoyan rəddi yenidən sıralayın, çatışmayan cihaz və ya MFA şərtini hədəflədiyiniz siyasətə əlavə edin, ya da istifadəçini on başqasını daşıyan qrupa qaldırmaq əvəzinə bir resurs üçün dar qayda yazın.
Qısa dövr dəyişikliyi dürüst saxlayır:
- Rəddi ilkin hesabla təkrar yaradın və heç nəyi dəyişməzdən əvvəl hadisə ID-sini yazın.
- Bir obyekt dəyişdirin, siyasət sırası, tək şərt və ya bir qrup, və hansını dəyişdiyinizi qeyd edin.
- Yeni sessiya açın, icazənin jurnalda göründüyünü və resursun həqiqətən açıldığını təsdiqləyin.
- Hələ də rədd edilməli olan istifadəçini sınayın ki, düzəliş siyasəti təsadüfən genişləndirməsin.
İcazə düzgündürsə və resurs hələ də açılmırsa, problem avtorizasiya keçdiyi anda marşrutlaşdırmaya və ya ad həllinə keçib. Bu iki nasazlığı ayrı saxlayın və növbəti bilet yarım gün yerinə dəqiqələr alacaq.