RADIUS アカウンティングとログイン成功の違い: それぞれが何を証明するか

VPN の課金に関する議論では、必ず二つの問いが混同されます。この利用者に接続が許可されていたのか、そして実際に何をしたのか。前者に答えるのは認証です。後者には、開始し、更新され、終了するアカウンティングのレコードが必要です。ログインの成功は前者を証明しますが後者については何も語らず、だからこそ動作している RADIUS 認証の設定でも空の利用レポートが生まれます。

二つの異なる問い

認証は接続を開始してよいかを決め、アドレスプールやグループといった属性とともに判定を返します。アカウンティングは、その後に続いたサービスを、一つのセッションに紐づくイベントの連なりとして記録します。

両者は同じプロトコルを通り、たいていは同じサーバーに届きます、だからこそ、一方が他方を意味すると人は思い込みます。

アクセス要求にはセッションの継続時間は含まれず、Stop レコードが利用者を許可すべきだったかを決め直すこともありません。両者を別々の契約として扱うと、統合の作業がはっきりします。一方の経路には判断が必要で、もう一方には始まり、中間、終わりを備えたライフサイクルが必要です。

三つのレコード種別が与えるもの

Start レコードはセッションを開き、Interim-Update は開いている間の活動を報告し、Stop はそれを閉じます。三つともセッション識別子を持つので、受信側はそれらを一つのサービスイベントに対応付けられます。

その識別子だけが両者をつなぐ信頼できる手がかりです。同じユーザー名で複数のセッションが連続したり並行したりするからです。保存設計はアカウント名ではなくこの識別子を中心に組み立ててください。

レコードを確認応答することと、それをきちんと保存することは別の話です。アカウンティング仕様は、レコードを書き込めなかった場合の確認応答を禁じています。つまり応答は、受信側が責任を引き受けたことを伝えますが、その後のレポート処理やダッシュボード、請求のエクスポートが正しく消費したことまでは伝えません。

ユーザー名がセッションではない理由

同じ人が午前はノート PC から、午後は携帯電話から接続し、どちらのセッションも同じアカウント名を持ちます。対応する Stop を伴わない Start は、名前を検索して最も古い開いた行を選ぶだけでは閉じられません。

その近道が、利用レポートにあり得ない継続時間を生む仕組みです。

ネットワークアクセスサーバーの識別情報をセッション識別子と並べて保持してください。二つのサーバーが別の文脈で同じ値を割り当てることがあり、識別子だけで統合すると無関係なセッションが結び付くからです。セッションが正常に終わらない場合、照合の方針が閉じ方を決める必要があり、その判断は設計に属し、月に一度の手作業のデータベース編集に属しません。

PAM が適合する場所とそうでない場所

OpenVPN の認証プラグインは PAM の認証段階とアカウント管理段階を呼び出します。アカウント段階は適格性を確認しますが、その名前は利用量のアカウンティングを意味せず、プラグインは PAM のセッション開始・終了フックを動かしません。

一部の PAM RADIUS モジュールはそれらのセッションフックを通じてアカウンティングレコードを送れますが、アプリケーションが実際にそれらを呼び出す場合にしか機能しません。

したがって、そうしたモジュールを認証スタックに加えても切断イベントは生まれません。ライフサイクル全体が必要なら、それを担う統合を選んでください。接続の状態変化に合わせて Start、Interim-Update、Stop を発するプラグインやサポートされたビルドです。保守状況と、受信側が利用できないときの文書化された挙動を確認してください。レコードを黙って捨てるプラグインは、一度も送らなかったプラグインと見分けがつかないからです。アカウンティング仕様が、統合の守るべきレコードの意味論を定めています。

契約を証明する受け入れテスト

通常の接続と切断を試し、次に同じアカウントでの再接続を、次に切断せずに消えるクライアントを試します。

一つのセッション識別子を生成から確認応答を経て保存まで追跡し、カウンターの向き、単位、インターフェースを確認します。ラベルのないバイト数は後から監査できません。

最後に、サーバーがタイムアウトで閉じざるを得なかったセッションが、レポートの理解できる形で表されていることを確認します。正常な切断だけを対象にした契約は、最も必要になる日に破綻する契約です。