RRAS pe o VM Azure nu este acceptat: verificați înainte de proiectare

Deschideți portalul, implementați Windows Server 2022 într-o subrețea, iar rolul Remote Access se instalează fără probleme. Această secvență dovedește că instalatorul funcționează, nu că Microsoft acceptă configurația. Ghidul publicat de suport pentru software de server pentru mașini virtuale Azure listează RRAS printre funcționalitățile Windows Server care nu sunt acceptate pe VM-urile Azure, iar aceasta este o decizie de arhitectură, nu un detaliu de depanare. Un tunel care urcă nu mută implementarea în interiorul limitei de suport.

Parcursul de mai jos începe pe pagina de suport, apoi merge spre cerințe și opțiunile de înlocuire.

Începeți pe pagina de suport, nu în laborator

Citiți ghidul de suport pentru VM-urile Azure înainte de a dimensiona ceva. Acesta separă produsele, rolurile și funcționalitățile acceptate în loc să trateze Windows Server ca un singur bloc nediferențiat. Observați în ce rând se încadrează de fapt încărcarea de lucru dorită, deoarece două componente care par legate în consolă pot sta în rânduri diferite.

Scrieți citarea în documentul de proiectare cât timp pagina este deschisă. Starea de suport este un fapt cu o sursă, iar o revizuire de proiectare care nu o poate cita va fi contrazisă de cel care are demonstrația.

Separați suportul sistemului de operare de suportul rolurilor și funcționalităților

Acel ghid include Network Policy and Access Services printre rolurile acceptate, în timp ce listează RRAS separat ca neacceptat. Cele două intrări descriu lucruri diferite, iar unirea lor în „accesul de la distanță este acceptat“ este felul în care un proiect este aprobat pe o citire greșită. Faptul că sistemul de operare este acceptat nu spune nimic despre o funcționalitate cu rândul ei.

Limitarea este și mai îngustă decât se citează uneori. Se referă la acea funcționalitate care rulează în interiorul unui VM Azure; nu înseamnă că o rețea privată nu se poate conecta la Azure și nu spune că RRAS nu este acceptat nicăieri. Un laborator mai vechi care redirecționează corect pachetele este dovadă despre pachete, nu despre declarația de suport.

Țineți cele două întrebări separate pentru restul proiectului: funcționează și este acceptat. Veți avea nevoie de răspunsuri diferite și uneori de responsabili diferiți pentru fiecare.

Scrieți ce trebuie să facă de fapt proiectarea

Înainte de a alege o înlocuire, transformați lista de locații în cerințe după care un produs poate fi măsurat:

• Protocoalele de tunel pe care le vorbesc deja echipamentele sucursalelor și dacă vreo locație are nevoie de rutare dinamică.
• Prefixele la distanță, inclusiv orice spațiu de adrese suprapus care are nevoie de traducere, nu de rutare.
• Schimbul de rute cu Azure și cine deține fiecare intrare din tabelul de rutare.
• Debitul și numărul de conexiuni pe care trebuie să le susțină cea mai aglomerată oră.
• Comportamentul la preluare convenit de proprietarii locațiilor, nu doar cel pe care îl puteți construi.

NAT este elementul care este sărit și apoi decide întreaga proiectare. Un echipament care poate stabili IPsec poate totuși traduce adrese diferit față de implementarea RRAS pe care o înlocuiește, iar asta schimbă ce vede sucursala ca adrese sursă și ce înregistrează jurnalele dumneavoastră.

Duceți lista la proprietarii rețelei și confirmați-o înainte de orice discuție despre produse. Cerințele ambigue transformă fiecare comparație de furnizori într-o dispută de preferințe.

Evaluați înlocuirile față de acele cerințe

Serviciile de conectivitate administrate de Azure și dispozitivele virtuale de rețea acceptate de furnizori trebuie ambele punctate față de aceeași listă. Nu presupuneți că vreunul este echivalent direct al unui VM cu RRAS doar pentru că poate termina IPsec: modelul NAT și proprietatea rutelor și proiectarea de înaltă disponibilitate decid modul în care se conectează locațiile existente și unde se întorc răspunsurile lor. Punctați fiecare candidat pe hârtie față de listă și notați ce cerințe nu le îndeplinește, pentru că acea notă face alegerea revizuibilă mai târziu.

Un balansator de sarcină în fața a două VM-uri de dispozitiv nu este înaltă disponibilitate prin el însuși. Oferă un front end, nu o stare de tunel sincronizată, iar o preluare care renunță la fiecare sesiune este o decizie de proiectare pe care cineva trebuie să o ia intenționat. Întrebați furnizorul dispozitivului care este modelul HA acceptat și dacă acesta corespunde disponibilității promise locațiilor. Testați preluarea înainte ca acele locații să depindă de ea și tratați fiecare sesiune pierdută ca o constatare, nu ca o surpriză.

Unde cerința este cu adevărat simplă — o locație, un prefix, fără suprapunere — un serviciu administrat câștigă de obicei la costul operațional. Unde traducerea și rutarea dinamică sunt ambele în joc, calea prin dispozitiv poate fi singura potrivită, iar acesta este un motiv să planificați o migrare mai lungă în loc să păstrați VM-ul neacceptat.

Dacă un VM cu RRAS rulează deja

Descoperirea nu este un motiv să îl ștergeți. Planificați schimbarea în jurul dependențelor pe care acel VM le-a acumulat: rute pe care se bazează alte subrețele, reguli NAT care ascund adrese sursă și tot ce monitorizarea a învățat să aștepte de la adresa lui. Păstrați rutele necesare și o cale de recuperare testată în timp ce ținta acceptată este proiectată și validată alături.

Țineți sustenabilitatea și diagnosticul tehnic ca constatări separate tot timpul. O amenajare neacceptată poate avea și o eroare obișnuită de rutare, iar corectarea acelei erori nu îi schimbă statutul de suport. Ambele afirmații aparțin raportului și niciuna nu o anulează pe cealaltă.

Închideți parcursul înregistrând citarea de suport, lista de cerințe, înlocuirea aleasă și ordinea de tranziție. Aceste patru elemente sunt primul lucru pe care îl va cere un auditor sau un membru nou al echipei.