strongSwan EAP: IKE-Identität gegen den erwarteten AAA-Namen

Ein strongSwan-EAP-Client kann zwei Servernamen prüfen. remote.id deckt das IKE-Gateway ab, local.aaa_id den EAP-Server; beides sind nicht dasselbe Feld.

EAP-Authentifizierung über IKEv2 kann von einem Client verlangen, zwei verschiedene Servernamen in einer Verbindung zu prüfen. Das Gateway, das IKE beendet, zeigt eine Identität, und das EAP-Backend, das den inneren TLS-Austausch beendet, kann eine andere zeigen. In strongSwan liegen sie in verschiedenen Konfigurationsblöcken, und ein Name im falschen Block erzeugt einen Fehler, der wie ein Zertifikatsproblem aussieht. Erst das Lesen, welche Prüfung fehlgeschlagen ist, sagt Ihnen, welchen Block Sie ändern müssen.

Eine Verbindung, zwei Serveridentitäten

Die erste Identität gehört zum IKE-Austausch. Der Client wählt eine Adresse und erwartet, dass die Gegenseite eine bestimmte Identität nachweist, meist den Namen im Gateway-Zertifikat.

Die zweite gehört zu EAP. Bei PEAP oder TTLS baut der Client einen TLS-Tunnel zum Authentifizierungsserver innerhalb der IKE SA, und dieser innere Server zeigt sein eigenes Zertifikat. Ist das Backend ein eigener Host, unterscheidet sich sein Name von dem des Gateways. Ein Client, der nur den ersten Namen prüft, akzeptiert, was der zweite behauptet. Ein Client mit einem Namen an beiden Stellen scheitert, sobald die beiden wirklich abweichen.

Beide Namen stammen aus der Konfiguration des Betreibers und nicht aus dem Zertifikat, das den Fehler verschwinden lässt. Den Betreiber nach den Bereitstellungsdetails zu fragen ist schneller, als zwei Hostnamen zu raten.

Welches Feld zu welcher Schicht gehört

In swanctl sind Adresse und IKE-Identität getrennte Einstellungen, und die EAP-Identität ist eine dritte.

Die Remote-Adresse bestimmt, wohin Pakete gehen, und die Remote-Identität gibt an, was die Gegenseite nachweisen muss. Die EAP-Erwartung steht unter dem local-Block, weil sie den EAP-Austausch dieses Clients beschreibt und nicht das IKE-Verhalten der Gegenseite. Genau diese Platzierung wird falsch gelesen. Der Name steht in der Konfiguration des Clients und beschreibt doch einen Server, weshalb er fehl am Platz wirkt.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Dieses Fragment ist keine vollständige Verbindung; Vertrauensmaterial, Anmeldedaten und Richtlinien für Kindverbindungen müssen noch vorhanden sein. Wer es wörtlich in eine laufende Datei kopiert, ersetzt Einstellungen, die weiterhin gebraucht werden.

Warum aaa_id unter local steht

Der local-Block beschreibt, was diese Seite während der Authentifizierung tut, einschließlich der Methode, die sie verwendet, und der Identität, die sie für diese Methode von der Gegenseite erwartet. Nichts darin behauptet, der AAA-Server laufe auf derselben Maschine.

Der Standard macht die Falle schärfer. Ist kein ausdrücklicher Wert gesetzt, folgt die erwartete AAA-Identität der Remote-Identität, sodass eine Bereitstellung mit einem Namen funktioniert und den Unterschied verdeckt. Ein ausdrücklicher Wert zählt nur, wenn die EAP-Bereitstellung wirklich anderswo endet. Ihn ohne diesen Grund auf einen anderen Namen zu setzen, erzeugt einen Fehler, den der Betreiber nicht reproduzieren kann. Lesen Sie die Bereitstellung, bevor Sie einen zweiten Namen erfinden.

Halten Sie den Wert identisch mit dem, was das Backend-Zertifikat tatsächlich behauptet, einschließlich der Form des Namens. Ein abschließender Punkt oder ein Platzhalter, der den Host nicht abdeckt, genügt, damit die Prüfung scheitert.

Frontends, die die Trennung nicht ausdrücken können

Ein NetworkManager-Profil ist nicht dieselbe Konfigurationsschnittstelle wie swanctl. Das Plugin dahinter bietet einen schmaleren Satz an Identitätssteuerungen, und welche existieren, hängt von der installierten Version ab.

Das zählt, wenn die Bereitstellung wirklich zwei Namen braucht. Ein als Serveridentität bezeichnetes Feld kann eine Schicht konfigurieren und die andere nicht, sodass ein Profil korrekt aussieht und dennoch an der inneren Prüfung scheitert. Prüfen Sie, was das installierte Plugin unterstützt, bevor Sie annehmen, das Profil könne die Anordnung ausdrücken. Kann es das nicht, liegt die Wahl beim Betreiber: ein anderer Bereitstellungsweg oder ein korrigiertes Design der Serveridentität. PEAP abzuschwächen oder jeden Namen zu akzeptieren ändert die Authentifizierungsrichtlinie, statt sie zu reparieren.

Die Alternative ist nichts, was man auf dem Client erfindet. Verlangen Sie die unterstützte Anordnung schriftlich und bewahren Sie diese Antwort beim Profil auf.

Unterscheiden Sie Identitätskonflikt von abgelaufenem Zertifikat

Eine Namensabweichung und ein abgelaufenes Zertifikat sind verschiedene Fehler, und das Protokoll unterscheidet sie. Lesen Sie die Meldung, bevor Sie entscheiden, welches Feld zu ändern ist.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

Die beabsichtigte AAA-Identität zu setzen erneuert kein Zertifikat und begründet kein Vertrauen in dessen Aussteller, und ein Zertifikat zu erneuern korrigiert keinen falschen erwarteten Namen. Lesen Sie, welche Prüfung fehlgeschlagen ist, bevor Sie ein weiteres Identitätsfeld ändern. Laden Sie dann die Konfiguration neu und bestätigen Sie, dass die geladene Verbindung den gesetzten Wert zeigt, denn eine bearbeitete Datei, die nie geladen wurde, ändert nichts. Schreiben Sie beide Namen und ihre Schichten in die Bereitstellungsnotizen.

Ähnliche Artikel