Fünf Adressrollen in einem IPsec-Profil – und welche davon falsch ist

Fünf verschiedene Aufgaben bekommen in einer typischen Verbindungsdefinition eine Adresse, und sie müssen nicht übereinstimmen. Administratoren bleiben hängen, weil ein vernünftiger Instinkt, nämlich alle Felder auf denselben Host zeigen zu lassen, für mindestens drei davon falsch ist. Der Ausweg besteht darin, zuerst das Symptom zu benennen und dann die ein oder zwei Felder anzusehen, die es erzeugen könnten.

Die fünf Aufgaben, in der Reihenfolge ihrer Bedeutung

Der Transportendpunkt ist der Ort, an dem der IKE-Austausch zugestellt wird. Die authentifizierte Identität ist der Name, den jede Seite beweist, und sie wird gegen die Richtlinie geprüft und nicht gegen eine Routingtabelle. Die geschützten Subnetze sind die Selektoren, die entscheiden, welcher innere Datenverkehr zum Tunnel gehört. Dann gibt es die Quelle, die verwendet wird, wenn das Gateway selbst ein Gespräch beginnt, und schließlich den nächsten Hop des Underlays, um den Peer zu erreichen.

Teilnehmerbezeichnungen wie left und right sind Konventionen für die beiden Seiten einer Verbindung, keine Synonyme für lokal und entfernt. Lesen Sie das Handbuch der tatsächlich installierten Implementierung, bevor Sie annehmen, ein Schlüssel bedeute das, was ein anderes Produkt darunter verstand.

Entscheidung eins: nichts kommt zustande

Wenn in den Protokollen überhaupt kein Austausch erscheint, ist der Endpunkt der erste Verdächtige: eine falsche Adresse, ein gefilterter Pfad oder eine Schnittstelle, auf der der Daemon nicht lauscht. Wechseln Sie erst zu den Identitätsfeldern, wenn ein Handshake sichtbar ist, denn die Identität wird innerhalb des Austauschs beurteilt, nicht davor. Ein gefilterter Pfad und eine falsche Adresse sehen vom Client aus identisch aus, prüfen Sie also die lauschende Seite, bevor Sie etwas bearbeiten. Bestätigen Sie, dass der Daemon an die erwartete Schnittstelle gebunden ist, denn ein Dienst, der auf einer Adresse lauscht, sieht genauso aus wie ein blockierter Pfad.

Eine öffentliche Adresse, die durch Übersetzung beobachtet wird, ist nicht dasselbe wie die Identität, die ein Peer beweist. Eine Adresse zu ändern, damit sie zu dem passt, was ein Paketmitschnitt am fernen Ende zeigt, ist eine häufige und falsche Korrektur.

Entscheidung zwei: der Tunnel steht und der Verkehr stirbt

Selektoren entscheiden, was in den Tunnel gelangt, und eine Abweichung hier erzeugt eine Verbindung, die erfolgreich verhandelt, während die Anwendung weiterhin scheitert. Die Gegenseite muss Ihren geschützten Bereich als ihren entfernten Bereich benennen, und genau dort schleichen sich vertauschte Werte ein.

Lesen Sie beide Konfigurationen nebeneinander, bevor Sie bearbeiten. Der lokale Bereich auf dem einen Host ist der entfernte Bereich auf dem anderen, und ein einziges vertauschtes Paar erklärt einen Tunnel, der nichts befördert. Verengen Sie das Paar, bevor Sie die Schlüssel anfassen: ein Subnetz innerhalb des Tunnels und eines außerhalb sagt Ihnen, ob der Selektor oder das Routing schuld ist.

Entscheidung drei: nur der eigene Verkehr des Gateways scheitert

Für Clients weitergeleiteter Verkehr kann einwandfrei funktionieren, während eine Anfrage, die das Gateway selbst beginnt, scheitert, weil dieser Fluss keine Client-Quelle hat, die er erben könnte. Die Einstellung für die bevorzugte Quelle existiert genau für diesen Fall, und sie ist keine Quellübersetzung: Sie wählt eine Quelladresse aus, statt eine umzuschreiben.

Eine Anwendung, die ausdrücklich eine andere Adresse bindet, kann die Präferenz außer Kraft setzen, bestätigen Sie also die tatsächliche Quelle des Pakets, bevor Sie schließen, dass die Einstellung ignoriert wird. Zeichnen Sie an der eigenen Schnittstelle des Gateways auf, statt der Absicht der Konfiguration zu vertrauen.

Der nächste Hop ist eine lokale Anweisung

Der nächste Hop des Underlays sagt diesem Host, wie er den Peer erreicht, und die Gegenseite braucht nicht denselben Wert. Ihn als gemeinsame Einstellung zu behandeln oder ein Standardgateway fest zu verdrahten, bricht in dem Moment, in dem sich die Route ändert oder ein zweiter Pfad auftaucht.

Manche Implementierungen bieten hier besondere Werte an. Was das Handbuch für die installierte Version auflistet, ist die einzig sichere Antwort, und die lokale Routingtabelle ist der Beweis, dass es funktioniert hat. Wenn ein Peer über den Namen, aber nicht über die Adresse erreichbar ist, ist diese Abweichung der Befund und kein Detail, um das man herumarbeitet.

Lesen Sie das Profil von beiden Enden

Die Rollen auf dem Papier zu vertauschen ist die schnellste Überprüfung, die es gibt: Tauschen Sie die geschützten Bereiche, behalten Sie den eigenen nächsten Hop jeder Seite und die eigene Identität jeder Seite. Alles, was den Tausch nicht übersteht, ist wahrscheinlich der falschen Aufgabe zugeordnet.

Testen Sie dann einen Fluss pro Rolle: Erreichbarkeit zwischen Peers, einen inneren Client-Fluss und eine vom Gateway ausgehende Anfrage. Drei Tests sagen Ihnen, welche Aufgabe falsch zugeordnet ist, ohne die Konfiguration erneut zu öffnen. Fügen Sie das Ergebnis im Ticket neben dem Feld hinzu, das Sie geändert haben, denn der nächste Ingenieur trifft dasselbe Profil an.