RADIUS-accounting versus geslaagde login: wat elk ervan bewijst
Een Access-Accept zegt dat een sessie mag beginnen. Start-, Interim-Update- en Stop-records zeggen wat daarna gebeurde; een sessie-identificatie verbindt ze.
In elk gesprek over VPN-facturering worden twee vragen door elkaar gehaald: mocht deze gebruiker verbinden, en wat deed hij werkelijk. De eerste wordt beantwoord door authenticatie. De tweede vereist accounting-records die beginnen, bijwerken en eindigen. Een geslaagde login bewijst de eerste en zegt niets over de tweede, daarom kan een werkende RADIUS-authenticatie nog steeds een leeg gebruiksrapport opleveren.
Twee verschillende vragen
Authenticatie beslist of een verbinding mag beginnen, en geeft een oordeel plus attributen zoals een adrespool of een groep terug. Accounting legt de dienst vast die volgde, als een reeks gebeurtenissen die aan één sessie zijn gebonden.
Ze reizen over hetzelfde protocol en meestal naar dezelfde server, en juist daarom nemen mensen aan dat het ene het andere impliceert.
Niets in een toegangsverzoek draagt de duur van de sessie, en niets in een Stop-record beslist opnieuw of de gebruiker toegelaten had moeten worden. Ze als aparte contracten behandelen maakt het integratiewerk zichtbaar: het ene pad heeft een beslissing nodig, het andere een levenscyclus met een begin, een midden en een eind.
Wat de drie recordtypen je geven
Een Start-record opent een sessie, een Interim-Update meldt activiteit terwijl die open is, en een Stop sluit haar. Alle drie dragen een sessie-identificatie zodat de ontvanger ze aan één dienstgebeurtenis kan koppelen.
Die identificatie is de enige betrouwbare schakel tussen hen, omdat dezelfde gebruikersnaam meerdere sessies na elkaar of parallel kan hebben. Ontwerp de opslag eromheen en niet om de accountnaam.
Een record bevestigen is iets anders dan het goed opslaan. De accounting-specificatie verbiedt de bevestiging wanneer het record niet kon worden geschreven, dus een antwoord vertelt je wel dat de ontvanger verantwoordelijkheid aanvaardde. Het vertelt je niet dat de latere rapportagetaak, het dashboard of de facturatie-export het correct heeft verwerkt.
Waarom de gebruikersnaam niet de sessie is
Eén persoon verbindt 's ochtends vanaf een laptop en 's middags vanaf een telefoon, en beide sessies dragen dezelfde accountnaam. Een Start die aankomt zonder bijbehorende Stop kan niet worden gesloten door de naam op te zoeken en de oudste open rij te kiezen.
Die sluiproute is hoe gebruiksrapporten onmogelijke duur krijgen.
Houd de identiteit van de netwerktoegangsserver naast de sessie-identificatie, want twee servers kunnen dezelfde waarde in verschillende contexten toekennen en een samenvoeging op alleen de identificatie kan ongerelateerde sessies verbinden. Wanneer een sessie onbeholpen eindigt, moet het afstemmingsbeleid beslissen hoe ze wordt gesloten, en die beslissing hoort in het ontwerp en niet in een handmatige databasewijziging die eens per maand wordt gedaan.
Waar PAM past en waar niet
De authenticatie-plugin van OpenVPN roept de authenticatie- en accountbeheerfasen van PAM aan. De accountfase controleert geschiktheid; de naam betekent geen gebruiksaccounting, en de plugin stuurt de sessie-open- en sluit-hooks van PAM niet aan.
Sommige PAM RADIUS-modules kunnen accounting-records via die sessie-hooks versturen, en dat werkt alleen wanneer de toepassing ze werkelijk aanroept.
Zo'n module aan een authenticatiestack toevoegen creëert dus geen verbreekgebeurtenissen. Als je de volledige levenscyclus nodig hebt, kies dan een integratie die die bezit: een plugin of een ondersteunde build die Start, Interim-Update en Stop uitzendt wanneer de verbinding van staat verandert. Controleer de onderhoudsstatus en het gedocumenteerde gedrag wanneer de ontvanger niet beschikbaar is, want een plugin die records stil laat vallen ziet er identiek uit aan een die ze nooit heeft verzonden. De accounting-specificatie definieert de semantiek van de records die de integratie moet respecteren.
Een acceptatierun die het contract bewijst
Test een normale verbinding en verbreking, dan een herverbinding onder hetzelfde account, dan een client die verdwijnt zonder te verbreken.
Volg één sessie-identificatie van het ontstaan via de bevestiging tot de opslag, en controleer de richting, eenheden en interface van de tellers. Een ongelabeld byteaantal is later niet te auditen.
Bevestig ten slotte dat een sessie die de server moest laten verlopen, wordt voorgesteld op een manier die het rapport begrijpt. Een contract dat alleen nette verbrekingen dekt, is een contract dat faalt op de dagen dat je het het hardst nodig hebt.