Azure P2S VPN statik IP: müştəri ünvanı niyə dəyişir

Hər Azure point-to-site müştərisi autentifikasiyadan keçdikdə hovuzdan ünvan alır və onu yalnız həmin bağlantının ömrü boyu saxlayır. Nə rezervasiya cədvəli, nə istifadəçi üzrə xəritələmə, nə də “bu şəxsə həmişə 172.16.0.10 ver” mənasını verən gateway parametri var. Məhz bu tək mexanizm insanların sonralar qarşılaşdığı iki simptomu izah edir: əvvəllər uyğun gəldiyi istifadəçiyə artıq uyğun gəlməyən NSG qaydası və heç kimin qəsdən əlavə etmədiyi maşını səssizcə qəbul edən icazə siyahısı. Qaydanı daha ağıllı IP qaydası ilə əvəz etmək heç birini düzəltmir, çünki qaydanın adlandırdığı şey sizin nəzarət etmədiyiniz cədvəl üzrə yenidən təyin edilir.

Hovuz tutumdur, kimlik deyil. O, paralel tunellərin unikal ünvanlar alması üçün mövcuddur və icarə bitdiyi anda onları təkrar istifadəyə qaytarır. Bu aydın olanda faydalı sual “bu müştərini necə sabitləyim” olmaqdan çıxıb “gateway-in təkrar istifadəyə qaytarmayacağı nəyə qarşı qayda yaza bilərəm” olur.

Gateway müştəri qoşulanda əslində nə edir

Gateway konfiqurasiya edilmiş müştəri ünvan hovuzunu saxlayır və ona icarə cədvəli kimi yanaşır. Qoşulma zamanı növbəti boş ünvanı, praktikada mövcud olan ən aşağı ünvanı götürür və müştəri bağlantını kəsənə və ya icarə bitənə qədər onu tunel adapterinə təyin edir. Qərarı sıra verir, kimlik yox: sakit dövrdən sonra birinci qoşulan, o anda təsadüfən boş olan ən aşağı ünvanı alır.

Hovuzun ölçüsü davranışı gizlədir. Test edənlərin sayından bir-iki ünvan böyük laboratoriya hovuzu determinist görünür, çünki eyni noutbuk hər səhər eyni sıra ilə qoşulmağa meyllidir. Üçüncü maşın əlavə edin, hovuzun ölçüsünü dəyişin və ya sessiyanı nahar boyu açıq saxlayın — naxış pozulur. Ünvan heç vaxt sabit deyildi; sabit olan növbə idi.

Point-to-site konfiqurasiyasındakı hər hansı dəyişiklik icarə məkanını da sıfırlayır. Fərqli autentifikasiya növü, ölçüsü dəyişdirilmiş hovuz, yeni hovuz diapazonu və ya sökülüb yenidən qurulan gateway bütün müştəriləri köhnə ünvanlarına artıq uyğun gəlməyən hovuza qaytarır. Bu dəyişikliyin heç biri NSG-nizə toxunmur, buna görə də pozulma kortəbii görünür.

Bunu təxminən bir dəqiqə ərzində izləyə bilərsiniz. Qoşulun, müştərinin bağlantı təfərrüatlarında tunel ünvanını qeyd edin, bağlantını kəsin, ikinci maşını qoşun, sonra birincini yenidən qoşun. Aldığınız ünvan ikinci maşının nəyi saxlamasından asılıdır və heç bir portal parametri əvvəlkini tələb üzrə bərpa etməyəcək.

Müştəri IP-sinə əsaslanan NSG əslində qoşulma sırasına dair qaydadır

İnsanların ilk yazdığı qayda aşkar olanıdır: idarəetmə VM-inin NIC-i və ya onun subneti üzərində, mənbə kimi VPN müştərisinin daxili ünvanı olan giriş qaydası. Qısadır, yazıldığı gün testi keçir və hovuzda birdən çox boş ünvan olanda dərhal uğursuz olur.

Bundan iki uğursuzluq rejimi çıxır və yalnız biri xəta kimi görünür. Qanuni istifadəçi rədd edilir, çünki qaydanın adlandırdığı ünvanı hazırda başqası saxlayır və bu, narahat edici dəstək müraciəti kimi gəlir. Ya da nəzərdə tutulmayan istifadəçiyə icazə verilir, çünki qaydanın hələ də etibar etdiyi ünvanı miras alıblar və bu, kimsə girişi audit edənə qədər heç nə kimi gəlmir.

Qayda icarəni izlədiyi üçün effektiv siyasət “birinci qoşulan idarəetmə girişi alır” kimi oxunur. Bu, niyyət kimi bəzədilmiş qoşulma sırasının təsviridir və heç bir qayda gigiyenası onu niyyəti ifadə etməyə məcbur etmir.

Müştəri icarəsi və gateway ünvanı fərqli obyektlərdir

Qarışıqlığın çoxu bir sözdən gəlir. Gateway-in nisbətən sabit publik IP-si var; müştərilərin hovuzdan aldığı şəxsi ünvanlar isə sabit deyil. Zona-redundant olmayan VPN gateway üçün publik IP dinamik ayrılır, lakin ölçü dəyişikliyindən, sıfırlamadan və rutin texniki xidmətdən sonra da qalır — yalnız gateway özü silinib yenidən yaradılanda dəyişir. Zona-redundant və zonal gateway SKU-ları Standard SKU publik IP istifadə edir və bu ayrılma statik olmalıdır.

Bu sabitlik yerli peer-in konfiqurasiyasında ehtiyac duyduğu şeydir və fərdi müştərinin identifikasiyası barədə heç nə demir. Tərəfdaş hansı ünvanı görəcəklərini soruşanda cavab site-to-site altında gateway-in publik IP-si və ya ortaq NAT diapazonudur — heç vaxt noutbukun tunel icarəsi deyil.

Qrup hovuzları sizə qayda yazmağa dəyər diapazon verir

Virtual WAN point-to-site istifadəçi qruplarını dəstəkləyir və hər qrupa öz müştəri ünvan hovuzu təyin edilə bilər. Üzvlük kimliklə müəyyən edilir, ona görə də müştərinin düşdüyü diapazon proqnozlaşdırıla bilən olur: əməliyyatlar bir diapazonda, podratçılar başqasında, və diapazon firewall və ya NSG qaydasının təxmin etmədən adlandıra biləcəyi şeydir.

Yaranan qayda dəsti nəzərdən keçirilə bilən formaya malikdir:

• hər auditoriya üçün bir hovuz, işçi sayına deyil, pik paralel sessiyalara görə ölçüləndirilmiş;
• qrup üzvlüyü kimliklə idarə olunur, hər kəs qoşulanda qaydaları redaktə etməklə deyil;
• NSG və ya Azure Firewall qaydaları hovuz diapazonlarına görə yazılır, heç vaxt fərdi icarələrə görə deyil;
• heç vaxt diapazon paylaşmamalı olan auditoriyalar üçün ayrı hub və ya gateway.

Bütün hovuzu icazə siyahısına salmaq dürüstdür, amma kobuddur: həmin diapazondakı hər qoşulmuş müştəri eyni girişi alır. Bu, nəzərdən keçirmə zamanı kəşf etmək əvəzinə yüksək səslə deməyə dəyər siyasət qərarıdır. Hələ də hər şəxs üzrə cavab tələb edən hər şey paket filtrinə deyil, rol təyinatları vasitəsilə resursa aid olur.

Yerləşdirmə Virtual WAN-a keçə bilməyəndə

Bir çox gateway adi VPN gateway olaraq qalır və Virtual WAN-a keçid təsadüfi dəyişiklik deyil. Praktik cavab istifadəçi üzrə qərarı paket filtrindən istifadəçinin kim olduğunu artıq bilən bir şeyə köçürməkdir.

Resurs səviyyəsində kimlik ən ucuz variantdır. Storage, SQL və Key Vault hamısı istifadəçi və ya qrup üzrə rol təyinatları ilə Entra ID autentifikasiyasını dəstəkləyir, ona görə VPN yalnız şəbəkə əlçatanlığını sübut etməlidir. Adlandırılmış hesabları olan jump host inzibati iş üçün eyni işi görür, çünki host insanı qeydə alır və tunel sadəcə paket daşıyır. Müştəriləri DNS-də qeydiyyata almaq və nömrə əvəzinə adı icazə siyahısına salmaq qaydanı bir qat yuxarı aparır. Tətbiq səviyyəsində kimlik — sertifikat subyekti, token iddiası, qrup üzvlüyü — qərar vermək tələb olunan şey şəbəkə deyil, tətbiq olduqda işləyir.

Sabit mənbə ünvanında isə israr edən tərəfdaş üçün cavab müəyyən peer prefiksi ilə site-to-site və ya ExpressRoute-dur. Onlar peer prefiksini icazə siyahısına salır, onların tərəfində görünən ünvan gateway-ə aiddir və kimsə noutbuku yenidən başladanda dəyişmir.

Başqa icazə siyahısını redaktə etməzdən əvvəl hovuzu yoxlayın

İki hovuz xassəsi insanların müştərinin üzərinə atdığı davranışın çoxuna səbəb olur. Çox kiçik hovuz icarələri tez təkrar istifadəyə qaytarır, ona görə ünvanlar daim yer dəyişən kimi görünür və ünvana əsaslanan hər qayda dizaynca etibarsız görünür. Yerli diapazonlarla və ya virtual şəbəkə məkanı ilə üst-üstə düşən hovuz isə heç bir firewall qaydasının düzəldə bilməyəcəyi marşrut qeyri-müəyyənliyi yaradır.

Qaydaya toxunmazdan əvvəl üç şeyi bir səhifədə toplayın: point-to-site hovuzu, virtual şəbəkə ünvan məkanı və yerli diapazonlar. Onlar üst-üstə düşməməlidir və hovuzda hər paralel müştəri üçün yer, üstəgəl yenidən qoşulmalar üçün ehtiyat olmalıdır.

Sonra dövrü bu sıra ilə bağlayın:

• İki maşından hər iki sıra ilə qoşulun və ünvanları müqayisə edin; əgər onlar yer dəyişə bilirsə, ünvana əsaslanan heç bir qayda təhlükəsiz deyil.
• Gateway-in Virtual WAN olub olmadığını yoxlayın; əgər belədirsə, hər ünvan üçün qaydalar yerinə qrup hovuzlarından istifadə edin.
• Qayda yanlış şəxsə uyğun gələndə nə baş verdiyini soruşun; cavab giriş insidentidirsə, nəzarəti kimliyə köçürün.
• Hansı diapazonun hansı qrupa aid olduğunu NSG tərifləri ilə eyni repoda qeyd edin.
• Hovuz, autentifikasiya və ya gateway dəyişikliyindən sonra yenidən test edin, çünki bu dəyişikliklər xəritələməni elan etmədən yenidən yazır.