Warum das Hinzufügen eines Azure-VPN-Präfixes die Verbindung kappt

Ein Präfix, das am falschen Azure-Objekt hinzugefügt wird, erzeugt eine Verbindung, die Connected meldet und nichts weiterleitet – und das ist die teuerste Fehlerart in diesem Stack. Drei Ressourcen sind beteiligt, und nur eine von ihnen besitzt den entfernten Adressraum: das virtuelle Netzwerkgateway, das lokale Netzwerkgateway, das die Gegenseite beschreibt, und die Verbindung, die beide zusammenführt. Das Präfix gehört zum lokalen Netzwerkgateway, die Verbindung muss neu aufgebaut werden, damit die Änderung wirksam wird, und das Gateway selbst bleibt normalerweise unangetastet. Die Reihenfolge ist nicht verhandelbar, und das Portal zeigt nur einen Teil davon.

Drei Objekte, von denen eines das Präfix hält

Der Adressraum des virtuellen Netzwerks beantwortet eine andere Frage: Was lebt innerhalb von Azure. Ein entferntes Präfix dort hinzuzufügen leitet keinen Verkehr dorthin, es erweitert nur den Raum, den die Plattform als eigenen betrachtet, was mit dem echten entfernten Bereich kollidieren kann. Das lokale Netzwerkgateway ist das Objekt, das die entfernten Präfixe hält, und die Verbindung referenziert beide Gateways plus einen vorab geteilten Schlüssel.

Es gibt eine dritte Reservierung, die man im Blick behalten muss. GatewaySubnet beherbergt die verwalteten Gateway-Instanzen, muss genau diesen Namen tragen, und für Nicht-Basic-SKUs wird erwartet, dass es mindestens ein /27 ist.

Nichts anderes gehört in dieses Subnetz, und eine Präfixänderung hat keinen Grund, es anzufassen. Ein Präfix, das im lokalen Netzwerkgateway fehlt, ist unerreichbar, egal was der Verbindungsstatus sagt, weil das Gateway beim Aushandeln des Tunnels nur die Präfixe anbietet, über die es informiert wurde. Deshalb ist das Symptom asymmetrisch: Der Tunnel steht, die Sicherheitszuordnung ist in Ordnung, und ein Subnetz taucht nie in den Verkehrsselektoren auf. Wenn ein einzelner entfernter Bereich fehlt, während seine Nachbarn funktionieren, hören Sie auf, auf den Tunnel zu schauen, und lesen Sie das lokale Netzwerkgateway.

Warum ausgerechnet die Verbindung entfernt wird

Das Verbindungsobjekt fixiert die ausgehandelte Konfiguration für seine gesamte Lebensdauer. Deshalb entfernt das dokumentierte Verfahren zuerst die Verbindung, aktualisiert das lokale Netzwerkgateway und erstellt die Verbindung dann mit demselben geteilten Schlüssel neu. Die Gateway-Instanzen werden für eine reine Präfixänderung nicht neu aufgebaut, was den Ausfall auf den Abbau der Verbindung begrenzt statt auf ein erneutes Bereitstellen des Gateways.

Diese Löschung ist der Ausfall, behandeln Sie sie also als geplante Änderung mit Beginn und erwartetem Ende statt als schnelle Bearbeitung. In PowerShell ist die Abfolge kurz: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, dann Set-AzLocalNetworkGateway mit dem neuen -AddressPrefix Array, dann New-AzVirtualNetworkGatewayConnection mit demselben -SharedKey und denselben Gateways. Die Wiederverwendung des Schlüssels ist wichtig, weil die Gegenseite nicht neu konfiguriert wird und ein neuer Schlüssel Abstimmung mit dem erfordert, der das entfernte Gerät besitzt. Wenn ein anderes Team dieses Gerät betreibt, stimmen Sie das Zeitfenster mit ihm ab, bevor Sie etwas entfernen.

Wann das Gateway selbst neu aufgebaut werden muss

Eine zweite Antwort, die zu diesem Problem kursiert, besagt, das Gateway müsse neu erstellt und der Schlüssel neu ausgetauscht werden. Das stimmt für eine andere Gruppe von Vorgängen: Änderung des Gatewaytyps oder der SKU, Wechsel zwischen Punkt-zu-Standort und Standort-zu-Standort oder Reparatur eines Gateways, dessen eigene Konfiguration falsch ist. Solche Änderungen verändern tatsächlich die Gateway-Ressource, ein Neuaufbau ist also wirklich erforderlich.

Ein für Punkt-zu-Standort erstelltes Gateway kann nicht einfach eine Standort-zu-Standort-Verbindung erhalten. Die Punkt-zu-Standort-Konfiguration muss entfernt und das Gateway neu erstellt werden, was auch einen neuen geteilten Schlüssel und ein neues Clientpaket erzeugt.

Das Punkt-zu-Standort-Paket verdient eine eigene Anmerkung, weil es abläuft. Das Portal erzeugt eine Datei mit kurzer Lebensdauer, daher ist der praktische Ansatz, sie einmal herunterzuladen und zusammen mit dem Clientzertifikat zu verteilen, statt Benutzern einen Portallink zu schicken, der tot ist, wenn sie ihn anklicken. Für die Präfixfrage trifft nichts davon zu. Die beiden Verfahren auseinanderzuhalten ist die ganze Disziplin: Präfixe sind eine Änderung auf Verbindungsebene, und Gateway-Eigenschaften sind eine Änderung auf Gateway-Ebene.

Lesen Sie den Zustand, nicht das Portal-Abzeichen

Lesen Sie den Zustand aus der Ressource statt aus dem Abzeichen im Portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 gibt ConnectionStatus zusammen mit Byte-Zählern für eingehenden und ausgehenden Verkehr zurück, und die Zähler sind es, die einen verbundenen Tunnel, der nichts trägt, von einem unterscheiden, der nie aufgebaut wurde.

Zähler, die mitten in einer Übertragung aufhören zu steigen, deuten auf den Pfad hin, nicht auf die Authentifizierung. Zähler, die sich überhaupt nicht bewegen, deuten auf die Präfixgruppe oder den geteilten Schlüssel hin.

Timer erklären eine Klasse von Trennungen, die fälschlich der VPN zugeschrieben werden. Der Load Balancer von Azure schließt inaktive Flows nach seinem konfigurierten Timeout, standardmäßig vier Minuten, als diese Notizen geschrieben wurden, und nach oben konfigurierbar, sodass ein OpenVPN-Server auf einer VM ohne Keepalive alle paar Minuten abbrechen kann, während alles andere gesund aussieht. Ein Gateway, das die Plattform zyklisch neu startet, kann auch eine VNet-Verbindung zu einer Web App unterbrechen, und dieser Fehler liegt auf der Plattformseite und nicht in einer Clientkonfiguration. Das Erkennungszeichen ist, ob die Trennung einem festen Intervall folgt oder einer Änderung, die Sie vorgenommen haben.

Halten Sie die drei Objekte und ihre Werte in einem Datensatz fest: den Adressraum des virtuellen Netzwerks, die Präfixliste des lokalen Netzwerkgateways und die Referenz auf den geteilten Schlüssel der Verbindung. Site-to-Site-PowerShell-Artikel dokumentiert die Befehle des lokalen Netzwerkgateways und die Reihenfolge, in die sie gehören. Eine Präfixänderung mit dem Gedächtnis zu vergleichen, ist der Weg, einen funktionierenden Tunnel zweimal neu aufzubauen.

Prüfen Sie dann in der Reihenfolge, in der Sie geändert haben: Das lokale Netzwerkgateway zeigt die neue Präfixliste, die Verbindung ist wieder Connected, und die Zähler bewegen sich, wenn Sie Verkehr zu einem Host im neuen Bereich senden. Wenn der dritte Schritt fehlschlägt, während die ersten beiden bestehen, hat die Gegenseite den neuen Verkehrsselektor nicht akzeptiert, und das entfernte Gerät braucht den passenden Phase-2-Eintrag. Das ist ein Gespräch mit dem anderen Ende des Tunnels, keine weitere Änderung in Azure.