VPN-Anmeldung hängt nach einer RADIUS Access-Challenge

Das Passwort stimmt, die VPN-Anmeldung scheitert trotzdem, und der RADIUS-Server hat vielleicht genau das getan, was ihm gesagt wurde. Das Gateway hat wahrscheinlich eine Access-Challenge empfangen, nichts Brauchbares angezeigt und ist dann in ein Timeout gelaufen oder hat diese Antwort als Ablehnung behandelt. Aus Sicht des Clients sieht es nach falschen Zugangsdaten oder einem defekten Tunnel aus. Die Ursache liegt meist mitten in einer Konversation, die niemand mitgeschnitten hat.

Eine Anmeldung, zwei RADIUS-Austausche

Wenn das Backend einen zweiten Faktor verlangt, antwortet es auf die erste Anfrage nicht mit Annahme oder Ablehnung. Es antwortet mit Code 11 und wartet auf die nächste Antwort des Nutzers, die das Gateway in einer Folgeanfrage zurücksenden muss. Diese Folgeanfrage gehört zu derselben Authentifizierungskonversation, nicht zu einem neuen Anmeldeversuch.

In einer funktionierenden Umgebung sieht der Nutzer eine zweite Abfrage: zuerst das Passwort, dann einen Einmalcode, oder eine einzige kombinierte Abfrage, wenn der Betreiber eine dokumentiert hat. In einer defekten Umgebung erscheint die zweite Abfrage nie und die Anmeldung scheitert einfach.

Das ist das Symptom, dem man nachgehen muss, und es lässt sich allein von der Clientseite bestätigen: Wenn der VPN-Client nach genau einem Geheimnis fragt und dann ein Passwort ablehnt, von dem Sie wissen, dass es gültig ist, endete der Austausch wahrscheinlich bei der Challenge.

Was die Challenge tatsächlich trägt

Die RADIUS-Spezifikation beschreibt Code 11 in Abschnitt 4.4 und erlaubt zwei Attribute, die hier zählen. Reply-Message enthält Text für den Nutzer, und State enthält einen undurchsichtigen Wert, den der Server zurückgespiegelt haben möchte. Das NAS soll State nicht interpretieren, sondern nur unverändert zurückgeben.

Die Folgeanfrage verwendet einen neuen Identifier und einen neuen Request Authenticator und muss denselben State-Wert plus die Antwort des Nutzers tragen. Der Server ordnet sie über diesen State der wartenden Challenge zu, weshalb ein Gateway, das das Attribut neu erzeugt oder verwirft, die Zeremonie nicht abschließen kann. Der Response Authenticator jeder Antwort muss ebenfalls validieren, sonst sollte das NAS das Paket verwerfen.

Abschnitt 4.4 ergänzt das Detail, das die meisten stillen Fehler erklärt: Ein NAS, das Challenges nicht unterstützt, behandelt Access-Challenge als Ablehnung. Wenn der VPN-Dienst Ihres Gateways diese Unterstützung nicht kennt oder auslässt, wird die Anfrage des Backends nach einem zweiten Faktor zu einem sofortigen „Authentifizierung fehlgeschlagen“ ohne jede Abfrage.

Wo die verkettete Anfrage verloren geht

Der erste Verdächtige ist der Abfrageweg, nicht die Zugangsdaten. Ein Portal, das für Weblogins ein OTP-Feld anzeigt, tut das nicht automatisch für den VPN-Dienst, und manche Gateways reichen eine Challenge nur an Clients weiter, die die Fähigkeit ankündigen. Testen Sie dasselbe Konto an beiden Einstiegspunkten; wenn das Portal funktioniert und das VPN nicht, betrachten Sie die Übergabe, nicht das Token.

Das Eingabeformat ist der zweite Verdächtige. Passwort und Code ohne den dokumentierten Trenner des Herstellers zu verketten oder gespeicherte Zugangsdaten einen alten Code wiederholen zu lassen, scheitert auf eine Weise, die einem falschen Passwort gleicht. Verwenden Sie die dokumentierte getrennte Abfrage oder das kombinierte Format des Betreibers und erfinden Sie niemals einen Trenner.

Release-spezifische Fehler gibt es, aber eine Liste korrigierter Versionen von vor Jahren ist keine Diagnose für das heutige Deployment. Lesen Sie die Release Notes der Software, die Sie tatsächlich betreiben, und halten Sie die beobachtete Austauschphase als Beweis fest.

Verfolgen Sie einen einzigen Versuch von Anfang bis Ende

Reproduzieren Sie ihn einmal mit aktiviertem serverseitigem Debugging und halten Sie jede andere Sitzung aus dem Aufzeichnungsfenster:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

Suchen Sie in der Ausgabe nach der Form der Konversation statt nach einer einzelnen Zeile. Eine erste Access-Request mit Identifier 3, eine Access-Challenge mit State, dann eine zweite Access-Request mit Identifier 4, die diesen State wiederholt und die Antwort des Nutzers enthält. Fehlt die zweite Anfrage, hat das Gateway nie nachgefasst. Kommt sie ohne State an, kann der Server sie nicht der wartenden Challenge zuordnen und wird sie meist ablehnen.

Schwärzen Sie Zugangsdaten, Token und unnötige Identitätsdaten, wenn Sie den Trace teilen, und korrelieren Sie Ereignisse aus dem einen Versuch, statt Wiederholungen aus mehreren Browser-Tabs zu vermischen. Zeitstempel sind hier Ihr Freund; eine Challenge, die ankommt, nachdem der Client aufgegeben hat, wirkt auf den Nutzer wie eine Ablehnung und im Log wie eine langsame Antwort.

Der gewünschte Endzustand ist eine abgeschlossene, autorisierte Konversation, gefolgt vom beabsichtigten Dienstzugriff. Eine Antwort, die vom RADIUS-Server eintrifft, beweist deutlich weniger.