EAP über ein VPN-Gateway: Wer die Methode beendet

Support-Tickets beschreiben eine fehlgeschlagene VPN-Anmeldung und eine RADIUS-Richtlinie, die eine stärkere Methode verlangt, als wären es dasselbe Problem, und das sind sie nicht. Das Gateway nimmt entweder Anmeldedaten an und leitet sie weiter, oder es führt ein EAP-Gespräch zwischen Client und Authentifizierungsserver. Was davon geschieht, entscheidet, ob eine Änderung auf Serverseite überhaupt etwas beheben kann. Lesen Sie den Austausch, bevor Sie die Servergruppe bearbeiten.

Zwei Authentifizierungswege, die im Protokoll gleich aussehen

Im ersten Weg sammelt das VPN-Gateway Benutzername und Kennwort und sendet eine RADIUS Access-Request mit einem Kennwortattribut. Der Authentifizierungsserver vergleicht sie mit seinem Speicher und antwortet mit Annahme oder Ablehnung. Der Client führt nie eine EAP-Methode aus, weil ihn niemand darum gebeten hat.

Im zweiten Weg führen Client und Authentifizierungsserver die EAP-Methode durchgängig aus, und das Gateway leitet EAP-Message-Attribute zwischen ihnen weiter. Das Gateway beendet weiterhin das äußere RADIUS-Gespräch, aber die Methodenlogik liegt an beiden Endpunkten.

Beide Wege erzeugen eine Protokollzeile, die besagt, dass die Authentifizierung fehlgeschlagen ist. Nur der zweite kann davon abhängen, welche EAP-Methode der Server bevorzugt, und nur der erste davon, wie das Gateway das Kennwort liest. Sie als austauschbar zu behandeln, ist der Grund, warum Teams einen Tag damit verbringen, Servergruppen für einen Client zu ändern, der nie PEAP sprechen würde.

Wo die Methode tatsächlich läuft

RFC 3579 definiert die Durchleitungsanordnung: Der NAS trägt EAP-Pakete in RADIUS-Attributen und braucht keinen methodenspezifischen Code für jeden EAP-Typ. Deshalb kann ein Gateway PEAP und EAP-TLS unterstützen, ohne eine davon zu implementieren.

Ein Gateway, das ein Kennwort übermittelt, trägt kein PEAP, selbst wenn das Backend PEAP von einem anderen Client annehmen würde. PEAP in der Serverrichtlinie zu aktivieren, fügt einem Client keine Methode hinzu, der nie eine angeboten hat.

PPP-Authentifizierungseinstellungen gehören zum PPP-Dienst. Sie konfigurieren nicht still jeden IPsec- oder alten XAuth-Pfad um, der denselben AAA-Server nutzt, sodass eine Änderung, die für einen Zugangstyp funktioniert, den anderen unberührt lassen kann.

Was der NAS unterstützen muss

Die Durchleitung verlagert die Anforderung vom Methodencode auf die Trägerunterstützung. Das Gateway muss EAP über sein VPN-Protokoll tragen können, und der RADIUS-Client darauf muss EAP-Message-Attribute der betreffenden Größen senden und empfangen können.

Bei IKEv2 ist EAP Teil eines definierten Authentifizierungsablaufs, und die Identitäts- und Vertrauensprüfungen des Servers stammen aus diesem Ablauf. Ein aus einer 802.1X-Bereitstellung entlehntes PEAP-Label überträgt sich nicht automatisch, weil die Verhandlung darum anders ist.

Auch die Clientseite hat Anforderungen. Sie muss für die Methode konfiguriert sein, dem Serverzertifikat vertrauen, das die Methode vorlegt, und Anmeldedaten besitzen, die die Methode nutzen kann. Eine zertifikatsbasierte Methode ohne Clientzertifikat scheitert, bevor RADIUS etwas sieht, und das ist ein Bereitstellungsproblem und kein Problem der Serverrichtlinie.

Lesen Sie einen Versuch, bevor Sie die Richtlinie ändern

Zeichnen Sie einen einzelnen genehmigten Versuch am Gateway und am Authentifizierungsserver auf. Suchen Sie EAP-Message-Attribute in der RADIUS-Anfrage. Ihr Vorhandensein zeigt, dass der Durchleitungspfad genutzt wird; ihr Fehlen deutet auf einen Austausch von Anmeldedaten hin.

Auf einem Linux-Gateway zeigt eine Aufzeichnung am RADIUS-Port, welche Attribute auf der Leitung liegen:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Vergleichen Sie dann den Ablehnungspunkt. Ein Fehler am Gateway vor jedem RADIUS-Paket bedeutet, dass Client und Gateway sich über die Methode uneinig waren. Eine RADIUS-Ablehnung mit EAP-Attributen bedeutet, dass die Endpunkte die Methode ausgeführt haben und einer das Ergebnis abgelehnt hat.

Planen Sie die Migration als eine durchgängige Änderung

Die Methode zu ändern heißt, Clientkonfiguration, Trägerunterstützung des Gateways, Methodenrichtlinie des Servers und Anmeldedatenspeicher gemeinsam zu ändern. Tun Sie das in dieser Reihenfolge und halten Sie einen funktionierenden Pfad, bis der neue bewiesen ist. Eine Änderung nur auf Serverseite ist eine Vermutung und bricht meist die Clients, die funktionierten. Bereiten Sie die Änderung an einer Testidentität vor, bevor Sie die Gruppe anfassen.

Notieren Sie die Kombination, die funktioniert: VPN-Protokoll, EAP-Träger, Peer-Methode, Servermethode, Typ der Anmeldedaten und Serveridentitätsprüfung.

Halten Sie administrative AAA-Anmeldung von der VPN-Authentifizierung getrennt, es sei denn, die Aufgabe umfasst ausdrücklich beides. Eine für den Fernzugriff gedachte Änderung sollte Ihnen nicht die Möglichkeit nehmen, das Gerät zu verwalten, das sie beendet.