Wie eine VPN-Anmeldung RADIUS und Ihren Identitätsanbieter erreicht
Verfolgen Sie eine VPN-Anmeldung vom Client bis zur RADIUS-Anfrage des Gateways, dem Identitätsanbieter dahinter und der Richtlinie, die nach dem Accept greift.
Letzte Woche konnte sich ein Benutzer am VPN anmelden und landete trotzdem in einem Netz, in dem nichts aufgelöst wurde. Der Client meldete verbunden, das Gateway-Log meldete Access-Accept, und das Identitätsteam sagte, das Konto sei in Ordnung. Die Anmeldung hatte funktioniert; die Autorisierung dahinter nicht. Wenn eine VPN-Anmeldung fehlschlägt, gehe ich den Weg, den die Anfrage tatsächlich nimmt — Client, Gateway, RADIUS-Server, Identitätsanbieter — und halte am ersten Sprung an, dessen Antwort der nächsten widerspricht.
Der Client spricht nie RADIUS
Was die App auf dem Laptop auch zeigt: Ihr erster Sprung ist das VPN-Protokoll: IKEv2, OpenVPN, WireGuard oder ein TLS-basierter Client. RADIUS kommt in diesem Austausch nicht vor. Der Client authentifiziert sich am Gateway mit einem Zertifikat, einem Benutzernamen und Passwort oder einer EAP-Methode, die im Tunnelaufbau übertragen wird.
Das zählt, wenn Sie Logs lesen, denn die allgemeine Authentifizierungsfehlermeldung, die der Benutzer sieht, erzeugt das Gateway, nachdem es bereits mit etwas anderem gesprochen hat. Erreicht der Client das Gateway nie, existiert keine RADIUS-Anfrage zum Debuggen, und eine Stunde am RADIUS-Server ist verschwendet. Bestätigen Sie, dass der Tunnel überhaupt zustande kam, bevor Sie das Backend anfassen.
Das Gateway ist der RADIUS-Client
Sobald der Tunnelaufbau an den Punkt kommt, an dem Anmeldedaten geprüft werden müssen, wird das Gateway zum Netzwerkzugangsserver. Es baut eine Access-Request: User-Name, ein Passwort oder EAP-Payload, NAS-IP-Address oder NAS-Identifier und einen Message-Authenticator, wenn die Methode einen verlangt. Die Anfrage geht standardmäßig an UDP 1812, die Abrechnung an 1813. Ältere Installationen verwenden noch 1645 und 1646, daher erklärt eine Firewallregel für das eine Paar viele stille Fehler.
Beide Seiten teilen ein Geheimnis, und es sind keine Benutzeranmeldedaten. Es signiert den Austausch, und jede Antwort wird dagegen geprüft. Konfigurieren Sie das Geheimnis auf beiden Seiten unterschiedlich, antwortet der Server nicht mit einem falschen Geheimnis — er verwirft die Anfrage oder die Antwort scheitert an der Prüfung, sodass das Gateway eine Zeitüberschreitung meldet. Ein falsches Geheimnis und ein toter Server sehen vom Gateway aus identisch aus, deshalb teste ich den Sprung mit einem Client-Werkzeug, bevor ich das Verzeichnis beschuldige.
Das Protokoll ist klein und alt — RFC 2865 definiert den Authentifizierungsaustausch —, aber die Attribute, die es trägt, sind die Grundlage der meisten VPN-Richtlinien.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'Der RADIUS-Server ist vielleicht nur die Front des Identitätsanbieters
Leute sprechen von RADIUS und Identitätsanbieter, als wären sie dieselbe Kiste. Oft sind sie es nicht. Der RADIUS-Server empfängt die Access-Request und fragt dann etwas anderes — Active Directory über LDAP oder Kerberos, eine lokale Benutzerdatei oder einen externen Dienst —, bevor er antwortet. FreeRADIUS mit dem LDAP- oder krb5-Modul, Windows NPS und Cisco ISE sitzen alle an dieser Stelle.
Der Unterschied entscheidet, wo Sie nachsehen. Ein abgelehntes Passwort ist eine Antwort des Identitätsanbieters, die RADIUS weiterreicht. Eine Zeitüberschreitung ist meist die Strecke RADIUS-zu-Verzeichnis: ein abgelaufenes Bind-Konto, ein unerreichbares Verzeichnis oder eine Anfrage an das falsche Backend. Trägt der Benutzername ein Domänensuffix, kann der Server danach routen, und dasselbe Konto als CORP\alice und [email protected] gesendet kann an verschiedenen Stellen landen. Unter Windows NPS protokolliert das Security-Log 6272 für eine Gewährung und 6273 für eine Ablehnung, was Ihnen sagt, ob die Entscheidung überhaupt von NPS kam.
Lesen Sie den Fehler an dem Sprung, der ihn erzeugt hat
Eine Kann-nicht-verbinden-Meldung deckt vier verschiedene Fehler ab. Bevor Sie etwas ändern, ordnen Sie das Symptom dem Sprung zu, der es erzeugt hat.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
Die letzte Zeile ist die, die Leute zum falschen Team schickt. Access-Accept heißt, die Anmeldedaten wurden akzeptiert; es heißt nicht, dass das Gateway den Benutzer in den richtigen Pool gesetzt oder Routen verteilt hat. Gruppenattribute zählen nur, wenn die Gateway-Richtlinie sie liest. Ich habe erlebt, dass eine korrekte Anmeldung in einem Gästepool landete, weil das Gruppenmapping auf der RADIUS-Seite für ein anderes Attribut konfiguriert war als das, das das Gateway prüft.
Verfolgen Sie eine Anmeldung von Anfang bis Ende
Wählen Sie ein Testkonto und ein Gateway und beobachten Sie dann denselben Versuch an allen vier Punkten. Starten Sie einen Debug-Lauf auf der RADIUS-Seite — freeradius -X druckt die Anfrage und jedes Modul, das sie berührt —, verfolgen Sie das Auth-Log des Gateways und führen Sie tcpdump für den UDP-Austausch aus. Verbinden Sie sich einmal und lesen Sie die vier Spuren der Reihe nach.
Was Sie sehen wollen, ist Übereinstimmung: Das Gateway fragte nach dem Benutzer, den Sie erwarteten, der RADIUS-Server wählte das Backend, das Sie erwarteten, dieses Backend lieferte eine Entscheidung, und die Attribute in der Antwort passen zur Richtlinie, die das Gateway anwendet. Die erste Stelle, an der die Spuren nicht übereinstimmen, ist Ihre Fehlergrenze. Trägt die Antwort kein Gruppenattribut, liegt das Problem auf der RADIUS-Seite, nicht im VPN-Profil; ist das Attribut da und das Gateway ignoriert es, ist die Gateway-Richtlinie das Problem.
Eine Sicherheitsnotiz, während Sie dort sind. Das gemeinsame Geheimnis schützt den Austausch, verschlüsselt aber die meisten Attribute nicht. Liegen Gateway und RADIUS-Server in verschiedenen Segmenten, legen Sie diesen Sprung auf RADIUS über TLS oder einen privaten Pfad. Ein verschlüsselter Benutzertunnel sagt nichts über die Backend-Verbindung.
Bevor Sie das Ticket schließen, bestätigen Sie vier Dinge. Das Gateway erreicht den RADIUS-Server auf dem Port, für den es tatsächlich konfiguriert ist. Das gemeinsame Geheimnis stimmt auf beiden Seiten. Der RADIUS-Server löst genau die Benutzernamensform auf, die das Gateway sendet. Der Accept trägt die Attribute, die die Gateway-Richtlinie braucht. Wenn alle vier gelten, ist eine Anmeldung, die weiterhin fehlschlägt, ein Gateway-Richtlinienproblem, kein Authentifizierungsproblem.