Warum RADIUS eine IP-Adresse statt des VPN-Benutzernamens sieht

strongSwan kann die IKE-Identität in RADIUS User-Name eintragen, bevor ein EAP-Austausch stattfindet. Legen Sie fest, wer die Kontoidentität anfragt, und gleichen Sie dann einen Versuch ab.

Ein Windows-IKEv2-Client verbindet sich, und die RADIUS-Anfrage kommt mit einer Adresse an, wo der Kontoname stehen sollte. Noch ist nichts fehlgeschlagen, und genau das verwirrt: Das Gateway meldet die Identität, die der Client auf der IKE-Ebene vorgelegt hat. Der Benutzername, den Ihr Backend erwartet, stammt möglicherweise aus einem separaten EAP-Austausch, der noch nicht stattgefunden hat. Legen Sie fest, wer ihn anfragt, bevor Sie das Konto ändern.

Zwei Identitäten reisen in einer Verbindung

In einer Verbindung können zwei Namen auftreten. Die IKE-Identität kennzeichnet den Peer beim Tunnelaufbau, und das eap-radius-Plugin kopiert sie zunächst in RADIUS User-Name. Die EAP-Identität ist ein anderer Wert, der für die Benutzerauthentifizierung dient, und sie wird möglicherweise nie gesendet, wenn niemand sie anfragt.

Deshalb kann das RADIUS-Protokoll eine Adresse zeigen, obwohl das Konto existiert und das Passwort korrekt ist. Das Backend wird zur falschen Ebene befragt. Das RADIUS-Attribut ist nur der Transport für den jeweils gewählten Namen.

Lassen Sie das Gateway eine EAP-Identität anfordern

Eine unterstützte Anordnung lässt das Gateway die EAP-Identität anfordern, bevor es die Authentifizierung an RADIUS übergibt. Im Abschnitt für die Remote-Authentifizierung der Verbindung setzen Sie die Methode auf eap-radius und fordern die EAP-Identität ausdrücklich an. Das folgende Fragment gehört in einen bestehenden Verbindungsblock, nicht in eine eigene Datei. Prüfen Sie die Verbindung und das Konfigurations-Backend, bevor Sie die Syntax aus einer anderen Umgebung kopieren.

remote {
    auth = eap-radius
    eap_id = %any
}

Damit erhält das Backend die Identität, die der Client im EAP-Austausch liefert, statt der IKE-Adresse. Sonst ändert sich an der Verbindung nichts.

Oder lassen Sie RADIUS den EAP-Austausch beginnen

Die andere Anordnung legt den ersten Zug auf die RADIUS-Seite. Das Plugin kann eine EAP-Start-Anzeige senden, statt auf eine erste Identitätsantwort zu warten, wodurch der Server den Austausch steuert. Das ist eine Konfiguration auf Plugin-Ebene, sie betrifft also jede Verbindung, die das Plugin nutzt.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

Wählen Sie eine Anordnung mit dem RADIUS-Betreiber, statt beide zu aktivieren und zu hoffen. Sie beschreiben unterschiedliche Abläufe, und ein Server, der selbst beginnen will, kommt nicht unbedingt mit einem Gateway zurecht, das das Gespräch eröffnet. Die Plugin-Dokumentation beschreibt beides, einschließlich der Identität, die jeder Schritt trägt.

Verfolgen Sie einen Versuch in beiden Protokollen

Gleichen Sie einen einzelnen Versuch über beide Protokolle ab. Beobachten Sie die IKE-Identität, dann ob ein EAP-Identity-Austausch stattfindet, und dann, welchen Namen der Authentifizierungsschritt erhält. Ein Backend, das die Adresse vor dem EAP-Austausch ablehnt, kann den Vorgang beenden, bevor Ihre beabsichtigte Identität je zu sehen ist.

journalctl -u strongswan -f

Behalten Sie das genaue Benutzernamenformat bei, das das Identitätssystem erwartet, einschließlich des Domänenpräfixes. Erfinden Sie niemals ein Konto aus einem adressförmigen Wert, und schalten Sie die Authentifizierung nie ab, um eine Richtlinienregel zu erfüllen. Eine EAP-Identität ist ein behaupteter Name, und die Methode muss ihn trotzdem nachweisen. Tragen Sie den resultierenden Namen in den Testdatensatz ein, damit der nächste Versuch von einem bekannten Zustand ausgeht.

Wenn der korrigierte Ablauf das richtige Konto erreicht und trotzdem abgelehnt wird, sind die nächsten Belege die EAP-Methode und die Backend-Richtlinie, nicht die Identität. Das Wiederholen einer Passwortzurücksetzung kann einen Wert nicht reparieren, der auf einer früheren Protokollebene gewählt wurde.

Ähnliche Artikel