Comment une connexion VPN atteint RADIUS et votre fournisseur d'identité
Suivez une connexion VPN du client à la requête RADIUS de la passerelle, au fournisseur d'identité derrière elle et à la politique appliquée après l'acceptation.
La semaine dernière, un utilisateur a pu se connecter au VPN et a tout de même atterri sur un réseau où rien ne se résolvait. Le client disait connecté, le journal de la passerelle disait Access-Accept, et l'équipe identité disait que le compte était correct. La connexion avait fonctionné ; l'autorisation derrière, non. Quand une connexion VPN échoue, je parcours le chemin que la requête emprunte réellement — client, passerelle, serveur RADIUS, fournisseur d'identité — et je m'arrête au premier saut dont la réponse ne concorde pas avec la suivante.
Le client ne parle jamais RADIUS
Quoi qu'affiche l'application sur le portable, son premier saut est le protocole VPN : IKEv2, OpenVPN, WireGuard ou un client basé sur TLS. RADIUS n'apparaît pas dans cet échange. Le client s'authentifie auprès de la passerelle avec un certificat, un nom d'utilisateur et un mot de passe, ou une méthode EAP transportée dans la configuration du tunnel.
Cela compte quand on lit les journaux, car l'erreur d'authentification générique que voit l'utilisateur est produite par la passerelle après qu'elle a déjà parlé à autre chose. Si le client n'atteint jamais la passerelle, aucune requête RADIUS n'existe à déboguer, et une heure passée sur le serveur RADIUS est perdue. Confirmez que le tunnel s'est bien monté avant de toucher au backend.
La passerelle est le client RADIUS
Dès que la configuration du tunnel arrive au point où les identifiants doivent être vérifiés, la passerelle devient un serveur d'accès réseau. Elle construit une Access-Request : User-Name, un mot de passe ou une charge EAP, NAS-IP-Address ou NAS-Identifier, et un Message-Authenticator quand la méthode l'exige. La requête part vers UDP 1812 par défaut, et la comptabilité vers 1813. Les installations plus anciennes utilisent encore 1645 et 1646, si bien qu'une règle de pare-feu écrite pour une paire explique beaucoup d'échecs silencieux.
Les deux côtés partagent un secret, et ce n'est pas un identifiant utilisateur. Il signe l'échange, et chaque réponse est vérifiée par rapport à lui. Configurez le secret différemment des deux côtés et le serveur ne répond pas mauvais secret : il abandonne la requête ou la réponse échoue à la vérification, donc la passerelle signale un délai d'attente. Un mauvais secret et un serveur mort semblent identiques depuis la passerelle, c'est pourquoi je teste le saut avec un outil client avant d'accuser l'annuaire.
Le protocole est petit et ancien — RFC 2865 définit l'échange d'authentification — mais les attributs qu'il transporte sont ce sur quoi repose l'essentiel de la politique VPN.
# 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'Le serveur RADIUS n'est peut-être que la façade du fournisseur d'identité
Les gens parlent de RADIUS et du fournisseur d'identité comme s'il s'agissait de la même boîte. Souvent, ce n'est pas le cas. Le serveur RADIUS reçoit l'Access-Request puis interroge autre chose — Active Directory via LDAP ou Kerberos, un fichier d'utilisateurs local ou un service externe — avant de répondre. FreeRADIUS avec le module LDAP ou krb5, Windows NPS et Cisco ISE occupent tous cette position.
La distinction décide où regarder. Un mot de passe refusé est une réponse du fournisseur d'identité relayée par RADIUS. Un délai d'attente est généralement le tronçon RADIUS-annuaire : un compte de liaison expiré, un annuaire injoignable ou une requête routée vers le mauvais backend. Si le nom d'utilisateur porte un suffixe de domaine, le serveur peut router dessus, et le même compte envoyé comme CORP\alice et [email protected] peut aboutir à des endroits différents. Sous Windows NPS, le journal Security consigne 6272 pour une autorisation et 6273 pour un refus, ce qui indique si la décision vient bien de NPS.
Lisez l'échec au saut qui l'a produit
Un seul message impossible de se connecter couvre quatre échecs différents. Avant de changer quoi que ce soit, associez le symptôme au saut qui l'a produit.
| 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 |
La dernière ligne est celle qui envoie les gens vers la mauvaise équipe. Access-Accept signifie que les identifiants ont été acceptés ; cela ne signifie pas que la passerelle a placé l'utilisateur dans le bon pool ou poussé des routes. Les attributs de groupe ne comptent que si la politique de la passerelle les lit. J'ai vu une connexion correcte atterrir dans un pool invité parce que le mappage des groupes était configuré côté RADIUS pour un attribut différent de celui que la passerelle inspecte.
Suivez une connexion de bout en bout
Choisissez un seul compte de test et une passerelle, puis observez la même tentative aux quatre points. Lancez une exécution de débogage côté RADIUS — freeradius -X imprime la requête et chaque module qu'elle touche — suivez le journal d'authentification de la passerelle et lancez tcpdump pour l'échange UDP. Connectez-vous une fois et lisez les quatre traces dans l'ordre.
Ce que vous voulez voir, c'est un accord : la passerelle a interrogé l'utilisateur attendu, le serveur RADIUS a choisi le backend attendu, ce backend a renvoyé une décision, et les attributs de la réponse correspondent à la politique que la passerelle applique. Le premier endroit où les traces divergent est votre ligne de faille. Si la réponse ne porte aucun attribut de groupe, le problème est côté RADIUS, pas dans le profil VPN ; si l'attribut est là et que la passerelle l'ignore, c'est la politique de la passerelle qui est en cause.
Une note de sécurité tant que vous y êtes. Le secret partagé protège l'échange, mais il ne chiffre pas la plupart des attributs. Si la passerelle et le serveur RADIUS sont sur des segments différents, placez ce saut sur RADIUS via TLS ou un chemin privé. Un tunnel utilisateur chiffré ne dit rien du lien vers le backend.
Avant de clôturer le ticket, confirmez quatre choses. La passerelle peut joindre le serveur RADIUS sur le port pour lequel elle est réellement configurée. Le secret partagé correspond des deux côtés. Le serveur RADIUS résout la forme exacte du nom d'utilisateur que la passerelle envoie. L'acceptation porte les attributs dont la politique de la passerelle a besoin. Quand les quatre tiennent, une connexion qui échoue encore est un problème de politique de passerelle, pas d'authentification.