Pourquoi une réponse RADIUS VLAN ne fait rien pour un utilisateur VPN

Vous ajoutez l’attribut VLAN à la stratégie NPS, l’utilisateur VPN se connecte, et l’ordinateur portable atterrit toujours dans le pool par défaut. Le serveur RADIUS renvoie ce que vous avez demandé, ce qui donne à la panne l’air d’un problème de cache. Ce n’est généralement pas le cas. Un Access-Accept porte des indications d’autorisation, et seul le serveur d’accès réseau qui les a reçues peut transformer l’une d’elles en affectation réseau.

Commencez par la passerelle, pas par la stratégie

Parcourez la chaîne du client vers l’intérieur avant de changer quoi que ce soit. Le client demande une session à la passerelle, la passerelle demande à RADIUS si l’utilisateur peut en avoir une, et RADIUS répond avec un résultat et un ensemble d’attributs. La passerelle applique ensuite ce qu’elle sait appliquer.

Votre parcours commence à la quatrième étape, et c’est pourquoi les trois premières semblent saines. Rien dans l’échange n’oblige la passerelle à implémenter un attribut qu’elle a reçu. La réponse est une demande adressée à la passerelle, non un fait sur le client.

Ce que le commutateur fait et que le VPN ne peut pas

Un commutateur d’accès 802.1X est un authentificateur doté de ports, et l’affectation dynamique de VLAN déplace l’un de ces ports vers un VLAN que le commutateur transporte déjà. Les attributs de tunnel RADIUS décrivent cette intention sous une forme que le commutateur comprend. Un VPN routé termine des tunnels, pas des ports de commutateur, et ses clients reçoivent généralement une adresse et une route plutôt qu’une appartenance à un domaine de diffusion. Il n’y a aucun port à déplacer, donc le même attribut n’a rien sur quoi agir.

C’est une différence de modèle, pas un défaut du fournisseur. Certaines passerelles ajoutent leur propre stratégie de groupe, une sélection de pool ou un mécanisme de filtrage qui ressemble à la même chose sur une capture d’écran. D’autres n’en implémentent rien, et l’attribut est journalisé puis ignoré. Lisez la documentation du mode d’accès distant que vous avez réellement activé, pas celui de la capture d’écran.

Lisez la réponse que le serveur a réellement envoyée

Confirmez ce que RADIUS a renvoyé plutôt que ce qu’affiche l’éditeur de stratégie. Une requête de test avec le même nom d’utilisateur et un mot de passe connu imprime les attributs de réponse sous une forme lisible, ce qui règle la question en une étape.

radtest alice secret 10.0.0.10 0 testing123

Si les attributs VLAN manquent dans cette réponse, corrigez d’abord la correspondance de stratégie. S’ils sont présents, le serveur a fait sa part et l’écart se situe en aval.

Prouvez d’abord la stratégie de session, puis l’accessibilité

Regardez maintenant la session que la passerelle a construite. La liste des sessions actives affiche le pool, l’adresse attribuée et toute stratégie de groupe que la passerelle a jointes, et c’est la seule preuve qui compte pour l’application. Comparez cela à ce que l’utilisateur peut atteindre, et non à ce que la stratégie prévoyait.

swanctl --list-sas

Testez ensuite depuis le client une ressource autorisée et une ressource refusée, car une adresse issue du bon pool ne prouve pas l’isolation. Si la passerelle n’a aucun mécanisme pour l’affectation voulue, davantage de copies de l’attribut n’en créeront pas. Une adresse du pool attendu peut coexister avec un accès complet à tous les autres pools. Choisissez un mécanisme de stratégie pris en charge ou modifiez volontairement la conception du réseau.