Eine stabile Registrierungsquelle für GET VPN-Mitglieder wählen

Jemand richtet die Registrierung des Gruppenmitglieds auf eine Loopback-Adresse und erklärt die Instabilität von GET VPN für gelöst. Manchmal stimmt das. Oft ist das Loopback nur aus der eigenen Routingtabelle des Mitglieds erreichbar und von sonst nirgendwo, sodass die Registrierung beim nächsten Flattern des Uplinks, der sie trug, wieder bricht. Die Registrierungsadresse ist eine Identität in der Steuerungsebene und hilft nur, wenn in beide Richtungen ein echter Pfad existiert. Sie bewusst zu wählen lohnt sich, und es ist eine kleinere Änderung, als das Gerede vermuten lässt.

Was die Registrierungsadresse kennzeichnet

In einer GDOI-Umgebung registriert sich das Gruppenmitglied beim Schlüsselserver und erhält von ihm die Gruppenrichtlinie. Die Adresse, die der Schlüsselserver festhält, ist die Identität des Mitglieds für dieses Gespräch.

Diese Identität umfasst das Steuerungsgespräch: Registrierung, Schlüsselwechsel und den Richtlinien-Download. Sie wird nicht zur Quelle des Kundenverkehrs, und sie ändert nicht, welche Schnittstellen welche Ströme schützen.

Beides getrennt zu halten ist der erste Schritt, denn die meiste Verwirrung um diese Einstellung entsteht aus der Erwartung, eine Änderung in der Steuerungsebene behebe ein Symptom in der Datenebene.

Ein Loopback ist nur so gut wie seine Route

Ein Loopback gibt dem Mitglied eine logische Adresse, die nicht verschwindet, wenn ein physischer Uplink ausfällt. Das ist ein echter Vorteil auf einem Router mit mehreren Wegen zum Schlüsselserver.

Es ist aber auch nur eine Adresse. Hat der Schlüsselserver keine Route zurück dorthin, scheitert die Registrierung genau wie zuvor. Erreicht die Routingtabelle des Mitglieds den Schlüsselserver nur über einen Uplink, ist das Loopback stabil und der Pfad nicht.

Prüfen Sie die Erreichbarkeit in beide Richtungen über jeden Uplink, der überleben soll. Ein Loopback, das administrativ oben bleibt, beweist nichts über die Weiterleitung, und der Fehler erscheint als nicht erreichbarer Schlüsselserver statt als Schnittstellenproblem. Schreiben Sie die Prüfung als Befehl pro Uplink, nicht als Annahme. Dann beginnt das nächste Änderungsfenster mit Belegen statt mit einem Diagramm.

Steuerung und geschützten Verkehr getrennt halten

Ciscos GDOI-Bypass-Leitfaden dokumentiert die Registrierungsschnittstelle und das Verhältnis zwischen Registrierung und Bypass-Behandlung. Lesen Sie das Verhalten für die Version, die Sie tatsächlich betreiben, statt einen Satz als allgemeingültigen Befehl zu behandeln.

Prüfen Sie Filterung und Übersetzung auf dem Steuerungspfad und stellen Sie sicher, dass der Schlüsselverwaltungsverkehr nicht versehentlich in eine Schutzrichtlinie gerät, die von genau der Gruppenrichtlinie abhängt, die er abzurufen versucht. Diese zirkuläre Abhängigkeit ist ein klassischer Weg, eine funktionierende Umgebung nach einer Richtlinienänderung scheitern zu lassen.

Die Richtlinie der Datenebene ist ein eigenes Design. Eine Änderung daran, woher die Registrierung kommt, lässt die geschützten Ströme, die Selektoren und die Bypass-Regeln genau dort, wo sie waren.

Identität im Übergang prüfen

Notieren Sie vor der Änderung die Gruppe, die gewählte Registrierungsadresse, das Ziel des Schlüsselservers, den Routing-Kontext und den erlaubten Steuerungspfad. Prüfen Sie nach einem genehmigten Uplink-Wechsel erneut die Ansicht der registrierten Mitglieder auf dem Schlüsselserver und den Steuerungszustand des Mitglieds.

Was Sie sehen wollen, ist der vorgesehene logische Endpunkt, weiterhin erreichbar und weiterhin so dargestellt, wie Sie ihn entworfen haben. Was Sie nicht wollen, ist eine zweite Registrierung von einer Adresse, die Sie nicht beabsichtigt haben, denn genau so entstehen doppelte Mitgliedseinträge.

Testen Sie danach geschützten Anwendungsverkehr für sich. Eine Übertragung kann gelingen, während der nächste Schlüsselwechsel keinen Weg mehr hat, und eine erfolgreiche Registrierung sagt nichts darüber aus, ob ein bestimmter Strom korrekt ausgewählt und geroutet wird.

Was eine stabile Quelle nicht behebt

Sie entfernt keine doppelten Mitgliedseinträge, die eine frühere Fehlkonfiguration erzeugt hat. Sie repariert keinen Fehlschlag beim Schlüsselwechsel, der durch eine Richtlinienabweichung zwischen Mitglied und Schlüsselserver entsteht. Sie übersteht keinen Ausfall eines physischen Pfades, der die einzige Route zum Schlüsselserver beseitigt hat.

Was sie tut, ist eine Variable zu entfernen: Die Identität ändert sich nicht mehr, wenn sich eine Uplink-Adresse ändert. Das ist gut zu haben, und es ist eine Zeile in einem Entwurf und nicht der ganze Entwurf.

Reihenfolge der Arbeit: den Steuerungspfad benennen, eine Adresse mit Route in beide Richtungen wählen, die Ansicht des Schlüsselservers bestätigen und dann geschützten Verkehr getrennt testen. Scheitert die Registrierung weiterhin, war das Loopback nie das Problem.