RADIUS-Accounting versus erfolgreicher Login: Was jeder von beiden beweist

In jeder Abrechnungsdiskussion zu VPN werden zwei Fragen vermischt: Durfte dieser Benutzer sich verbinden, und was hat er tatsächlich getan. Die erste beantwortet die Authentifizierung. Die zweite erfordert Accounting-Datensätze, die beginnen, aktualisieren und enden. Ein erfolgreicher Login beweist die erste und sagt nichts über die zweite, weshalb eine funktionierende RADIUS-Authentifizierung trotzdem einen leeren Nutzungsbericht erzeugen kann.

Zwei verschiedene Fragen

Die Authentifizierung entscheidet, ob eine Verbindung beginnen darf, und liefert ein Urteil samt Attributen wie einem Adresspool oder einer Gruppe. Das Accounting zeichnet den Dienst auf, der folgte, als Folge von Ereignissen, die an eine Sitzung gebunden sind.

Sie laufen über dasselbe Protokoll und meist zum selben Server, genau deshalb nehmen Leute an, das eine bedinge das andere.

Nichts in einer Zugriffsanfrage trägt die Dauer der Sitzung, und nichts in einem Stop-Datensatz entscheidet neu, ob der Benutzer hätte zugelassen werden sollen. Wer sie als getrennte Verträge behandelt, macht die Integrationsarbeit sichtbar: Der eine Pfad braucht eine Entscheidung, der andere einen Lebenszyklus mit Anfang, Mitte und Ende.

Was die drei Datensatztypen liefern

Ein Start-Datensatz öffnet eine Sitzung, ein Interim-Update meldet Aktivität, solange sie offen ist, und ein Stop schließt sie. Alle drei tragen eine Sitzungskennung, damit der Empfänger sie einem Dienstereignis zuordnen kann.

Diese Kennung ist die einzige verlässliche Verbindung zwischen ihnen, denn derselbe Benutzername kann mehrere Sitzungen nacheinander oder parallel halten. Entwerfen Sie die Speicherung darum herum und nicht um den Kontonamen.

Einen Datensatz zu bestätigen ist etwas anderes, als ihn gut zu speichern. Die Accounting-Spezifikation verbietet die Bestätigung, wenn der Datensatz nicht geschrieben werden konnte, eine Antwort sagt Ihnen also, dass der Empfänger Verantwortung übernommen hat. Sie sagt Ihnen nicht, dass der spätere Berichtsjob, das Dashboard oder der Abrechnungsexport ihn korrekt verarbeitet hat.

Warum der Benutzername nicht die Sitzung ist

Eine Person verbindet sich morgens von einem Laptop und nachmittags von einem Telefon, und beide Sitzungen tragen denselben Kontonamen. Ein Start, der ohne passenden Stop eintrifft, lässt sich nicht schließen, indem man den Namen nachschlägt und die älteste offene Zeile wählt.

Diese Abkürzung ist der Weg, auf dem Nutzungsberichte unmögliche Dauern bekommen.

Halten Sie die Identität des Netzwerkzugriffsservers neben der Sitzungskennung, denn zwei Server können denselben Wert in verschiedenen Kontexten vergeben, und eine Zusammenführung allein über die Kennung kann unzusammenhängende Sitzungen verbinden. Endet eine Sitzung unsauber, muss die Abstimmungsrichtlinie entscheiden, wie sie geschlossen wird, und diese Entscheidung gehört ins Design und nicht in eine manuelle Datenbankänderung einmal im Monat.

Wo PAM passt und wo nicht

Das Authentifizierungs-Plugin von OpenVPN ruft die Authentifizierungs- und Kontoverwaltungsstufen von PAM auf. Die Kontostufe prüft die Berechtigung; ihr Name bedeutet kein Nutzungs-Accounting, und das Plugin steuert nicht die Sitzungs-Öffnungs- und Schließ-Hooks von PAM.

Manche PAM-RADIUS-Module können Accounting-Datensätze über diese Sitzungs-Hooks senden, und das funktioniert nur, wenn die Anwendung sie tatsächlich aufruft.

Ein solches Modul zu einem Authentifizierungs-Stack hinzuzufügen erzeugt daher keine Trennungsereignisse. Wenn Sie den vollen Lebenszyklus brauchen, wählen Sie eine Integration, die ihn besitzt: ein Plugin oder einen unterstützten Build, der Start, Interim-Update und Stop ausgibt, während sich der Verbindungszustand ändert. Prüfen Sie seinen Wartungsstatus und sein dokumentiertes Verhalten, wenn der Empfänger nicht erreichbar ist, denn ein Plugin, das Datensätze still verwirft, sieht genauso aus wie eines, das sie nie gesendet hat. Die Accounting-Spezifikation legt die Datensatz-Semantik fest, die die Integration einhalten muss.

Ein Abnahmelauf, der den Vertrag beweist

Testen Sie ein normales Verbinden und Trennen, dann ein erneutes Verbinden unter demselben Konto, dann einen Client, der ohne Trennung verschwindet.

Verfolgen Sie eine Sitzungskennung von der Erzeugung über die Bestätigung bis zur Speicherung und prüfen Sie Richtung, Einheiten und Schnittstelle der Zähler. Eine unbenannte Bytezahl lässt sich später nicht prüfen.

Bestätigen Sie schließlich, dass eine Sitzung, die der Server per Zeitüberschreitung beenden musste, so dargestellt wird, wie der Bericht es versteht. Ein Vertrag, der nur saubere Trennungen abdeckt, ist ein Vertrag, der an den Tagen versagt, an denen Sie ihn am dringendsten brauchen.