Azure VM'de RRAS desteklenmiyor: tasarımdan önce kontrol edin

Portalı açarsınız, Windows Server 2022'yi bir alt ağa dağıtırsınız ve Remote Access rolü sorunsuz kurulur. Bu sıra, yükleyicinin çalıştığını kanıtlar, Microsoft'un yapılandırmayı desteklediğini değil. Azure sanal makineleri için yayımlanan sunucu yazılımı destek kılavuzu, RRAS'ı Azure VM'lerde desteklenmeyen Windows Server özellikleri arasında listeler ve bu, sorun giderme ayrıntısı değil mimari bir karardır. Ayağa kalkan bir tünel, dağıtımı destek sınırının içine taşımaz.

Aşağıdaki kılavuz destek sayfasından başlar, ardından gereksinimlere ve değiştirme seçeneklerine doğru genişler.

Laboratuvarda değil, destek sayfasından başlayın

Herhangi bir şeyi boyutlandırmadan önce Azure VM destek kılavuzunu okuyun. Windows Server'ı tek bir farklılaşmamış blok olarak ele almak yerine desteklenen ürünleri, rolleri ve özellikleri ayırır. Planlanan iş yükünün gerçekte hangi satıra girdiğine dikkat edin, çünkü konsolda ilişkili görünen iki bileşen farklı satırlarda olabilir.

Sayfa açıkken atfı tasarım belgesine yazın. Destek durumu kaynağı olan bir olgudur ve onu alıntılayamayan bir tasarım incelemesi, demoya sahip olan tarafından çürütülür.

İşletim sistemi desteğini rol ve özellik desteğinden ayırın

Aynı kılavuz Network Policy and Access Services'i desteklenen roller arasında sayarken RRAS'ı ayrı olarak desteklenmiyor diye listeler. Bu iki kayıt farklı şeyleri anlatır ve onları “uzaktan erişim destekleniyor” diye birleştirmek, bir projenin yanlış okumaya dayanarak onaylanma yoludur. İşletim sisteminin desteklenmesi, kendi satırı olan bir özellik hakkında hiçbir şey söylemez.

Kısıtlama bazen alıntılandığından da dardır. Azure VM'in içinde çalışan o özellikle ilgilidir; özel bir ağın Azure'a bağlanamayacağı anlamına gelmez ve RRAS'ın her yerde desteklenmediğini de söylemez. Paketleri doğru ileten eski bir laboratuvar, paketler hakkında kanıttır, destek beyanı hakkında değil.

Projenin geri kalanında bu iki soruyu ayrı tutun: çalışıyor mu ve destekleniyor mu. Her biri için farklı yanıtlara ve bazen farklı sorumlulara ihtiyacınız olacak.

Tasarımın gerçekte ne yapması gerektiğini yazın

Bir değiştirme seçmeden önce site listesini bir ürünün ölçülebileceği gereksinimlere dönüştürün:

• Şube cihazlarının hâlihazırda konuştuğu tünel protokolleri ve herhangi bir sahanın dinamik yönlendirmeye ihtiyacı olup olmadığı.
• Uzak önekler, yönlendirme yerine çeviri gerektiren herhangi bir çakışan adres alanı dahil.
• Azure ile rota değişimi ve yönlendirme tablosundaki her girdinin sahibi kim.
• En yoğun saatte dayanılması gereken verim ve bağlantı sayısı.
• Site sahiplerinin üzerinde anlaştığı yük devretme davranışı, yalnızca sizin kurabileceğiniz değil.

NAT atlanan ve ardından tüm tasarımı belirleyen maddedir. IPsec kurabilen bir cihaz, değiştirdiği RRAS dağıtımından farklı şekilde adres çevirebilir ve bu, şubenin hangi adresleri kaynak olarak gördüğünü ve günlüklerinizin ne kaydettiğini değiştirir.

Listeyi ağ sahiplerine götürün ve herhangi bir ürün tartışmasından önce onaylatın. Belirsiz gereksinimler her satıcı karşılaştırmasını bir tercih tartışmasına dönüştürür.

Değiştirmeleri bu gereksinimlere göre değerlendirin

Azure'un yönetilen bağlantı hizmetleri ve satıcı destekli sanal ağ cihazlarının ikisi de aynı listeye göre puanlanmalıdır. IPsec'i sonlandırabildiği için herhangi birinin RRAS VM'in doğrudan eşdeğeri olduğunu varsaymayın: NAT modeli ve rota sahipliği ile yüksek kullanılabilirlik tasarımı, mevcut sahaların nasıl bağlandığını ve yanıtlarının nereye döndüğünü belirler. Her adayı kâğıt üzerinde listeye göre puanlayın ve hangi gereksinimleri karşılamadığını yazın, çünkü o not seçimi sonradan gözden geçirilebilir kılar.

İki cihaz VM'inin önündeki yük dengeleyici kendi başına yüksek kullanılabilirlik değildir. Bir ön uç sağlar, eşitlenmiş tünel durumu değil, ve her oturumu düşüren bir yük devretme, birinin bilerek vermesi gereken bir tasarım kararıdır. Cihaz satıcısına desteklenen HA deseninin ne olduğunu ve sahalara vaat edilen kullanılabilirlikle eşleşip eşleşmediğini sorun. O sahalar buna bağımlı olmadan önce yük devretmeyi test edin ve kaybedilen her oturumu sürpriz değil bulgu olarak değerlendirin.

Gereksinim gerçekten basit olduğunda — bir saha, bir önek, çakışma yok — yönetilen bir hizmet genellikle işletme maliyetinde kazanır. Çeviri ve dinamik yönlendirme ikisi de işin içindeyse, cihaz yolu tek uygun yol olabilir ve bu, desteklenmeyen VM'i tutmak yerine daha uzun bir geçiş planlamak için bir nedendir.

Bir RRAS VM zaten çalışıyorsa

Keşif onu silmek için bir neden değildir. Değişikliği o VM'in biriktirdiği bağımlılıklar etrafında planlayın: diğer alt ağların güvendiği rotalar, kaynak adresleri gizleyen NAT kuralları ve izlemenin onun adresinden beklemeyi öğrendiği her şey. Desteklenen hedef yanında tasarlanıp doğrulanırken gerekli rotaları ve test edilmiş kurtarma yolunu koruyun.

Desteklenebilirliği ve teknik tanılamayı her zaman ayrı bulgular olarak tutun. Desteklenmeyen bir düzenin sıradan bir yönlendirme hatası da olabilir ve o hatayı düzeltmek destek durumunu değiştirmez. Her iki ifade de rapora aittir ve hiçbiri diğerini geçersiz kılmaz.

Kılavuzu destek atfını, gereksinim listesini, seçilen değiştirmeyi ve geçiş sırasını kaydederek kapatın. Bir denetçi veya yeni ekip üyesinin ilk soracağı şey bu dört maddedir.