Az RRAS Azure VM-en nem támogatott: ellenőrizze a tervezés előtt

Megnyitja a portált, üzembe helyezi a Windows Server 2022-t egy alhálózatban, és a Remote Access szerepkör tisztán települ. Ez a sorrend azt bizonyítja, hogy a telepítő működik, nem azt, hogy a Microsoft támogatja a konfigurációt. Az Azure virtuális gépekhez közzétett kiszolgálószoftver-támogatási útmutató az RRAS-t azon Windows Server-funkciók közé sorolja, amelyek Azure VM-en nem támogatottak, és ez architektúradöntés, nem hibaelhárítási részlet. Egy feljövő alagút nem viszi beljebb a telepítést a támogatási határon.

Az alábbi végigvezetés a támogatási oldalon kezdődik, majd onnan a követelmények és a helyettesítési lehetőségek felé halad.

A támogatási oldalon kezdje, ne a laborban

Olvassa el az Azure VM támogatási útmutatót, mielőtt bármit méretez. Szétválasztja a támogatott termékeket, szerepköröket és funkciókat ahelyett, hogy a Windows Servert egyetlen differenciálatlan blokként kezelné. Jegyezze meg, melyik sor alá esik valójában a tervezett munkaterhelés, mert két, a konzolon hasonlónak tűnő összetevő különböző sorokban lehet.

Írja be a hivatkozást a tervezési dokumentumba, amíg az oldal nyitva van. A támogatási állapot forrással rendelkező tény, és egy tervezési felülvizsgálatot, amely nem tud rá hivatkozni, a demóval rendelkező fél lebeszél.

Válassza szét az operációs rendszer támogatását a szerepkörök és funkciók támogatásától

Ugyanez az útmutató a Network Policy and Access Services-t a támogatott szerepkörök között sorolja fel, míg az RRAS-t külön, nem támogatottként listázza. Ez a két bejegyzés különböző dolgokat ír le, és ezek összevonása „a távoli hozzáférés támogatott“ formára az, ahogy egy projekt félreolvasás alapján jóváhagyást kap. Az, hogy az operációs rendszer támogatott, semmit sem mond egy saját sorral rendelkező funkcióról.

A korlátozás szűkebb is annál, mint ahogy néha idézik. Arra a funkcióra vonatkozik, amely Azure VM-en belül fut; nem jelenti azt, hogy egy magánhálózat nem csatlakozhat az Azure-hoz, és nem mondja, hogy az RRAS sehol sem támogatott. Egy régi labor, amely helyesen továbbítja a csomagokat, a csomagokról szóló bizonyíték, nem a támogatási nyilatkozatról.

Tartsa ezt a két kérdést külön a projekt hátralévő részében: működik-e, és támogatott-e. Mindegyikhez más válaszokra és néha más felelősökre lesz szüksége.

Írja le, mit kell a tervezésnek valóban tennie

Mielőtt helyettesítőt választ, alakítsa a telephelylistát olyan követelményekké, amelyekhez mérni lehet egy terméket:

• Azok az alagútprotokollok, amelyeket a fióki eszközök már beszélnek, és hogy szüksége van-e valamelyik telephelynek dinamikus útválasztásra.
• A távoli előtagok, beleértve bármilyen átfedő címteret, amely fordítást igényel, nem útválasztást.
• Az útvonalcserét az Azure-ral, és hogy ki birtokolja az útválasztási táblázat egyes bejegyzéseit.
• Az átviteli teljesítményt és a kapcsolatszámot, amelyet a legforgalmasabb órának el kell viselnie.
• A telephelygazdák által elfogadott feladatátvételi viselkedést, nem csak azt, amit Ön fel tud építeni.

A NAT az az elem, amelyet kihagynak, és amely aztán az egész tervezést eldönti. Egy IPsec létrehozására képes eszköz még mindig máshogy fordíthatja a címeket, mint a leváltott RRAS-telepítés, és ez megváltoztatja, mit lát a fiók forráscímként, és mit rögzítenek a naplói.

Vigye a listát a hálózati gazdákhoz, és erősítse meg még bármilyen termékvita előtt. A homályos követelmények minden szállító-összehasonlítást preferenciavitává alakítanak.

Értékelje a helyettesítőket ezekhez a követelményekhez

Az Azure felügyelt kapcsolódási szolgáltatásait és a szállítók által támogatott hálózati virtuális berendezéseket is ugyanahhoz a listához kell pontozni. Ne feltételezze, hogy bármelyik közvetlen egyenértékű egy RRAS VM-mel, csak mert IPsec-t tud lezárni: a NAT-modell és az útvonalak tulajdonjoga valamint a magas rendelkezésre állás tervezése dönti el, hogyan csatlakoznak a meglévő telephelyek, és hova térnek vissza a válaszaik. Pontozza minden jelöltet papíron a lista ellen, és írja le, mely követelményeket nem teljesíti, mert ez a feljegyzés teszi a választást később felülvizsgálhatóvá.

Két berendezés-VM előtti terheléselosztó önmagában nem magas rendelkezésre állás. Front endet ad, nem szinkronizált alagútállapotot, és az a feladatátvétel, amely minden munkamenetet elejt, olyan tervezési döntés, amelyet valakinek szándékosan meg kell hoznia. Kérdezze meg a berendezés szállítójától, mi a támogatott HA-minta, és hogy az megfelel-e a telephelyeknek ígért rendelkezésre állásnak. Tesztelje a feladatátvételt, mielőtt azok a telephelyek függnének tőle, és kezeljen minden elveszett munkamenetet leletként, nem meglepetésként.

Ahol a követelmény valóban egyszerű — egy telephely, egy előtag, nincs átfedés — a felügyelt szolgáltatás általában az üzemeltetési költségen nyer. Ahol a fordítás és a dinamikus útválasztás is szerepel, a berendezéses út lehet az egyetlen megfelelő, és ez ok arra, hogy hosszabb átállást tervezzen a nem támogatott VM megtartása helyett.

Ha már fut egy RRAS VM

A felderítés nem ok a törlésre. Tervezze a változtatást azok köré a függőségek köré, amelyeket az a VM felhalmozott: útvonalak, amelyekre más alhálózatok támaszkodnak, a forráscímeket elrejtő NAT-szabályok, és mindaz, amit a monitorozás megtanult elvárni a címétől. Őrizze meg a szükséges útvonalakat és egy tesztelt helyreállítási utat, miközben a támogatott cél mellette terveződik és validálódik.

Tartsa a támogathatóságot és a műszaki diagnózist végig külön leletként. Egy nem támogatott elrendezésnek is lehet hétköznapi útválasztási hibája, és a hiba javítása nem változtatja meg a támogatási állapotát. Mindkét állítás a jelentésbe tartozik, és egyik sem semmisíti meg a másikat.

Zárja le a végigvezetést a támogatási hivatkozás, a követelménylista, a választott helyettesítő és az átállási sorrend rögzítésével. Ez a négy elem az, amit egy auditor vagy egy új csapattag elsőként kérdez.