RRAS auf einer Azure-VM wird nicht unterstützt: vor dem Design prüfen

Sie öffnen das Portal, stellen Windows Server 2022 in ein Subnetz, und die Rolle Remote Access lässt sich sauber installieren. Diese Abfolge beweist, dass der Installer funktioniert, nicht dass Microsoft die Konfiguration unterstützt. Die veröffentlichten Supporthinweise für Server-Software auf Azure-VMs führen RRAS unter den Windows Server-Features, die auf Azure-VMs nicht unterstützt werden, und das ist eine Architekturentscheidung, kein Detail der Fehlerbehebung. Ein Tunnel, der hochkommt, verschiebt die Bereitstellung nicht in die Supportgrenze hinein.

Die folgende Durchführung beginnt auf der Supportseite und arbeitet sich dann zu Anforderungen und Ersatzoptionen vor.

Beginnen Sie auf der Supportseite, nicht im Labor

Lesen Sie die Supporthinweise für Azure-VMs, bevor Sie irgendetwas dimensionieren. Sie trennen unterstützte Produkte, Rollen und Features, statt Windows Server als einen undifferenzierten Block zu behandeln. Achten Sie darauf, unter welche Zeile Ihre geplante Arbeitslast tatsächlich fällt, denn zwei Komponenten, die in der Konsole verwandt aussehen, können in verschiedenen Zeilen stehen.

Schreiben Sie die Fundstelle ins Design-Dokument, solange die Seite geöffnet ist. Supportstatus ist eine Tatsache mit Quelle, und ein Design-Review, das sie nicht zitieren kann, wird von demjenigen, der die Demo hat, niedergeredet.

Trennen Sie Betriebssystem-Support von Rollen- und Feature-Support

Dieselben Hinweise führen Network Policy and Access Services unter den unterstützten Rollen, während RRAS separat als nicht unterstützt aufgeführt wird. Diese beiden Einträge beschreiben verschiedene Dinge, und sie zu „Remotezugriff wird unterstützt“ zu verschmelzen, ist der Weg, auf dem ein Projekt aufgrund eines Fehlschlusses genehmigt wird. Dass das Betriebssystem unterstützt wird, sagt nichts über ein Feature mit eigener Zeile.

Die Einschränkung ist außerdem enger, als sie manchmal zitiert wird. Sie betrifft dieses Feature, das in einer Azure-VM läuft; sie bedeutet nicht, dass ein privates Netzwerk keine Verbindung zu Azure herstellen kann, und sie sagt nicht, dass RRAS überall nicht unterstützt wird. Ein älteres Labor, das Pakete korrekt weiterleitet, ist ein Beleg über Pakete, nicht über die Supportaussage.

Halten Sie diese beiden Fragen für den Rest des Projekts getrennt: funktioniert es, und wird es unterstützt. Sie brauchen unterschiedliche Antworten und manchmal unterschiedliche Verantwortliche für jede.

Schreiben Sie auf, was das Design tatsächlich leisten muss

Bevor Sie einen Ersatz wählen, verwandeln Sie die Standortliste in Anforderungen, an denen ein Produkt gemessen werden kann:

• Tunnelprotokolle, die die Geräte der Filialen bereits sprechen, und ob ein Standort dynamisches Routing braucht.
• Entfernte Präfixe, einschließlich jedes überlappenden Adressraums, der Übersetzung statt Routing erfordert.
• Routenaustausch mit Azure und wer welchen Eintrag der Routentabelle besitzt.
• Durchsatz und Verbindungszahlen, die die verkehrsreichste Stunde tragen muss.
• Failover-Verhalten, dem die Standortverantwortlichen zugestimmt haben, nicht nur das, was Sie bauen können.

NAT ist der Punkt, der übersprungen wird und dann das ganze Design entscheidet. Ein Gerät, das IPsec aufbauen kann, übersetzt Adressen möglicherweise anders als die RRAS-Bereitstellung, die es ersetzt, und das ändert, was die Filiale als Quelladressen sieht und was Ihre Protokolle aufzeichnen.

Nehmen Sie die Liste zu den Netzwerkverantwortlichen und bestätigen Sie sie vor jeder Produktdiskussion. Unklare Anforderungen machen jeden Anbietervergleich zu einer Geschmacksdebatte.

Bewerten Sie Ersatzlösungen an diesen Anforderungen

Azures verwaltete Konnektivitätsdienste und anbieterunterstützte virtuelle Netzwerk-Appliances müssen beide an derselben Liste bewertet werden. Gehen Sie nicht davon aus, dass eines von beiden ein direkter Ersatz für eine RRAS-VM ist, nur weil es IPsec terminieren kann: das NAT-Modell und die Routenverantwortung sowie das Hochverfügbarkeitsdesign entscheiden, wie bestehende Standorte sich verbinden und wohin ihre Antworten zurücklaufen. Bewerten Sie jeden Kandidaten auf dem Papier an der Liste und notieren Sie, welche Anforderungen er verfehlt, denn diese Notiz macht die Wahl später überprüfbar.

Ein Load Balancer vor zwei Appliance-VMs ist nicht aus sich heraus Hochverfügbarkeit. Er liefert ein Frontend, keinen synchronisierten Tunnelzustand, und ein Failover, das jede Sitzung fallen lässt, ist eine Designentscheidung, die jemand bewusst treffen muss. Fragen Sie den Appliance-Anbieter, welches HA-Muster unterstützt wird und ob es der Verfügbarkeit entspricht, die den Standorten zugesagt wurde. Testen Sie das Failover, bevor diese Standorte davon abhängen, und behandeln Sie jede verlorene Sitzung als Befund statt als Überraschung.

Wo die Anforderung wirklich einfach ist — ein Standort, ein Präfix, keine Überlappung — gewinnt ein verwalteter Dienst meist bei den Betriebskosten. Wo Übersetzung und dynamisches Routing beide im Spiel sind, kann der Appliance-Weg der einzig passende sein, und das ist ein Grund, eine längere Migration zu planen, statt die nicht unterstützte VM zu behalten.

Wenn bereits eine RRAS-VM läuft

Entdeckung ist kein Grund, sie zu löschen. Planen Sie die Änderung um die Abhängigkeiten herum, die diese VM angesammelt hat: Routen, auf die andere Subnetze angewiesen sind, NAT-Regeln, die Quelladressen verbergen, und alles, was das Monitoring von ihrer Adresse zu erwarten gelernt hat. Erhalten Sie die erforderlichen Routen und einen getesteten Wiederherstellungsweg, während das unterstützte Ziel daneben entworfen und validiert wird.

Halten Sie Unterstützbarkeit und technische Diagnose durchgehend als getrennte Befunde. Eine nicht unterstützte Anordnung kann auch einen gewöhnlichen Routingfehler haben, und diesen Fehler zu beheben ändert ihren Supportstatus nicht. Beide Aussagen gehören in den Bericht, und keine hebt die andere auf.

Schließen Sie die Durchführung ab, indem Sie die Support-Fundstelle, die Anforderungsliste, den gewählten Ersatz und die Umstellungsreihenfolge festhalten. Diese vier Punkte sind das, wonach ein Prüfer oder ein neues Teammitglied zuerst fragt.