Azure P2S VPN: Rückverkehr funktioniert nur in eine Richtung

Das Tunnelsymbol ist grün, die NSG wirkt durchlässig, die effektiven Routen sehen richtig aus, und dennoch kann die VM keine Verbindung zurück zum verbundenen Client öffnen. Die übliche Annahme lautet, ein funktionierender Point-to-Site-Tunnel sei symmetrisch: Wenn der Client die VM erreicht, erreicht die VM auch den Client. Diese Annahme ist der Fehler im Denken, nicht in der Konfiguration. Ein Tunnel kann eine Richtung eines unaufgeforderten Flusses tragen und die andere verwerfen, und die Behebung hängt davon ab, welche Schicht sie verwirft.

Mythos: Ein verbundener Tunnel ist ein Tunnel in beide Richtungen

Ein VPN-Tunnel ist ein Richtlinienpfad, kein Kabel. Jede Richtung wird gegen Selektoren, Routen und Filter geprüft, und jede davon kann die eine Richtung erlauben und die andere blockieren.

In der Praxis ist die Asymmetrie so verbreitet, dass die Richtung in den ersten Test gehört, nicht in den letzten. Der Client initiiert, das Gateway verfolgt den Fluss, und die Antwort folgt dem Zustand, der angelegt wurde. Eine VM, die einen neuen Fluss beginnt, hat keinen solchen Zustand und ist darauf angewiesen, dass der Rückweg ausdrücklich routbar und erlaubt ist. Fehlt dieser Weg, stirbt der Verbindungsversuch, bevor eine Anwendung ihn sieht.

Prüfen Sie die Richtung, bevor Sie die Erreichbarkeit prüfen

Wählen Sie eine Client-Adresse, eine VM-Adresse und ein Protokoll. Verbinden Sie sich vom Client und protokollieren Sie das Ergebnis; starten Sie dann denselben Test von der VM und protokollieren Sie auch diesen. Wenn der erste gelingt und der zweite scheitert, funktionieren der Client-Pool, die Gateway-Zuordnung und der Pfad vom Client zum VNet.

Der nächste Schritt sind Belege, nicht weitere Regeln. Prüfen Sie die NSG im VM-Subnetz in beide Richtungen, lesen Sie die effektiven Routen auf der VM-NIC und zeichnen Sie Pakete auf der VM auf, während der Client Datenverkehr sendet. Eine Anfrage, die ohne Antwort ankommt, ist ein Filter- oder Rückrouteproblem; eine Anfrage, die nie ankommt, ist ein Pfadproblem. Betrachten Sie einen fehlgeschlagenen Ping nicht als Beweis, dass die VM unerreichbar ist, denn eine ICMP-Richtlinie kann die Antwort verwerfen, während TCP funktioniert.

Der IKEv2-Point-to-Site-Rückweg ist der übliche Verdächtige

In dem Azure-Bericht hinter diesem Artikel konnte ein Client VMs über IKEv2 erreichen, aber eingehendes ICMP von der VM zum Client schlug fehl, bis der Tunneltyp des Gateways auf OpenVPN umgestellt wurde. Der Berichterstatter gibt an, Microsoft habe eine Einschränkung im IKEv2-Point-to-Site-Pfad bestätigt, bei der Rückverkehr von einer VM zum Client nicht symmetrisch geroutet wird, sofern nicht der Client die Sitzung begonnen hat. IKEv2 stützt sich auf Verkehrsselektoren, und das Gateway hat die Rückrichtung in diesem Fall nicht berücksichtigt.

Das macht OpenVPN nicht allgemein zum besseren Tunneltyp. Es macht den Tunneltyp zu einer Variablen in der Testmatrix für diese Arbeitslast.

Der Wechsel des Tunneltyps ist eine Dienständerung, kein Schalter. Jeder Client braucht ein kompatibles Profil, und das Gateway benötigt möglicherweise ein anderes Zertifikat oder eine andere Authentifizierungs-Einrichtung. Reproduzieren Sie das Einwegverhalten mit einem Testclient und einer Test-VM, ändern Sie den Typ nach einem genehmigten Zeitplan und wiederholen Sie danach dieselben Richtungstests. Übersteht das Verhalten den Wechsel, war der Tunneltyp nicht die Ursache, und Sie haben das Problem eingegrenzt, ohne die Produktion anzufassen.

Mythos: Broadcast-Erkennung überschreitet die VNet-Grenze

Eine zweite Annahme scheitert aus einem unabhängigen Grund. Ein virtuelles Azure-Netzwerk überträgt keinen Broadcast-Verkehr, daher kann eine VM keine Broadcast-Frames aus einem lokalen Netzwerk über eine Site-to-Site- oder Point-to-Site-Verbindung empfangen. Anwendungen, die Peers per Broadcast finden, etwa ältere Dateinavigation oder manche Geräteerkennungsprotokolle, werden die Gegenseite nie sehen, egal wie die Routen geschrieben sind.

Ersetzen Sie die Broadcast-Erkennung durch DNS-Namen, einen Verzeichnisdienst oder eine explizite Peer-Liste. Hat die Anwendung keine Unicast-Alternative, braucht das Design einen anderen Erkennungsmechanismus, keinen breiteren Tunnel.

Was zu ändern ist und wie man es belegt

Scheitert der Richtungstest nur bei IKEv2, halten Sie den Tunneltyp des Gateways, den Client-Adresspool und den genauen ICMP- oder TCP-Test fest und bewerten Sie dann ein genehmigtes OpenVPN-Profil für die betroffenen Clients. Scheitert er bei jedem Tunneltyp, arbeiten Sie am Rückweg: Die Client-Adresse muss vom VM-Subnetz aus routbar sein, jede benutzerdefinierte Route muss auf einen gültigen nächsten Hop zeigen, und die Firewall des Clients muss den eingehenden Fluss annehmen. Hängen Sie die NSG- und Routenbelege an das Ticket.

Prüfen Sie mit der Anwendung, nicht mit Ping. Ein erfolgreicher ICMP-Austausch nach einer Änderung sagt nichts über den Dienstport, seine Authentifizierung oder seine Namensauflösung aus. Wiederholen Sie den Test nach einer erneuten Verbindung, denn ein Client, der eine andere Pool-Adresse erhält, kann das Ergebnis ändern. Wiederholen Sie ihn dann noch einmal, nachdem der Client geschlafen und wieder aufgewacht ist, denn in einer fortgesetzten Sitzung taucht Einwegverhalten oft wieder auf.