Azure IP-Flow-Verify meldet erlaubt, aber das VPN schlägt weiterhin fehl

Site-to-Site-Tunnel verbunden, VM gesund, der lokale Client bekommt nichts. Sie öffnen den Network Watcher, führen IP-Flow-Verify aus, und es sagt Access allowed, also wird das Ticket als VPN-Problem geschlossen. Dieses Ergebnis bedeutet nicht, was es zu sein scheint, denn IP-Flow-Verify bewertet die Sicherheitsregeln für den von Ihnen beschriebenen Flow und prüft nie, ob Azure eine Route zu Ihrem lokalen Präfix hat.

Die Filterfrage und die Routingfrage sind getrennt, und der Network Watcher beantwortet sie mit unterschiedlichen Werkzeugen. Zu wissen, welche Sie gestellt haben, ist der größte Teil der Diagnose.

Was IP-Flow-Verify tatsächlich entscheidet

IP-Flow-Verify nimmt eine VM, eine Netzwerkschnittstelle, eine Richtung, Fünf-Tupel-Werte und ein Protokoll und meldet dann die Entscheidung der NSG- und Sicherheitsadministratorregel für diesen Flow. Es arbeitet mit TCP und UDP, ist also kein ICMP-Regeltester, und ein blockierter Ping beweist nichts über Ihren Dienst. Geben Sie ihm den echten Flow statt einer Vermutung. Eine eingehende Verbindung vom lokalen Netz zu einem Datenbankport ist eine andere Beschreibung als eine ausgehende Verbindung, die die VM initiiert.

Wenn das Gateway Adressen übersetzt, verwenden Sie die Quelladresse, die die von Ihnen bewertete Grenze erreicht, nicht die aus der Clientkonfiguration. Lesen Sie das Ergebnis auch für das, was es ist. Access allowed bedeutet, dass die Filtersschicht das Paket zulassen würde, wenn es ankäme, und nichts weiter.

Was es Ihnen nicht sagen kann, ist die von Azure gewählte Route, ob die Gastfirewall den Port zulässt oder ob etwas lauscht. Das lebt auf anderen Schichten.

Was nächster Hop und effektive Routen hinzufügen

Der nächste Hop beantwortet eine Weiterleitungsfrage: für dieses Ziel, welchen Nächster-Hop-Typ Azure wählt, an welcher Adresse, aus welcher Routentabelle. Effektive Routen listen, was die NIC tatsächlich hat. Führen Sie beides aus, und Sie erhalten den Azure-seitigen Pfad, den ein grünes IP-Flow-Verify leer lässt.

Microsofts Übersicht zu IP-Flow-Verify nennt den Filterumfang direkt, während die Seiten zu nächstem Hop und Routendiagnose die Weiterleitungsseite abdecken. Zitieren Sie die richtige Seite, wenn Sie den Befund aufschreiben.

Die Befehle sind kurz genug, um sie aus einer Shell auszuführen. az network nic show-effective-route-table listet die auf die Schnittstelle angewendeten Routen auf. az network watcher show-next-hop gibt mit Quelle und Ziel den ausgewählten Hop zurück. Vergleichen Sie das Präfix, das Sie interessiert, mit dieser Tabelle und bestätigen Sie dann, welcher Eintrag gewinnt.

Gehen Sie den Rückweg von der NIC der VM

Tun Sie das von der NIC der Ziel-VM aus, für das Präfix des lokalen Clients, nicht für das Internet. Der Rückweg ist der Ort, an dem sich Site-to-Site-Fehler verstecken, denn eine Tunnelstatusprüfung meldet nur, dass die Sicherheitszuordnungen bestehen.

Wenn die erwartete Route fehlt, prüfen Sie die entfernten Präfixe, die die Gatewaykonfiguration bereitstellt, das VNet-Konnektivitätsdesign und jede Routenverteilungseinstellung. Ein lokales Netzwerkgatewayobjekt beschreibt die lokale Seite; seine Existenz beweist nicht, dass jedes erforderliche Präfix auf der NIC vorhanden und bevorzugt ist. Das sind verschiedene Fakten, und nur einer davon erscheint in einer Portalzusammenfassung.

Lesen Sie den Nächster-Hop-Typ, statt ein Beispiel zu kopieren

Ein Pfad über ein verwaltetes VPN-Gateway zeigt normalerweise VirtualNetworkGateway als Nächster-Hop-Typ. VirtualAppliance beschreibt ein anderes Weiterleitungsdesign, meist eine Firewall oder ein virtuelles Netzwerkgerät.

Erstellen Sie keine Geräteroute zu einem geratenen VPN-Endpunkt, nur weil eine alte Forumsantwort diesen Typ verwendet hat. Wenn eine benutzerdefinierte Route den beabsichtigten Pfad überschreibt, ermitteln Sie ihren Eigentümer und Zweck, bevor Sie sie ändern. Eine zweite NIC kann ebenfalls ändern, welche Schnittstelle der Gast verwendet, und ihr Entfernen kann einen anderen Dienst beschädigen, statt diese Route zu reparieren.

Wechseln Sie zur Grenze, die weiterhin fehlschlägt

Wenn Filterung und Routing beide zum Design passen, liegt der Fehler woanders. Prüfen Sie die eigene Routentabelle des Gastes, seine Firewall und ob der Listener an die erwartete Adresse gebunden ist. Prüfen Sie dann die geschützten Verkehrsselektoren des VPN und den lokalen Antwortpfad. Jede davon ist ein eigener Test mit einem eigenen Ergebnis.

Schließen Sie mit einer erlaubten Anwendungsanfrage und Beobachtungen von beiden Enden ab. Ein Allow-Ergebnis und ein korrekter nächster Hop sind zwei Beweisstücke, kein Beweis, dass die Verbindung erfolgreich war.