Eingehender IPsec-Peer passt zu keinem Profil? Vier Felder prüfen

Ihr Peer meldet, der Tunnel sei aufgebaut, Ihre Seite zeigt keine Sicherheitsassoziation, und die Konfigurationsdatei enthält eindeutig einen passenden Verbindungsnamen. Alle drei Aussagen können gleichzeitig zutreffen. Eine eingehende Verhandlung wird mit der laufenden Konfiguration abgeglichen, anhand der Adresse des Peers, der vorgelegten Identität und des vorgeschlagenen Verkehrs. Eine Datei auf der Platte, die nie geladen wurde, eine Identität, die nicht dem erwarteten Wert entspricht, oder ein Selektorpaar, das um ein Präfix danebenliegt — jedes davon erzeugt Stille. Gehen Sie die vier Feldgruppen in der Reihenfolge durch, die der Responder einhält.

Beginnen Sie beim Paket, nicht bei der Datei

Der Responder empfängt eine IKE-Anfrage, sucht eine Definition, die diesen Peer annehmen kann, und fährt dann mit Authentifizierung und Verkehrsauswahl fort. Wenn im ersten Schritt keine geladene Definition passt, endet die Verhandlung, bevor ein brauchbarer Fehler den Benutzer erreicht.

Deshalb ist „die Konfiguration sieht richtig aus“ kein Beweis. Die Frage ist, was der laufende Dienst geladen hat und welchen Eintrag er für diesen Versuch ausgewählt hat. Eine Statusauflistung beantwortet das mit einem Befehl, während ein Editor-Puffer eine andere Frage beantwortet. Prüfen Sie die Auflistung, bevor Sie die Datei erneut ändern.

Erste Feldgruppe: die Definition, die tatsächlich geladen ist

Prüfen Sie den laufenden Zustand mit dem Werkzeug, das den Daemon besitzt: ein Statusbefehl, der geladene Verbindungen auflistet, nicht der Editor-Puffer. Bestätigen Sie, dass der erwartete Eintrag vorhanden, für das gewünschte Startverhalten aktiviert und nach Ihrer letzten Änderung geladen wurde. Eine gespeicherte Datei, die nicht neu geladen wurde, ist die häufigste Ursache für „ich habe es korrigiert, und nichts hat sich geändert“.

Bestätigen Sie außerdem, welche Datei der Dienst liest. Distributionen unterscheiden sich, und eine Verbindung, die in den falschen Include geschrieben wurde, wird stillschweigend ignoriert statt abgelehnt. Wenn die Statusauflistung Ihren Eintrag überhaupt nicht zeigt, verdächtigen Sie den Include-Pfad, bevor Sie die Syntax verdächtigen.

Zweite Feldgruppe: Endpunkte sind keine Identitäten

Die Adresse, von der der Peer sich verbindet, und die Identität, mit der er sich authentifiziert, sind getrennte Felder. Ein Hostname, ein Distinguished Name, eine Schlüssel-ID und eine Adresse können je nach Konfiguration alle als IKE-Identität dienen, und sie müssen keineswegs wie die öffentliche Adresse aussehen.

Die Endpunktzuordnung kann auch eine NAT-Sicht umfassen: Die auf dem Draht gesehene Adresse kann von der Adresse abweichen, die der Peer für seine hält. Im Verbindungsmodell von libreswan sind left und right Bezeichnungen für die beiden Teilnehmer und keine feste Reihenfolge von lokal und entfernt; deshalb ist das Kopieren einer funktionierenden Konfiguration von einem anderen Standort mit vertauschten Adressen keine verlässliche Übertragung.

Notieren Sie die erwartete Identität beider Seiten und das Nachweismittel, das sie bestätigt. Wenn diese beiden Zeilen nicht übereinstimmen, wird kein noch so großes Adressieren einen Treffer erzeugen.

Dritte Feldgruppe: der Verkehr, der geschützt wird

Selektoren beschreiben die inneren Quell- und Zielbereiche, ihre Adressfamilie und jede Protokoll- oder Portbeschränkung. Ein Vorschlag für eine einzelne Hostadresse ist nicht dieselbe Anfrage wie für ein ganzes Subnetz, und ein für das Subnetz konfigurierter Responder kann ihn ablehnen oder verengen.

Wenn die beiden Enden nicht übereinstimmen, vergleichen Sie den beabsichtigten Fluss aus beiden Blickwinkeln, statt jeden Selektor zu erweitern, damit irgendetwas sich verbindet. Fragen Sie jeden Administrator nach dem Fluss, den er zu schützen glaubt, und vergleichen Sie dann die beiden Antworten. Die Abweichung ist meist ein Host-Präfix auf der einen und ein Subnetz auf der anderen Seite. Ein Tunnel, der passt, weil er jetzt alles schützt, ist eine andere Sicherheitsentscheidung, und eine, die niemand genehmigt hat.

Vierte Feldgruppe: Sie lesen eine Implementierung

Libreswan, das ältere Openswan und strongSwan haben unterschiedliche Verwaltungswerkzeuge, unterschiedliche Konfigurationssyntax und unterschiedliche Zuordnungsreihenfolge. Ein funktionierendes Beispiel des einen sagt nichts Genaueres über die Profilauswahlpriorität oder die Fehlerformulierung des anderen, prüfen Sie daher mit der Dokumentation für den Daemon auf diesem Host.

Verknüpfen Sie einen Versuch von Anfang bis Ende: die Quelladresse des Initiators, die angebotene Identität und die vorgeschlagenen Selektoren — gegen die Auswahlmeldung des Responders und den geladenen Eintrag, den sie nennt. Zähler von null bei Kapselung und Entkapselung besagen nur, dass die beobachteten Assoziationen diese Pakete nicht befördert haben; sie benennen weder den Endpunkt, der den Vorschlag abgelehnt hat, noch beweisen sie, dass in diesem Moment ein passender Eintrag existierte.

Bestätigen Sie nach einer abgestimmten Korrektur das ausgewählte Profil und die Assoziation und testen Sie dann den tatsächlich erlaubten Dienst und seinen Antwortpfad. Ein Profiltreffer ermöglicht die Verhandlung, und die Verhandlung ist nicht die letzte Zugriffsprüfung.