RRAS na virtuálnom počítači Azure nie je podporovaný: overte to pred návrhom

Otvoríte portál, nasadíte Windows Server 2022 do podsiete a rola Remote Access sa nainštaluje bez problémov. Táto postupnosť dokazuje, že inštalátor funguje, nie že Microsoft túto konfiguráciu podporuje. Zverejnené usmernenia k podpore serverového softvéru pre virtuálne počítače Azure uvádzajú RRAS medzi funkciami Windows Server, ktoré nie sú na virtuálnych počítačoch Azure podporované, a to je architektonické rozhodnutie, nie detail riešenia problémov. Tunel, ktorý sa zdvihne, nepresunie nasadenie dovnútra hranice podpory.

Postup nižšie začína na stránke podpory a potom prechádza k požiadavkám a možnostiam náhrady.

Začnite na stránke podpory, nie v laboratóriu

Prečítajte si usmernenia k podpore virtuálnych počítačov Azure, skôr než čokoľvek dimenzujete. Oddeľujú podporované produkty, roly a funkcie namiesto toho, aby Windows Server považovali za jeden nerozlíšený blok. Všimnite si, do ktorého riadku vaša plánovaná záťaž skutočne patrí, pretože dva komponenty, ktoré v konzole vyzerajú príbuzne, môžu sedieť v rôznych riadkoch.

Zapíšte citáciu do návrhového dokumentu, kým je stránka otvorená. Stav podpory je fakt so zdrojom a návrhová revízia, ktorá ho nedokáže citovať, bude umlčaná tým, kto má demo.

Oddeľte podporu operačného systému od podpory rolí a funkcií

Tie isté usmernenia uvádzajú Network Policy and Access Services medzi podporovanými rolami, zatiaľ čo RRAS uvádzajú osobitne ako nepodporovaný. Tieto dva záznamy opisujú rôzne veci a ich zlúčenie do „vzdialený prístup je podporovaný“ je spôsob, akým býva projekt schválený na základe chybného čítania. To, že operačný systém je podporovaný, nič nehovorí o funkcii, ktorá má vlastný riadok.

Obmedzenie je tiež užšie, než sa niekedy cituje. Týka sa tej funkcie bežiacej vo vnútri virtuálneho počítača Azure; neznamená, že sa privátna sieť nemôže pripojiť k Azure, a nehovorí, že RRAS nie je podporovaný nikde. Staršie laboratórium, ktoré správne preposiela pakety, je dôkazom o paketoch, nie o vyhlásení o podpore.

Udržujte tieto dve otázky oddelené po zvyšok projektu: funguje to a je to podporované. Pre každú budete potrebovať iné odpovede a niekedy aj iných zodpovedných.

Zapíšte, čo má návrh skutočne robiť

Pred výberom náhrady premeňte zoznam lokalít na požiadavky, podľa ktorých sa produkt dá merať:

• Tunelové protokoly, ktorými zariadenia v pobočkách už hovoria, a či niektorá lokalita potrebuje dynamické smerovanie.
• Vzdialené prefixy vrátane akéhokoľvek prekrývajúceho sa adresného priestoru, ktorý potrebuje preklad, nie smerovanie.
• Výmenu trás s Azure a to, kto vlastní každý záznam v smerovacej tabuľke.
• Priepustnosť a počet pripojení, ktoré musí najvyťaženejšia hodina zvládnuť.
• Správanie pri prevzatí, na ktorom sa dohodli vlastníci lokalít, nielen to, ktoré dokážete postaviť.

NAT je položka, ktorá sa preskočí a potom rozhodne celý návrh. Zariadenie, ktoré dokáže nadviazať IPsec, môže stále prekladať adresy inak ako nahrádzané nasadenie RRAS, čo mení, čo pobočka vidí ako zdrojové adresy a čo zaznamenávajú vaše protokoly.

Zoznam vezmite k vlastníkom siete a potvrďte ho pred akoukoľvek diskusiou o produktoch. Nejednoznačné požiadavky menia každé porovnanie dodávateľov na spor o preferencie.

Ohodnoťte náhrady podľa týchto požiadaviek

Spravované služby pripojenia Azure aj sieťové virtuálne zariadenia podporované dodávateľmi sa musia hodnotiť podľa toho istého zoznamu. Nepredpokladajte, že niektoré z nich je priamym ekvivalentom virtuálneho počítača s RRAS len preto, že dokáže ukončiť IPsec: model NAT a vlastníctvo trás a návrh vysokej dostupnosti rozhodujú o tom, ako sa pripájajú existujúce lokality a kam sa vracajú ich odpovede. Ohodnoťte každého kandidáta na papieri podľa zoznamu a zapíšte, ktoré požiadavky nespĺňa, pretože práve tá poznámka robí voľbu neskôr preskúmateľnou.

Nástroj na vyvažovanie záťaže pred dvoma virtuálnymi zariadeniami nie je sám osebe vysoká dostupnosť. Poskytuje front end, nie synchronizovaný stav tunelov, a prevzatie, ktoré zhodí každú reláciu, je návrhové rozhodnutie, ktoré musí niekto urobiť zámerne. Opýtajte sa dodávateľa zariadenia, aký je podporovaný vzor HA a či zodpovedá dostupnosti prisľúbenej lokalitám. Otestujte prevzatie, skôr než na ňom tieto lokality začnú závisieť, a každú stratenú reláciu berte ako zistenie, nie ako prekvapenie.

Kde je požiadavka naozaj jednoduchá — jedna lokalita, jeden prefix, žiadne prekrývanie — spravovaná služba zvyčajne vyhráva prevádzkovými nákladmi. Kde sú vo hre aj preklad, aj dynamické smerovanie, cesta cez zariadenie môže byť jediná vhodná, a to je dôvod naplánovať dlhšiu migráciu namiesto zachovania nepodporovaného virtuálneho počítača.

Ak už virtuálny počítač s RRAS beží

Objav nie je dôvodom ho vymazať. Naplánujte zmenu okolo závislostí, ktoré tento virtuálny počítač nazhromaždil: trás, na ktoré sa spoliehajú iné podsiete, pravidiel NAT, ktoré skrývajú zdrojové adresy, a všetkého, čo sa monitorovanie naučilo od jeho adresy očakávať. Zachovajte potrebné trasy a otestovanú cestu obnovy, zatiaľ čo sa podporovaný cieľ navrhuje a overuje vedľa.

Udržujte podporovateľnosť a technickú diagnostiku po celý čas ako oddelené zistenia. Nepodporované usporiadanie môže mať aj bežnú chybu smerovania a oprava tejto chyby nemení jeho stav podpory. Obe tvrdenia patria do správy a žiadne to druhé neruší.

Uzavrite postup zapísaním citácie podpory, zoznamu požiadaviek, zvolenej náhrady a poradia prechodu. Tieto štyri položky sú to prvé, na čo sa bude pýtať audítor alebo nový člen tímu.