Warum Point-to-Site ein routenbasiertes Azure VPN-Gateway benötigt

Ein richtlinienbasiertes Gateway baut einen IPsec-Tunnel auf, der durch Verkehrsselektoren ausgewählt wird, und besitzt keine Schnittstelle, an die es Clientrouten übergeben könnte. Point-to-Site ist eine Routingfunktion: Das Gateway besitzt einen Client-Adresspool und installiert Routen zu diesen Clients im virtuellen Netzwerk. Genau diese Diskrepanz ist der Grund, warum das Portal keine Option zum Hinzufügen anzeigt. Nichts am vorhandenen Gateway lässt sich umschalten, um die Schnittstelle zu erzeugen, daher ist die Änderung ein Austausch und keine Konfigurationsbearbeitung.

Die Reihenfolge ist wichtiger als die einzelnen Schritte. Wird die Abfolge vertauscht, läuft die Site-to-Site-Unterbrechung über das Wartungsfenster hinaus.

Was ein richtlinienbasiertes Gateway tatsächlich tut

Ein richtlinienbasiertes Gateway gleicht Pakete mit den an der Verbindung konfigurierten Verkehrsselektoren ab und schickt die Treffer in einen Tunnel. Es gibt keine Tunnelschnittstelle mit einer Adresse, und im virtuellen Netzwerk erscheint nirgends eine Route pro Client. Die Routentabelle erhält lediglich die lokalen Präfixe, die auf das Gateway zeigen. Dieses Modell reicht für eine Site-to-Site-Verbindung zwischen zwei festen Adressräumen.

Ein routenbasiertes Gateway arbeitet umgekehrt: Es stellt eine Tunnelschnittstelle bereit, und Routen entscheiden, was hineingelangt. Point-to-Site und jedes Design, dessen Peer-Menge sich ändert, hängen davon ab, dass diese Schnittstelle existiert.

Warum der Client-Pool diese Schnittstelle braucht

Wenn ein Laptop sich verbindet, weist das Gateway ihm eine Adresse aus dem Point-to-Site-Pool zu. Das virtuelle Netzwerk braucht dann eine Route, die besagt, dass diese Adresse über das Gateway erreichbar ist. Ohne Tunnelschnittstelle gibt es nichts, woran diese Route gehängt werden könnte.

Der Pool stammt aus einem Bereich, den Sie festlegen, und das Gateway vergibt daraus. Überschneidet sich dieser Bereich mit dem lokalen Netzwerk oder einem gepeerten virtuellen Netzwerk, zeigt sich der Konflikt erst, nachdem ein Client verbunden ist, was ein schlechter Zeitpunkt zum Entdecken ist. Reservieren Sie den Pool, bevor die Migration beginnt.

Auch der Typ ist keine Einstellung pro Verbindung. Ein Gateway hat einen Typ, und jede Verbindung, die es hält, verhält sich entsprechend, daher braucht ein gemischtes Design ein zweites Gateway statt einer zweiten Verbindung.

Der Typ steht bei der Erstellung fest

Microsoft gibt an, dass ein Gateway für virtuelle Netzwerke nach der Bereitstellung nicht zwischen richtlinienbasiert und routenbasiert geändert werden kann. Es gibt keinen Konvertierungsbefehl und keinen Schalter im Portal. Ein zweites Gateway im selben Subnetz zu erstellen ist ebenfalls kein Ausweg, da Azure ein Gateway pro virtuellem Netzwerk zulässt. Die Migration besteht daher aus Entfernen, Neuaufbau und erneutem Verbinden.

Das zieht auch die SKU-Entscheidung in denselben Aufbau. Ein späterer Wechsel zu einer größeren SKU ist ein weiterer Gateway-Austausch mit einer weiteren Unterbrechung.

Ein Gateway, ein GatewaySubnet

Das Gateway lebt in einem Subnetz namens GatewaySubnet, und nur ein Gateway belegt es. Die Dimensionierung dieses Subnetzes gehört zur Vorbereitung, denn eine größere SKU braucht mehr Adressen, und ein Subnetz lässt sich später nicht verkleinern. Notieren Sie die aktuellen Site-to-Site-Einstellungen, den gemeinsamen Schlüssel, das lokale Netzwerkgateway und die effektiven Routen, bevor Sie irgendetwas anfassen. Behandeln Sie das Fenster dann als Ausfall, denn der Site-to-Site-Tunnel bleibt unten, bis die neue Verbindung konfiguriert ist.

Eine Neuaufbau-Reihenfolge, die den Ausfall begrenzt: das routenbasierte Gateway erstellen, die Site-to-Site-Verbindung zum selben lokalen Netzwerkgateway neu erstellen, Tunnel und eine Host-zu-Host-Anfrage bestätigen und erst dann Point-to-Site hinzufügen und ein frisches Clientpaket erzeugen.

Was der Austausch nicht behebt

Eine zweite Einschränkung gehört dem Peer und nicht Azure. Ein richtlinienbasiertes lokales Gerät erreicht nur das virtuelle Netzwerk, mit dem es verbunden ist, und kann nicht über dasselbe Gateway zu anderen lokalen Netzwerken oder anderen virtuellen Netzwerken transiten. Der Austausch der Azure-Seite ändert nicht, was der Peer auswählen kann.

Wenn die Anforderung wirklich Transit zwischen Standorten ist, lautet die Antwort ein routenbasiertes Peer-Gerät oder eine Topologie, in der jedes Ziel separat endet. Klären Sie das, bevor Sie einen Termin versprechen, denn der Gateway-Austausch allein liefert das nicht.

Reihenfolge der Schritte und Prüfungen

Prüfen Sie jede Fähigkeit einzeln. Zuerst den Tunnelstatus zwischen den Standorten und eine Host-zu-Host-Anfrage, dann eine Point-to-Site-Verbindung und eine private Ressource, dann jeden Transitpfad, den das Design behauptet. Ein grüner Gateway-Status beweist nur, dass die Sicherheitsassoziation zustande kam, und nichts weiter. Halten Sie die Prüfungen in dieser Reihenfolge, damit ein Fehler auf die Stufe zeigt, die ihn eingeführt hat.

Erzeugen Sie Clientpakete nach jeder Topologieänderung neu und halten Sie den Pool von jedem lokalen und gepeerten Bereich frei. Die Einschränkungen und SKU-Unterschiede sind in der Referenz zu den Azure VPN Gateway-Einstellungen gesammelt.