Azure S2S VPN verbunden, aber kein Datenverkehr: das IKE-Log lesen

Das Portal sagt Connected, der Tunnel hat einen Uptime-Zähler, und ein Trace von Ihrer virtuellen Maschine stirbt am zweiten Hop. Der Verbindungsstatus beschreibt die IKE- und IPsec-Aushandlung, nicht ob ein einzelnes Paket die Policy-Ebene auf einer der beiden Seiten überlebt. Zwei Fehler erklären die meisten dieser Tickets, und keiner von beiden wird durch eine geänderte Azure-Route behoben. Beide stehen bereits in dem Log, das das Gateway erzeugt hat, weshalb ich dort anfange und nicht in der Routentabelle.

Was Connected tatsächlich bescheinigt

Eine verbundene Site-to-Site-Verbindung bedeutet, dass Phase 1 und Phase 2 abgeschlossen sind und die Security Associations stehen. Das ist eine Aussage über die Aushandlung: Beide Peers einigten sich auf einen Vorschlag, tauschten Schlüssel aus und installierten das SA-Paar. Sie sagt nichts darüber, ob die Traffic Selectors zu den Subnetzen passen, die Sie für geschützt halten, und nichts darüber, ob die Gegenseite das Paket nach dem Entschlüsseln irgendwohin routet. Ein Tunnel kann wochenlang stehen und dabei jeden interessanten Fluss verwerfen, und genau dieses Muster bringt Leute dazu, ein gesundes Gateway neu aufzubauen.

Die beiden zuerst zu prüfenden Fehler sind ein Peer, der AH statt ESP anbietet, und ein virtuelles Netz, das in einem Bereich nummeriert ist, den das Gateway nicht als intern behandelt.

Öffnen Sie das exportierte Log, bevor Sie Routen anfassen

Öffnen Sie im Portal das Gateway des virtuellen Netzwerks und führen Sie den Vorgang VPN troubleshoot für die Verbindung aus, laden Sie dann das erzeugte Paket herunter und entpacken Sie es. Darin liegt ein IKE-Log mit den Phase-1- und Phase-2-Aushandlungen, mit Zeitstempeln und als Klartext lesbar. Suchen Sie darin nach der Zeile transform, statt von oben nach unten zu lesen, denn der interessante Eintrag steht meist ein paar hundert Zeilen weiter unten. Ohne Portalzugriff erscheint dieselbe Diagnose im Logziel des Gateways, sofern die Diagnoseeinstellungen aktiviert sind.

Zwei Einträge tragen den größten Teil des Werts. Der erste lautet ungefähr expected ESP with combined authentication and cipher, received AH. Der zweite ist ein Invalid-Payload-Fehler während der IKE-Aushandlung, was meist ein fehlerhaftes oder nicht unterstütztes Vorschlagsfeld bedeutet.

Beide beschreiben, was das lokale Gerät angeboten hat, also sind beide Einstellungen auf der Peer-Seite. Die Azure-Seite der Verbindung neu zu erzeugen ändert den Vorschlag nicht, den Ihre Firewall sendet, und es trotzdem zu tun ist die am häufigsten verschwendete Stunde in diesem Ablauf. Setzen Sie beim Peer Phase 2 auf ESP mit kombinierter Authentifizierung und Verschlüsselung und lassen Sie ihn den Algorithmus aushandeln, und prüfen Sie dann, ob ein Hersteller-Kontrollkästchen mit einem Namen wie combined mode still darunter einen AH-Vorschlag auswählt.

Bestätigen Sie den Adressraum des virtuellen Netzwerks

Das Gateway erwartet, dass das virtuelle Netz in privaten Bereichen liegt. Ein Netz, das in einem öffentlichen Block nummeriert ist, etwa eines, das mit 111.x beginnt, kann den Tunnel hochbringen, während Azure sich weigert, diesen Bereich als intern zu behandeln, sodass die Verbindung gesund aussieht und kein Fluss angenommen wird. Bestätigen Sie den Adressraum, bevor Sie einen Nachmittag mit Selektoren verbringen. Ist die Nummerierung eine harte Vorgabe aus einer älteren Zuteilung, ist die Lösung eine Änderung des Adressplans und nicht ein anderes Gateway.

Notieren Sie die Überschneidung mit den lokalen Bereichen, während Sie im Blatt für den Adressraum sind, denn überlappende Präfixe erzeugen einen anderen Fehler, der vom Client aus ähnlich aussieht.

Prüfen Sie die Präfixe in beide Richtungen

Die Ressource für das Gateway des lokalen Netzwerks enthält die lokalen Präfixe, und sie müssen zu den Subnetzen passen, die das entfernte Gerät tatsächlich schützt. Eine Zusammenfassung, die Adressen enthält, die das Gerät verwirft, lässt einige Flüsse durch und scheitert bei anderen, was wie ein sporadischer Routingfehler und nicht wie eine Fehlkonfiguration aussieht. Prüfen Sie auch die Gegenseite: Ein Ende listet ein /16, während das andere drei /24 darin listet — das ist der klassische Teilausfall. Keine der Listen ist für sich maßgeblich, vergleichen Sie sie daher nebeneinander, statt der zu trauen, die Sie sehen können.

Eine Präfixänderung wird nicht immer von selbst übernommen, also planen Sie ein erneutes Speichern oder Neuanlegen des Verbindungsobjekts ein und bestätigen Sie danach, dass die neuen Präfixe auf beiden Seiten erscheinen.

Testen Sie einen Pfad, keinen Ping

Der Trace, der einen funktionierenden Tunnel von einer funktionierenden Route unterscheidet, sieht so aus: Der erste Hop ist das lokale Gateway, dann einige nicht antwortende Hops, dann antwortet der entfernte Host. Erreicht der Trace den Host nie, testen Sie den TCP-Port, den die Anwendung tatsächlich nutzt, denn ICMP wird oft genug gefiltert, dass ein fehlgeschlagener Ping sehr wenig beweist. Führen Sie denselben Trace von einem entfernten Host zu einer virtuellen Maschine in Azure aus. Die Asymmetrie zwischen beiden Ergebnissen ist der schnellste Weg, eine fehlende Rückroute oder eine Regel zu finden, die nur eine Richtung erlaubt.

Schreiben Sie den Vorschlag des Peers, beide Adressräume und die Erstellungszeit der Verbindung ins Ticket, damit der nächste Engineer weiß, welche Werte neu aufgebaut und welche nie angefasst wurden.

Kommt das Log leer zurück, terminiert das Gateway Ihre Verbindung möglicherweise gar nicht. Bestätigen Sie, dass die Peer-Adresse im Gateway des lokalen Netzwerks zu dem Gerät passt, von dem Sie das Log lesen, denn zwei Gateways in einem Abonnement sind bei einem Neuaufbau leicht zu verwechseln. Dieser Fehler kostet einen Tag und hinterlässt in keinem Log eine Spur.