IP VPN fixe : Framed-IP-Address RADIUS ou une réservation dans le pool

Trois endroits peuvent détenir une adresse interne fixe pour un client VPN, et un seul devrait la posséder. RADIUS peut renvoyer l’adresse dans un Access-Accept, la passerelle peut conserver un mappage statique pour le compte, et l’adaptateur du client peut être réglé à la main. Les deux premiers relèvent de la politique et le troisième est une supposition locale que la passerelle est libre d’ignorer ou d’écraser. Choisir entre les deux premiers est la vraie décision, et cela dépend de ce que le serveur d’accès au réseau implémente réellement.

Trois endroits où une adresse fixe peut vivre

RADIUS possède l’adresse quand la réponse porte Framed-IP-Address et que la passerelle applique cette valeur à la session. La passerelle la possède quand un administrateur associe le compte à une adresse statique dans le pool. Le client ne possède rien, même lorsque son adaptateur affiche une adresse manuelle, car le serveur attribue l’adresse interne pendant la négociation et un réglage local ne compte que si le serveur n’en envoie aucun. Les trois se ressemblent sur une connexion qui fonctionne, et c’est pourquoi les conflits apparaissent tard. La différence se voit à la reconnexion, sur un second appareil et après un changement de politique.

Deux propriétaires, c’est la configuration qui casse. Une réponse RADIUS qui attribue 172.28.4.77 alors que la passerelle détient un mappage statique pour 172.28.4.90 donne la valeur que le code du constructeur vérifie en premier, et le perdant est écarté sans ligne de journal. Le même compte sur un second appareil reçoit alors une adresse en double, et le symptôme se lit comme un défaut de routage plutôt que comme un conflit d’attribution. Tranchez le propriétaire avant d’ajouter le second mécanisme.

L’option côté client ne mérite d’être nommée que pour être écartée. Une adresse d’adaptateur manuelle est une préférence que le système d’exploitation peut présenter, pas une réservation, et elle ne peut pas empêcher une autre session de recevoir la même adresse.

Ce que la réponse RADIUS peut promettre et ne peut pas promettre

RFC 2865définit Framed-IP-Address comme l’adresse IPv4 à configurer pour l’utilisateur, et elle appartient à Access-Accept. Le même attribut dans Access-Request n’est qu’un indice que le serveur peut ignorer, ce qui compte lorsqu’un client ou une passerelle propose une adresse préférée. Rien dans le protocole n’oblige la passerelle à honorer la réponse, car le serveur d’accès au réseau est le composant qui l’applique à la session.

La prise en charge est une question de produit et non de protocole. Certaines passerelles appliquent les adresses encadrées par défaut, d’autres ont besoin d’un commutateur au niveau du groupe activé avant de le faire, et d’autres acceptent l’attribut sans jamais l’utiliser pour les sessions d’accès distant. Ce dernier cas est le dangereux, car l’enregistrement de comptabilité peut montrer la réponse pendant que le client reçoit une adresse du pool. Confirmez le comportement sur le modèle exact de passerelle et le firmware que vous exploitez, pas dans la documentation d’un produit frère.

Une réponse que la passerelle ignore ressemble exactement à une réponse qui n’a jamais été envoyée. Lire l’Access-Accept et l’adresse de la session côte à côte est le seul moyen de séparer les deux cas.

Réservez l’adresse à l’intérieur du pool que vous routez déjà

Choisissez l’adresse fixe dans le sous-réseau du pool que la passerelle route déjà et auquel le pare-feu fait déjà confiance. Une adresse hors de cette plage transforme un changement de politique en projet de routage, et le VPN montera alors que rien derrière lui ne pourra répondre. Si des règles d’accès par adresse existent, ajoutez-y l’adresse fixe dans le même changement.

Décidez ce qu’une seconde session simultanée doit faire. Attribuer une adresse deux fois n’est pas de la gestion d’appareils, et la collision qui en résulte apparaît comme une connectivité intermittente pour les deux sessions. Soit vous émettez des identités distinctes par appareil, soit des attributions distinctes, soit vous imposez la simultanéité avec une vérification prise en charge, comme Simultaneous-Use, au lieu d’espérer que le client ne se reconnecte jamais avant l’expiration de l’ancienne session.

Les routes de retour méritent la même attention que l’attribution. La passerelle a besoin d’une route vers le pool, les routeurs internes ont besoin d’une route de retour vers la passerelle, et l’adresse fixe hérite des deux. Un seul client qui fonctionne alors que tous les autres échouent signifie généralement que la route du pool existe mais pas la route d’hôte de l’adresse réservée.

Testez la réponse avant de faire confiance à la réservation

Testez le côté AAA et le côté session séparément, car ils échouent pour des raisons différentes. Un radtest local montre ce que le serveur renvoie pour le compte sans impliquer la passerelle, et l’entrée du fichier users montre ce à quoi le serveur est censé correspondre. Reconnectez ensuite le client et comparez l’adresse reçue avec l’attribut de la réponse.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

Un Access-Accept sans l’attribut signifie que le serveur n’a pas trouvé l’entrée ou que l’attribut n’a pas été appliqué à cet utilisateur. Un Access-Accept avec l’attribut et un client qui reçoit toujours une adresse du pool signifie que la passerelle l’a ignoré. Un Access-Reject vous renvoie aux identifiants ou à la politique de groupe, et aucun de ces résultats ne devrait être débogué en modifiant l’adaptateur du client.

Répétez la vérification après une reconnexion et après une seconde connexion depuis un autre appareil. Une réservation qui ne tient que pour la première session est un conflit de pool qui attend de se produire, et il est moins coûteux de le trouver maintenant qu’au cours d’un audit.

Choisissez un seul propriétaire et écrivez-le

Si la passerelle applique les adresses encadrées de manière fiable, laissez RADIUS posséder l’attribution et supprimez tout mappage statique pour le même compte. Sinon, laissez la passerelle la posséder et retirez l’attribut de la réponse, afin que les deux sources ne puissent pas diverger. Garder les deux parce que chacune fonctionne presque garantit une future session avec la mauvaise adresse et sans cause évidente.

Écrivez le propriétaire choisi, l’adresse réservée et le pool d’où elle vient dans l’enregistrement du compte. La personne suivante qui ajoute un appareil pourra alors voir si l’adresse est une politique AAA ou un mappage de passerelle avant de modifier l’un ou l’autre.