MAC stimmt in IKE nicht überein: Die Prüfung des gemeinsam genutzten Schlüssels ist fehlgeschlagen

Ihr Cloud VPN-Protokoll zeigt einen Versuch mit gemeinsam genutztem Schlüssel, gefolgt von MAC mismatched, und der erste Instinkt ist oft, ein Adressproblem zu suchen. In diesem Zweig ist MAC ein Nachrichtenauthentifizierungscode: ein Wert, der über den Austausch mit dem ausgehandelten Schlüssel berechnet wird. Der Peer verglich seine eigene Berechnung mit dem empfangenen Wert, und sie unterschieden sich. Keine Netzwerkkarte ist beteiligt, und keine Schnittstelleneinstellung ändert diesen Vergleich.

In der Praxis erzeugen ihn zwei Bedingungen: Die Geheimnisse an den beiden Enden sind nicht derselbe Wert, oder die Identitäten, mit denen das Geheimnis ausgewählt wird, stimmen nicht überein. Entscheiden Sie welche, indem Sie das Paar lesen, nicht den einzelnen Tunnel.

Was die Stufe beweist

Die Prüfung läuft, nachdem beide Seiten Anfangsparameter ausgetauscht und sich identifiziert haben. Sie wählt Kandidaten für gemeinsam genutzte Schlüssel für die lokale und die entfernte Identität und versucht, die empfangenen Authentifizierungsdaten zu validieren; wenn keine validiert, wird die Diagnose ausgegeben. Das ist eine starke Aussage über die Authentifizierung und eine schwache über die Ursache, denn sie sagt nicht, welche Seite falsch ist.

Früherer Erfolg überträgt sich nicht auf diese Prüfung. Ein abgeschlossenes IKE_SA_INIT oder eine NAT-Erkennungsnutzlast, die die erwarteten Werte zurückgab, beweist, dass die Peers miteinander sprechen können. Es beweist nichts darüber, ob sie ein Geheimnis teilen.

Zwei Konfigurationsfehler, eine Meldung

Der erste ist eine echte Geheimnisabweichung, und sie ist meist ein Bereitstellungsunfall: ein generierter Wert, der auf einer Konsole installiert und auf der anderen neu getippt wurde, ein nachgestelltes Zeichen, das auf einer Seite überlebte, oder ein Anführungszeichen, das mit einem Einfügen kam. Der zweite ist eine Identitätsabweichung, bei der das Geheimnis korrekt ist, aber die vom Peer vorgelegte Identität einen anderen Eintrag auswählt, sodass das richtige Geheimnis nie versucht wird. Beide erzeugen dieselbe Zeile, deshalb kostet Raten einen Nachmittag.

Vergleichen Sie das Paar, bevor Sie ein Geheimnis anfassen. Gleichen Sie den Tunnel, den Peer-Endpunkt, das Zeitfenster und die entfernte Konfiguration ab, denn zwei redundante Tunnel können unterschiedliche Geheimnisse halten, und der Bildschirm vor Ihnen ist vielleicht nicht der, der ausgefallen ist.

NAT-Erkennung ist eine andere Stufe

NAT-Erkennung fragt, wie Pakete umgeschrieben werden, nicht wer der Peer ist. Ein Kundengateway hinter NAT authentifiziert sich weiterhin korrekt, wenn seine konfigurierte Identität die ist, die der Peer erwartet, und ein NAT-Problem zeigt sich als Abweichung bei Vorschlag oder Port statt als fehlgeschlagener Authentifizierungsvergleich.

Tragen Sie keine alte Aussage über eine Anbieterversion in eine aktuelle Bereitstellung. Was NAT-Traversierung in Ihrer Version erfordert, gehört in ihre eigene Dokumentation, und der Ausdruck MAC mismatch ist kein Beweis dafür oder dagegen.

Entscheiden Sie anhand des Paares, nicht des Bildschirms

Lesen Sie beide Konfigurationen nebeneinander mit geschwärztem Geheimnis und stellen Sie dann drei Fragen. Ist die Identität auf jeder Seite genau das, was die andere erwartet, Zeichen für Zeichen? Verwenden beide Enden dieselbe IKE-Version und dieselbe Authentifizierungsmethode? Entspricht der fehlschlagende Tunnel der Konfiguration, die Sie lesen? Ein Nein auf eine davon entscheidet die Reparatur, ohne das Geheimnis anzufassen.

Wenn alle drei sauber sind, ersetzen Sie das Geheimnis über den genehmigten Arbeitsablauf, statt darum herum zu editieren.

Nachdem der Peer authentifiziert

Sobald die Authentifizierung gelingt, ist die nächste Fehlerfläche die untergeordnete Sicherheitsassoziation: Vorschläge und Traffic-Selektoren. Das Rotieren eines bereits akzeptierten Geheimnisses kann einen untergeordneten Fehler nicht beheben und verlängert die Ausfallzeit. Lesen Sie den untergeordneten Zustand, dann die Selektoren und geschützten Bereiche auf beiden Seiten, und gleichen Sie die Anleitung zur Cloud VPN-Fehlerbehebung mit der Stufe ab, die tatsächlich fehlgeschlagen ist.

Korrelieren Sie frische Protokolle von beiden Enden für dasselbe Paar und dasselbe Zeitfenster. Eine Seite allein liefert ein Urteil ohne die Eingabe der anderen, und genau diese Mehrdeutigkeit hat die Meldung ursprünglich erzeugt.

Was nicht zu schließen ist

Lesen Sie die Meldung nicht als Aufforderung, MAC-Adressen zu ändern, und veröffentlichen Sie das gemeinsame Geheimnis nicht, während Sie um Hilfe bitten; ein Auszug mit dem Schlüssel braucht den entfernten Schlüssel, nicht das aufbewahrte Protokoll. Nehmen Sie auch keinen Routingfehler an, denn Peers, die einander nicht erreichen können, erzeugen überhaupt keinen Authentifizierungsvergleich. Und verallgemeinern Sie eine dokumentierte Einschränkung einer Produktfamilie nicht auf jede IPsec-Implementierung.

Notieren Sie das fehlschlagende Paar, den Tunnelzustand vorher und nachher und welche der beiden Bedingungen Sie geändert haben. Diese Aufzeichnung macht den nächsten Vorfall zu einer Fünf-Minuten-Prüfung.