Adresse de client VPN stable avec Framed-IP-Address de RADIUS

RADIUS peut répondre par une adresse pour un utilisateur donné ; que le tunnel la reçoive réellement dépend de la passerelle. C’est dans cet écart entre ce qui est renvoyé et ce qui est appliqué que la plupart des plans d’adresses stables échouent. Un attribut dans une réponse de test prouve que le serveur peut l’envoyer, pas que le service d’accès distant l’applique. La séquence ci-dessous vérifie les deux moitiés avant que l’adresse n’arrive dans les règles du pare-feu.

Déterminez quelle couche possède l’adresse

Les passerelles d’accès distant ont généralement un pool local, et beaucoup peuvent aussi accepter une adresse issue de la réponse d’authentification. Laquelle l’emporte dépend de la plateforme, du protocole et de la configuration du service, aussi lisez la règle de priorité pour la version exacte utilisée. Là où le pool local a la priorité, l’attribut est décoratif et le client atterrit quand même sur une adresse aléatoire. Notez la décision, y compris si une valeur renvoyée doit rester dans la plage du pool ou peut en sortir.

La RFC 2865 définit Framed-IP-Address comme l’adresse à configurer pour l’utilisateur et ne dit rien de la volonté d’une passerelle particulière de la respecter. La documentation du fournisseur fait autorité pour la priorité, pas la définition de l’attribut.

Envoyez une requête de test et lisez la réponse

Testez d’abord le serveur isolément, afin qu’un attribut absent ne soit pas pris pour un problème de passerelle. radtest envoie une Access-Request et imprime les attributs qui reviennent.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Cherchez Framed-IP-Address dans l’Access-Accept et confirmez que la valeur est celle voulue et non une adresse de pool issue d’une règle de secours. Quand l’attribut manque, l’entrée utilisateur ou la politique d’autorisation ne correspond pas, et le réglage de la passerelle ne peut pas fournir ce que le serveur n’a jamais envoyé. Répétez la requête pendant que le serveur tourne en mode débogage si la réponse est difficile à rattacher à une règle précise. Gardez le secret partagé hors de l’historique du shell et des tickets, car l’espace réservé ci-dessus n’est pas un identifiant.

Confirmez que la passerelle a respecté la valeur

Une réponse correcte n’est que la moitié du contrat. L’adresse qui apparaît sur l’interface du tunnel est l’observation qui compte, et elle se lit sur le client plutôt que de se déduire de la configuration de la passerelle.

ip -4 addr show tun0

Comparez cette adresse à l’attribut de l’Access-Accept. Un écart signifie que la passerelle a ignoré ou réécrit la valeur, ce qui rouvre la question de priorité de la première section. Reconnectez encore une fois, car une réservation qui ne fonctionne qu’à la première tentative indique souvent une session périmée ou un bail encore détenu par la connexion précédente. Notez la version de la passerelle et le protocole à côté du résultat, afin que la personne suivante puisse dire si le comportement dépend de la version.

Planifiez la concurrence et la révocation

Un nom d’utilisateur sur deux appareils ne peut pas correspondre à une seule adresse, sauf si la passerelle distingue les sessions par autre chose que la connexion. Décidez si la correspondance appartient à une personne, à un appareil enrôlé ou à l’identité d’un certificat, et rendez ce choix explicite dans le magasin de stratégies. Testez un second client simultané et comparez les deux adresses attribuées, car une collision ici réapparaît plus tard comme défaut de routage. Le même soin vaut pour le plan de révocation, car une adresse réattribuée alors que d’anciennes règles de pare-feu la référencent encore devient un défaut d’autorisation.

L’adressage stable simplifie les règles et les journaux, mais il ne prouve jamais qui a généré un paquet. L’authentification et l’autorisation de destination comptent encore lorsque cette adresse passe plus tard à une autre session.