FortiGate Azure açar yeniləməsi: peer SA təklifi yerli siyasətə uyğun deyil

Tunel qalxdı, trafik keçdi və sonra jurnal deyir peer SA proposal not match local policy. Əksər insanlar bu sətri iki konfiqurasiyanın heç vaxt uyğunlaşmadığına sübut kimi oxuyur. Adətən bu daha dar bir məna daşıyır: onlar ilk CHILD SA üçün uyğunlaşdı və ilk yenilənmədə uyğunlaşmağı dayandırdı, çünki ilk assosiasiya sonrakıların yerinə yetirdiyi mübadiləyə heç vaxt ehtiyac duymadı. Bu fərq hara baxacağınızı müəyyən edir.

İlk CHILD SA miras alır, sonrakılar razılaşdırır

IKEv2-də ilkin CHILD SA IKE_AUTH zamanı yaradılır və onun açarları IKE SA açar materialından çıxarılır. Həmin anda ayrıca Diffie-Hellman mübadiləsi yoxdur, ona görə də bir peer-in qəbul edə bilmədiyi PFS qrupu sadəcə hələ sınaqdan keçirilmir. Tunel sağlam görünür, çünki sonradan uğursuz olacağınız tələb heç vaxt yoxlanmayıb.

CHILD_SA açar yeniləməsi fərqli mesaj ardıcıllığıdır. PFS konfiqurasiya edildikdə peer-lər təzə açar mübadiləsi aparır və hər iki tərəfin qəbul etdiyi qrup, həmçinin yeni assosiasiya üçün ESP təklifi barədə razılaşmalıdırlar. Uyğunsuzluğun göründüyü an elə budur və buna görə xəta marşrutu deyil, təklifi adlandırır.

Yəni “dünən işləyirdi” sizə təklif haqqında heç nə demir. Bu, ilkin mübadilənin uğurlu olduğunu deyir, bunu siz artıq bilirdiniz.

Uğursuz mübadiləni oxuyun, ilk ping-i deyil

Heç nəyi dəyişməzdən əvvəl hər iki tərəfdən uğurlu IKE autentifikasiyasını, ilkin CHILD SA-nı və uğursuz əvəzləməni toplayın. Sonra əməliyyatı dəqiq adlandırın: IKE SA açar yeniləməsi, IKE yenidən autentifikasiyası və CHILD SA açar yeniləməsi üç fərqli hadisədir və “faza 2” söhbətdə hamısını əhatə edir.

Aşağıdakı sahələri uğursuz olan bağlantı üçün müqayisə edin, ümumiyyətlə tunel üçün deyil.

FortiGate-də həmin tunel üçün faza-2 təklifini, PFS parametrini və qəbul edilmiş DH qruplarını açın. Yüklənmiş dəyərləri əvvəllər qurulmuş bağlantıdan çıxarmaq əvəzinə oxuyun. GUI səhifəsinin ekran görüntüsü işləyən konfiqurasiyadan zəif sübutdur, çünki ikisi yeniləmədən sonra fərqlənə bilər. Dəyişdirdiyiniz bölməni ixrac edin və biletlə birlikdə saxlayın.

Azure-un standart siyasəti hələ də siyasətdir

Bağlantıya fərdi siyasət əlavə edilməməsi Azure-un heç bir siyasət tətbiq etməməsi demək deyil. Bağlantı şlüzun standart təklif dəstinə qayıdır; bu dəst sizin FortiGate təklif etdiyindən geniş və ya dar ola bilər. Əgər iki dəst IKE üçün üst-üstə düşürsə, amma PFS ilə ESP üçün düşmürsə, tam olaraq bu uğursuzluq nümunəsini alırsınız.

Bu yalnız-oxuma görünüşü sirləri açmadan həqiqətən əlavə edilmiş siyasəti göstərir:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Real resurs adlarınızı istifadə edin. Açıq siyasət lazım olduqda onu bağlantı resursunda təyin edin. Bu, şlüz səviyyəsində açar deyil və eyni şlüzdəki digər tunellərə səssizcə tətbiq olunmur.

Portalda həmin bağlantının Configuration səhifəsi fərdi IPsec/IKE siyasətinin yerləşdiyi yerdir. Microsoft-un fərdi siyasət təlimatı dəstəklənən parametrləri və SKU tələblərini sadalayır. Azure hər bağlantı üçün bir tam kombinasiya götürür, ona görə IKE sahələrini və IPsec sahələrini birlikdə göstərirsiniz, bir-bir deyil.

PFS tələbdir, çevriləcək açar deyil

Əgər təhlükəsizlik bazanız PFS tələb edirsə, həll hər iki tərəfdə hər iki peer-in qəbul etdiyi və uyğun siyasətlə ifadə olunan qrupdur. Xəta yox olsun deyə PFS-i söndürmək saxlamaq istədiyiniz təhlükəsizlik xassəsini dəyişir və adətən sonra başqa uyğunsuzluq kimi qayıdır.

Azure-a xas bir tələ: ESP üçün GCM seçdikdə şifrələmə və bütövlük seçimləri eyni GCM alqoritmini və açar uzunluğunu adlandırmalıdır. GCM şifrəsini ayrı bütövlük alqoritmi ilə qarışdırmaq xidmətin rədd etdiyi kombinasiya yaradır; bu, siyasəti diqqətlə oxuyana qədər peer uyğunsuzluğu kimi görünür.

Hər iki ucun dəstəklədiyi və tələbinizin icazə verdiyi ən güclü kombinasiyanı seçin, sonra onu dəyişiklik qeydinə yazın. Növbəti şəxs işləyən tunelin xatirəsi ilə deyil, həmin qeydlə müqayisə edəcək. Ora PFS qrupunu və ESP təklifini də yazın, təkcə siyasətin adını deyil. Sonra kimsə auditin niyə uğursuz olduğunu və ya yeniləmənin niyə yavaş olduğunu soruşduqda, həmin sətir hər iki suala cavab verir.

Uğursuz olan mübadiləni yoxlayın

Dəyişikliyi bərpa yolu ilə planlaşdırın, çünki siyasəti redaktə etmək düzəltməyə çalışdığınız tuneli kəsə bilər. Trafik qayıtdıqdan sonra CHILD_SA yenilənməsini gözləyin və ya tetikləyin və yeni assosiasiyanın nəzərdə tutulan PFS qrupu ilə qurulduğunu təsdiqləyin. Sonra tətbiq trafikinin onun üzərindən davam etdiyini təsdiqləyin.

İki yanlış izi adlandırmağa dəyər. SA ömürləri yerli spesifikasiyalardır, ona görə bərabər olmayan dəyərlər normaldır və onları dəyişmək yalnız problemin nə vaxt görünəcəyini dəyişir. DPD peer-in diri olub-olmadığını aşkarlayır; onun fasiləsini artırmaq ESP və ya PFS seçimlərini uyğunlaşdırmır.

Razılaşdırılmış nəticəni və dəyişiklikdən sonra növbəti hadisəni qeyd edin. Əgər bağlantı indi IKE autentifikasiyası tamamlanmadan uğursuz olursa, sizə elə indicə redaktə etdiyiniz IKE parametrlərinə baxırsınız, orijinal CHILD yenilənmə nasazlığına deyil.