GDOI: Warum der Schlüsselserver nicht auf Ihrem Datenpfad liegt

Der Gruppen-Schlüsselserver verteilt Richtlinien und Schlüssel an Mitglieder, und die Mitglieder schützen den Verkehr selbst. Dieser Satz klingt wie eine Formalität, bis ein Entwurf den Controller als Relay für jedes geschützte Paket behandelt; dann bekommt die Topologie einen Hop, den sie nie brauchte, und der Verkehrspfad hängt von einem Gerät ab, das nur Zustand ausgeben sollte. Zu sagen, wo der Schlüsselserver sitzt, und zu sagen, wohin die Daten fließen, sind zwei verschiedene Diagramme, und GDOI ist genau um diesen Unterschied herum gebaut. Es umzudrehen ist kein kleiner Modellierungsfehler, denn es ändert, was Sie überwachen und was Sie skalieren. Die folgenden Abschnitte folgen der Aufteilung des Protokolls selbst.

Zwei Arten von Sicherheitszustand

RFC 6407 definiert den Pull-Austausch des Mitglieds zum Anfordern von Richtlinie und Schlüsselmaterial sowie einen Push-Austausch, der Richtlinie und Schlüsselaktualisierungen an autorisierte Mitglieder verteilt. Beide verwalten Sicherheitsassoziationen. Keiner davon ist der Datenstrom der Anwendung, also beweist ein erfolgreicher Austausch nur, dass der Steuerkanal funktioniert hat. Ein Mitglied kann sich sauber registrieren, gültige Schlüssel halten und den Verkehr trotzdem nicht schützen oder weiterleiten, wenn seine Datenrichtlinie falsch ist. Die beiden Fehler sehen völlig unterschiedlich aus, sobald man weiß, welcher Austausch welchen trägt.

Der Standard benennt außerdem eine Rekey-Sicherheitsassoziation, die Schlüsselaktualisierungsnachrichten schützt, getrennt von den Datensicherheitsassoziationen, die beschreiben, wie Mitglieder Verkehr schützen.

Folgen Sie den Austauschen, nicht dem Diagramm

Schauen Sie, wofür jede Nachricht da ist. Eine Registrierung sagt dem Controller, welches Mitglied fragt, und legt Zustand an; eine Rekey-Nachricht sagt den Mitgliedern, dass sich Richtlinie oder Schlüssel geändert haben; danach fließt geschützter Anwendungsverkehr zwischen den Mitgliedern über die installierte Datensicherheitsassoziation. Die Adresse des Controllers erscheint in den ersten beiden und muss in der dritten überhaupt nicht auftauchen.

Deshalb ein nach physischer Nachbarschaft gezeichnetes Schnittstellendiagramm hier in die Irre führt. Die Schnittstelle des Controllers ist eine Steuerquelle, nicht automatisch der nächste Hop für jedes verschlüsselte Paket.

Drei Aufzeichnungen, die es sich zu behalten lohnt

Notieren Sie die authentifizierte Registrierung des Mitglieds und die Steuerquelle, die es erreichen kann, den Pfad, der spätere Schlüsselaktualisierungen zustellt, sowie die Routen und Anbindungen, die geschützten Anwendungsverkehr tragen. Drei Aufzeichnungen, drei Eigentümer, und ein Fehler in einer davon erzeugt ein anderes Symptom. Ein Mitglied, das sich registriert und dann nie eine Aktualisierung erhält, sieht identisch aus wie eines, das sich mit veralteter Richtlinie registriert hat, es sei denn, Sie haben beide Aufzeichnungen.

Bewahren Sie dies neben der Konfiguration auf und nicht im Gedächtnis von jemandem. Mitgliedschaftsänderungen sind so selten, dass die Begründung immer verschwunden ist, wenn sie gebraucht wird.

Schnittstelle, Dienstbindung, Verarbeitungspfad

Auf einem dienstbasierten Gateway gibt es eine weitere Unterscheidung: Die physische Underlay-Adresse ist nicht dasselbe wie die lokale Dienstbindung, und die Implementierung der Plattform entscheidet, wie Verkehr ihren IPsec-Verarbeitungspfad erreicht. Einen Dienst auf eine physische Schnittstelle zu verschieben oder eine unzusammenhängende Übersetzung hinzuzufügen, weil eine Fehlermeldung eine Dienstschnittstellen-Regel erwähnte, ist eine Vermutung im Gewand einer Reparatur.

Lesen Sie die eigene Dokumentation der Plattform dazu, wie die Dienstbindung Verkehr empfängt. Der Mechanismus ist herstellerspezifisch, selbst wenn das Protokoll Standard ist.

Standardisierte Protokollnachrichten begründen auch keine herstellerübergreifende Kompatibilität. Vergleichen Sie erforderliche Funktionen, Richtlinien- und Assoziationsattribute, Authentifizierungsmethode sowie die genaue Plattform und Version, bevor Sie annehmen, dass zwei Implementierungen interoperieren.

Steuerverfügbarkeit und Datenweiterleitung sind getrennte Prüfungen

Planen Sie die Erreichbarkeit des Controllers für den Normalbetrieb, für Mitgliedschaftsänderungen und für Schlüsselaktualisierungen. Ein Anwendungsaustausch, der auf bereits installiertem Zustand gelingt, beweist nicht, dass die nächste Registrierung oder Rekey das Mitglied erreicht, und die Lücke zeigt sich typischerweise Stunden später als ein Tunnel, der keine neuen Mitglieder mehr annimmt. Testen Sie eine frische Registrierung, nicht nur eine funktionierende Sitzung.

Testen Sie dann die Weiterleitung getrennt, mit dem Controller außen vor. Zwei Prüfungen, zwei Ergebnisse und eine viel kürzere Diskussion darüber, welche Hälfte kaputt ist.