Azure VM-də RRAS dəstəklənmir: dizayndan əvvəl yoxlayın
Windows Server Azure-da işləyir, lakin Microsoft-un dəstək təlimatı RRAS-ı Azure VM-lərində dəstəklənməyən kimi sadalayır. VPN qurmazdan əvvəl bu sərhədi yoxlayın.
Portalı açır, Windows Server 2022-ni alt şəbəkəyə yerləşdirirsiniz və Remote Access rolu problemsiz quraşdırılır. Bu ardıcıllıq quraşdırıcının işlədiyini sübut edir, Microsoft-un bu konfiqurasiyanı dəstəklədiyini yox. Azure virtual maşınları üçün dərc edilmiş server proqram təminatı dəstəyi təlimatı RRAS-ı Azure VM-lərində dəstəklənməyən Windows Server funksiyaları sırasına daxil edir və bu, nasazlıqların aradan qaldırılması detalları deyil, arxitektura qərarıdır. Qalxan tunel yerləşdirməni dəstək sərhədinin içərisinə keçirmir.
Aşağıdakı icmal dəstək səhifəsindən başlayır, sonra tələblərə və əvəzetmə variantlarına doğru genişlənir.
Laboratoriyada deyil, dəstək səhifəsindən başlayın
Hər hansı ölçü seçməzdən əvvəl Azure VM dəstək təlimatını oxuyun. O, Windows Server-i vahid fərqləndirilməmiş blok kimi qəbul etmək əvəzinə dəstəklənən məhsulları, rolları və funksiyaları ayırır. Nəzərdə tutulan iş yükünün həqiqətən hansı sətirə düşdüyünə diqqət yetirin, çünki konsolda əlaqəli görünən iki komponent fərqli sətirlərdə ola bilər.
Səhifə açıq ikən istinadı dizayn sənədinə yazın. Dəstək statusu mənbəyi olan bir faktdır və onu sitat gətirə bilməyən dizayn baxışı demosu olan şəxs tərəfindən məğlub ediləcək.
ƏS dəstəyini rol və funksiya dəstəyindən ayırın
Həmin təlimat Network Policy and Access Services-i dəstəklənən rollar arasında sadalayır, RRAS-ı isə ayrıca dəstəklənməyən kimi göstərir. Bu iki qeyd fərqli şeyləri təsvir edir və onları “uzaqdan giriş dəstəklənir” kimi birləşdirmək layihənin səhv oxunuş əsasında təsdiqlənməsi yoludur. Əməliyyat sisteminin dəstəklənməsi öz sətri olan funksiya haqqında heç nə demir.
Məhdudiyyət bəzən sitat gətirildiyindən də dardır. Söhbət həmin funksiyanın Azure VM daxilində işləməsindən gedir; bu, xüsusi şəbəkənin Azure-a qoşula bilməyəcəyi demək deyil və RRAS-ın hər yerdə dəstəklənmədiyini də bildirmir. Paketləri düzgün yönləndirən köhnə laboratoriya paketlər barədə sübutdur, dəstək bəyanatı barədə deyil.
Layihənin qalan hissəsi üçün bu iki sualı ayrı saxlayın: işləyirmi və dəstəklənirmi. Hər biri üçün fərqli cavablara və bəzən fərqli məsullara ehtiyacınız olacaq.
Dizaynın həqiqətən nə etməli olduğunu yazın
Əvəzedici seçməzdən əvvəl sayt siyahısını məhsulun ölçülə biləcəyi tələblərə çevirin:
- Filial cihazlarının artıq danışdığı tunel protokolları və hər hansı saytın dinamik marşrutlaşdırmaya ehtiyacı olub-olmadığı.
- Uzaq prefikslər, o cümlədən marşrutlaşdırma deyil, tərcümə tələb edən üst-üstə düşən ünvan məkanı.
- Azure ilə marşrut mübadiləsi və hər marşrut cədvəli qeydinin kimə aid olduğu.
- Ən işlək saatın davam etdirməli olduğu ötürmə qabiliyyəti və bağlantı sayları.
- Sayt sahiblərinin razılaşdığı nasazlıq keçidi davranışı, yalnız qura biləcəyiniz deyil.
NAT atlanan və sonra bütün dizaynı həll edən maddədir. IPsec qura bilən cihaz yenə də ünvanları əvəz etdiyi RRAS yerləşdirməsindən fərqli tərcümə edə bilər, bu da filialın mənbə ünvanları kimi gördüyünü və qeydlərinizin nə yazdığını dəyişir.
Siyahını şəbəkə sahiblərinə aparın və hər hansı məhsul müzakirəsindən əvvəl təsdiqləyin. Qeyri-müəyyən tələblər hər satıcı müqayisəsini zövq mübahisəsinə çevirir.
Əvəzediciləri həmin tələblərə görə qiymətləndirin
Azure-un idarə olunan bağlantı xidmətləri və satıcı tərəfindən dəstəklənən şəbəkə virtual cihazları eyni siyahıya görə qiymətləndirilməlidir. IPsec-i sonlandıra bildiyi üçün hər hansı birini RRAS VM-in birbaşa ekvivalenti hesab etməyin: NAT modeli və marşrut sahibliyi və yüksək əlçatanlıq dizaynı mövcud saytların necə qoşulduğunu və cavablarının hara qayıtdığını həll edir. Hər namizədi kağız üzərində siyahıya görə qiymətləndirin və hansı tələblərdə uğursuz olduğunu yazın, çünki sonradan seçimi nəzərdən keçirilə bilən edən həmin qeyddir.
İki cihaz VM-nin qarşısındakı yük balanslaşdırıcı tək başına yüksək əlçatanlıq deyil. O, ön hissə verir, sinxronlaşdırılmış tunel vəziyyəti yox, və hər sessiyanı atan nasazlıq keçidi kimsə tərəfindən qəsdən verilməli dizayn seçimidir. Cihaz satıcısından dəstəklənən HA modelinin nə olduğunu və saytlara vəd edilən əlçatanlığa uyğun olub-olmadığını soruşun. O saytlar ondan asılı olmazdan əvvəl nasazlıq keçidini sınaqdan keçirin və hər itirilən sessiyaya sürpriz deyil, tapıntı kimi baxın.
Tələb həqiqətən sadə olduqda — bir sayt, bir prefiks, üst-üstə düşmə yoxdur — idarə olunan xidmət adətən əməliyyat xərci baxımından qazanır. Tərcümə və dinamik marşrutlaşdırma birlikdə iştirak etdikdə cihaz yolu yeganə uyğun variant ola bilər və bu, dəstəklənməyən VM-i saxlamaq əvəzinə daha uzun miqrasiya planlamaq üçün səbəbdir.
RRAS VM artıq işləyirsə
Kəşf onu silmək üçün səbəb deyil. Dəyişikliyi həmin VM-in topladığı asılılıqlar ətrafında planlaşdırın: digər alt şəbəkələrin güvəndiyi marşrutlar, mənbə ünvanlarını gizlədən NAT qaydaları və monitorinqin onun ünvanından gözləməyi öyrəndiyi hər şey. Dəstəklənən hədəf yanaşı dizayn edilib yoxlanılarkən tələb olunan marşrutları və sınaqdan keçirilmiş bərpa yolunu qoruyun.
Dəstəklənmə qabiliyyətini və texniki diaqnostikanı boyu ayrı tapıntılar kimi saxlayın. Dəstəklənməyən bir quruluşun da adi marşrutlaşdırma xətası ola bilər və o xətanın düzəldilməsi onun dəstək statusunu dəyişmir. Hər iki ifadə hesabata aiddir və heç biri digərini ləğv etmir.
İcmalı dəstək istinadını, tələblər siyahısını, seçilmiş əvəzedicini və keçid sırasını qeyd etməklə bağlayın. Auditor və ya yeni komanda üzvü ilk növbədə bu dörd elementi soruşacaq.