Comptabilité RADIUS et connexion réussie : ce que chacune prouve
Un Access-Accept indique qu’une session peut commencer. Les enregistrements Start, Interim-Update et Stop disent ce qui s’est passé ensuite ; un identifiant de session les relie.
Deux questions se confondent dans toute discussion sur la facturation VPN : cet utilisateur était-il autorisé à se connecter, et qu’a-t-il réellement fait. La première trouve sa réponse dans l’authentification. La seconde exige des enregistrements de comptabilité qui commencent, se mettent à jour et se terminent. Une connexion réussie prouve la première et ne dit rien de la seconde, ce qui explique pourquoi une configuration d’authentification RADIUS fonctionnelle peut tout de même produire un rapport d’usage vide.
Deux questions différentes
L’authentification décide si une connexion peut commencer, et elle renvoie un verdict accompagné d’attributs comme un pool d’adresses ou un groupe. La comptabilité enregistre le service qui a suivi, sous forme de suite d’événements liés à une session.
Ils passent par le même protocole et généralement vers le même serveur, et c’est précisément pourquoi les gens supposent que l’un implique l’autre.
Rien dans une requête d’accès ne porte la durée de la session, et rien dans un enregistrement Stop ne redécide si l’utilisateur aurait dû être admis. Les traiter comme des contrats distincts rend le travail d’intégration visible : un chemin a besoin d’une décision, l’autre d’un cycle de vie avec un début, un milieu et une fin.
Ce que les trois types d’enregistrement vous apportent
Un enregistrement Start ouvre une session, un Interim-Update signale l’activité tant qu’elle est ouverte, et un Stop la ferme. Les trois portent un identifiant de session afin que le récepteur puisse les rattacher à un seul événement de service.
Cet identifiant est le seul lien fiable entre eux, car le même nom d’utilisateur peut porter plusieurs sessions successives ou parallèles. Concevez le stockage autour de lui plutôt qu’autour du nom de compte.
Accuser réception d’un enregistrement est une chose distincte de bien le stocker. La spécification de comptabilité interdit l’accusé lorsque l’enregistrement n’a pas pu être écrit, donc une réponse vous indique bien que le récepteur a assumé la responsabilité. Elle ne vous dit pas que la tâche de reporting ultérieure, le tableau de bord ou l’export de facturation en ont fait bon usage.
Pourquoi le nom d’utilisateur n’est pas la session
Une personne se connecte depuis un ordinateur portable le matin et depuis un téléphone l’après-midi, et les deux sessions portent le même nom de compte. Un Start qui arrive sans son Stop correspondant ne peut pas être fermé en cherchant le nom et en prenant la ligne ouverte la plus ancienne.
Ce raccourci est la façon dont les rapports d’usage acquièrent des durées impossibles.
Gardez l’identité du serveur d’accès réseau à côté de l’identifiant de session, car deux serveurs peuvent attribuer la même valeur dans des contextes différents et une fusion sur le seul identifiant peut réunir des sessions sans rapport. Quand une session se termine mal, la politique de réconciliation doit décider comment la clore, et cette décision appartient à la conception et non à une modification manuelle de la base faite une fois par mois.
Où PAM trouve sa place et où il ne la trouve pas
Le greffon d’authentification d’OpenVPN appelle les étapes d’authentification et de gestion de comptes de PAM. L’étape de compte vérifie l’éligibilité ; son nom ne signifie pas comptabilité d’usage, et le greffon ne pilote pas les crochets d’ouverture et de fermeture de session de PAM.
Certains modules PAM RADIUS peuvent envoyer des enregistrements de comptabilité via ces crochets de session, et cela ne fonctionne que si l’application les invoque réellement.
Ajouter un tel module à une pile d’authentification ne crée donc pas d’événements de déconnexion. Si vous avez besoin du cycle de vie complet, choisissez une intégration qui le porte : un greffon ou une compilation prise en charge qui émet Start, Interim-Update et Stop à mesure que la connexion change d’état. Vérifiez son état de maintenance et son comportement documenté lorsque le récepteur est indisponible, car un greffon qui perd des enregistrements en silence ressemble exactement à un autre qui ne les a jamais envoyés. La spécification de comptabilité définit la sémantique des enregistrements que l’intégration doit respecter.
Une campagne d’acceptation qui prouve le contrat
Testez une connexion et une déconnexion normales, puis une reconnexion avec le même compte, puis un client qui disparaît sans se déconnecter.
Suivez un identifiant de session depuis sa création, puis l’accusé, jusqu’au stockage, et vérifiez le sens, les unités et l’interface des compteurs. Un décompte d’octets sans étiquette est impossible à auditer ensuite.
Enfin, confirmez qu’une session que le serveur a dû fermer par expiration est représentée d’une manière que le rapport comprend. Un contrat qui ne couvre que les déconnexions propres est un contrat qui échoue les jours où vous en avez le plus besoin.