RRAS na virtuálním počítači Azure není podporován: ověřte to před návrhem

Otevřete portál, nasadíte Windows Server 2022 do podsítě a role Remote Access se nainstaluje bez problémů. Tato posloupnost dokazuje, že instalátor funguje, ne že Microsoft tuto konfiguraci podporuje. Zveřejněné pokyny k podpoře serverového softwaru pro virtuální počítače Azure uvádějí RRAS mezi funkcemi Windows Server, které na virtuálních počítačích Azure podporovány nejsou, a to je architektonické rozhodnutí, nikoli detail řešení potíží. Tunel, který se zvedne, nepřesune nasazení dovnitř hranice podpory.

Následující postup začíná na stránce podpory a poté se rozšiřuje k požadavkům a možnostem náhrady.

Začněte na stránce podpory, ne v laboratoři

Přečtěte si pokyny k podpoře virtuálních počítačů Azure, než cokoli dimenzujete. Oddělují podporované produkty, role a funkce, místo aby Windows Server považovaly za jeden nerozlišený blok. Všimněte si, do kterého řádku vaše zamýšlená zátěž skutečně spadá, protože dvě komponenty, které v konzoli vypadají příbuzně, mohou sedět v různých řádcích.

Zapište citaci do návrhového dokumentu, dokud je stránka otevřená. Stav podpory je fakt se zdrojem a návrhová revize, která ho nedokáže citovat, bude umlčena tím, kdo má demo.

Oddělte podporu operačního systému od podpory rolí a funkcí

Tyto pokyny uvádějí Network Policy and Access Services mezi podporovanými rolemi, zatímco RRAS uvádějí samostatně jako nepodporovaný. Tyto dva záznamy popisují různé věci a jejich sloučení do „vzdálený přístup je podporován“ je způsob, jakým bývá projekt schválen na základě chybného čtení. To, že je operační systém podporován, nic neříká o funkci, která má vlastní řádek.

Omezení je také užší, než se někdy cituje. Týká se této funkce běžící uvnitř virtuálního počítače Azure; neznamená, že se privátní síť nemůže připojit k Azure, a neříká, že RRAS není podporován nikde. Starší laboratoř, která správně předává pakety, je dokladem o paketech, nikoli o prohlášení o podpoře.

Udržujte tyto dvě otázky oddělené po zbytek projektu: funguje to, a je to podporováno. Budete pro každou potřebovat jiné odpovědi a někdy i jiné vlastníky.

Zapište, co má návrh skutečně dělat

Než vyberete náhradu, převeďte seznam lokalit na požadavky, podle nichž lze produkt měřit:

• Tunelové protokoly, kterými zařízení v pobočkách už mluví, a zda některá lokalita potřebuje dynamické směrování.
• Vzdálené prefixy, včetně jakéhokoli překrývajícího se adresního prostoru, který potřebuje překlad, nikoli směrování.
• Výměna tras s Azure a to, kdo vlastní každý záznam směrovací tabulky.
• Propustnost a počty připojení, které musí nejvytíženější hodina udržet.
• Chování při převzetí, na němž se vlastníci lokalit dohodli, ne jen to, které dokážete postavit.

NAT je položka, která se přeskočí a pak rozhodne celý návrh. Zařízení, které umí navázat IPsec, může stále překládat adresy jinak než nasazení RRAS, které nahrazuje, což mění, co pobočka vidí jako zdrojové adresy a co zaznamenají vaše protokoly.

Vezměte seznam k vlastníkům sítě a potvrďte ho před jakoukoli diskusí o produktech. Nejednoznačné požadavky promění každé srovnání dodavatelů v spor o preference.

Hodnoťte náhrady podle těchto požadavků

Služby spravovaného připojení Azure i síťová virtuální zařízení podporovaná dodavateli je třeba bodovat podle stejného seznamu. Nepředpokládejte, že některé z nich je přímým ekvivalentem virtuálního počítače s RRAS jen proto, že umí ukončit IPsec: model NAT a vlastnictví tras a návrh vysoké dostupnosti rozhodují o tom, jak se stávající lokality připojují a kam se jejich odpovědi vracejí. Bodujte každého kandidáta na papíře podle seznamu a zapište, které požadavky nesplňuje, protože právě ta poznámka činí volbu později přezkoumatelnou.

Nástroj pro vyrovnávání zatížení před dvěma virtuálními zařízeními není sám o sobě vysoká dostupnost. Poskytuje front end, ne synchronizovaný stav tunelů, a převzetí, které zahodí každou relaci, je návrhové rozhodnutí, které musí někdo učinit záměrně. Zeptejte se dodavatele zařízení, jaký je podporovaný vzor HA a zda odpovídá dostupnosti slíbené lokalitám. Otestujte převzetí dřív, než na něm tyto lokality začnou záviset, a každou ztracenou relaci berte jako zjištění, ne jako překvapení.

Kde je požadavek skutečně jednoduchý — jedna lokalita, jeden prefix, žádné překrývání — spravovaná služba obvykle vyhraje provozními náklady. Kde jsou ve hře překlad i dynamické směrování, může být cesta přes zařízení jediná vhodná, a to je důvod naplánovat delší migraci, místo aby nepodporovaný virtuální počítač zůstal.

Pokud už virtuální počítač s RRAS běží

Objev není důvodem ho smazat. Naplánujte změnu kolem závislostí, které tento virtuální počítač nashromáždil: tras, na které spoléhají jiné podsítě, pravidel NAT, která skrývají zdrojové adresy, a všeho, co se monitorování naučilo od jeho adresy očekávat. Zachovejte potřebné trasy a otestovanou cestu obnovy, zatímco se podporovaný cíl navrhuje a ověřuje vedle.

Udržujte podporovatelnost a technickou diagnostiku po celou dobu jako oddělená zjištění. Nepodporované uspořádání může mít také běžnou chybu směrování a oprava této chyby nemění jeho stav podpory. Obě tvrzení patří do zprávy a žádné z nich to druhé neruší.

Uzavřete postup zapsáním citace podpory, seznamu požadavků, zvolené náhrady a pořadí přechodu. Tyto čtyři položky jsou to první, na co se zeptá auditor nebo nový člen týmu.