シナプス技術者ブログ

シナプスの技術者公式ブログ。インターネットで、鹿児島の毎日を笑顔にします。

RADIUSを半分自社開発してみました

技術 サーバ RADIUS FreeRADIUS Perl rlm_perl

中野です、2回目の投稿です!!

シナプスは、鹿児島を主な営業エリアにインターネット接続サービスを提供するインターネットサービスプロバイダ(ISP)です。

そのISPの「インターネット接続サービス」に必要不可欠なシステムに、RADIUSと呼ばれるシステムがあり、今回はそのRADIUSを半分だけ自社開発してリプレースしたお話です。

RADIUSって何

そのRADIUSが何かというと、Wikipediaによれば、

RADIUS（ラディウス、ラディアス、Remote Authentication Dial In User Service）は、ネットワーク資源の利用の可否の判断（認証）と、利用の事実の記録（アカウンティング）を、ネットワーク上のサーバコンピュータに一元化することを目的とした、IP上のプロトコルである。名称に「ダイヤルイン」という言葉を含むことからわかるように、元来はダイヤルアップ・インターネット接続サービスを実現することを目的として開発された。しかし、常時接続方式のインターネット接続サービス、無線LAN、VLAN、コンテンツ提供サービスなどのサービス提供者側設備において、認証とアカウンティングを実現するプロトコルとして幅広く利用されている。

引用元: RADIUS - Wikipedia

となっていまして、ざっくり言うと「ダイアルアップやPPPoE等でインターネットに接続する際のユーザ名/パスワードを認証する機能」を提供するシステムです。

RADIUSプロトコルを用いた通信は、家庭のパソコンやルータ等ではなく、接続を終端するNAS1/RAS2〜RADIUS間となります。

RADIUSの一般的なシーケンスは、下図のとおりです。

RADIUSの一般的なシーケンス

リプレース前に抱えていた課題

ISPにとって重要システムであるRADIUSですが、当時、下記のような課題を抱えていて、サービスの安定提供に影響を与えかねず、また運用管理上の煩雑さが課題となっていました。

  • ソフトウェアが古く、機能不足・不安定
    • DTC RADIUS Ver2.0.3p8(1999年5月リリース)
    • IPv6対応不可
    • 大量リクエスト時に処理を取りこぼす事も
  • 細かい制御ができない
    • 1接続アカウントで、複数の場所からの同時接続は禁止したい
    • 当時のソフトウェアでも、同時接続を制限する機能自体はあった
    • 一方、サービス仕様では、1アカウントでブロードバンドを1つ、モバイルを1つの同時接続を許可
    • そのため、同時接続制限機能を有効にできなかった
  • テキストベースの管理
    • 認証情報(接続アカウント/パスワード等)は、サーバ上のテキストファイルにて管理
    • 接続履歴も、テキストファイルに保存
    • どちらもテキストファイルのため、管理しづらい
    • 接続履歴からの分析などに手間がかかっていた

このような課題を抱えていた当時のシステム構成は、下図のとおりです。

以前のシステム構成

これらの課題解消のため、リプレースの検討を進め、当初「FreeRADIUS」と「rlm_sql」にて実装することを検討していました。

FreeRADIUS

「FreeRADIUS」は、高速・高機能・モジュラー型・高拡張性という特徴を持つRADIUSの実装の1つで、GPLv2のライセンスの元、オープンソースとして公開されているソフトウェアです。

rlm_sql

「rlm_sql」は、FreeRADIUSの拡張モジュールの1つで、認証情報/接続履歴を外部データベースから参照/保存することが可能とするものです。

実際には、rlm_sqlモジュールのみで動作するものではなく、利用するデータベースにあわせてバックエンドドライバーを選択して利用します。

対応している主なデータベースは、MySQL/Oracle/PostgreSQLです。

このrlm_sqlにて、サービス仕様に沿った処理の実装を進めましたが、比較的早い段階で断念しました。

というのも、rlm_sqlではデータベースに対し、認証用テーブル/接続履歴保管用テーブルを参照/保存する程度の処理しかできず、シナプスの接続サービスの複雑なサービス仕様に適合させらませんでした。

複雑なサービス仕様

シナプスでは1995年のサービス開始以降、何度か接続コースのラインナップの改変・統廃合・追加・削除を行ってきましたが、その時世にあわせた接続コースを提供してきたため、サービス仕様が複雑になっています。

いくつか、その複雑さを紹介しますと、

兎にも角にも組み合わせが多すぎる

接続サービスに関連するパラメータとしては、下表のようになっていて、これらの組み合わせによって、接続許可・接続拒否の判断をする必要があります。

項目 種類
接続コース 69
対応する回線の種類 55
ISP識別子 35
接続コースに付随するオプション 6
回線の種類毎の同時接続数のパターン 2

固定IPアドレス接続コースの不可解な仕様

固定IPアドレスを提供する、とある接続コースでは、1つのユーザ名/パスワードにて、下記の同時接続を許容するサービス仕様になっていたり。

  • 固定IPアドレスによるブロードバンド接続 1本
  • 動的IPアドレスによるブロードバンド接続 1本
  • モバイル接続 1本

救世主となった「rlm_perl」

rlm_sqlでは実現不可と判断した後に検討したのが、「rlm_perl」でした。

このrlm_perlは、rlm_sqlと同様にFreeRADIUSの外部モジュールの1つで、認証やアカウンティングなどのロジックをPerlスクリプトに記述することができるものです。

ここで用いるPerlスクリプトから、データベースの参照やSyslogの出力も可能となっています。

最終的に、前述した複雑なサービス仕様は、Perlスクリプトによるコード化とデータベースによって、全て実装しました。

Perlスクリプトの簡略化すると下記のようなり、RADIUSのAccess-Requestのアトリビュートは、RAD_REQUESTのハッシュに格納され、それを処理する流れです。

sub authenticate {
    if ($RAD_REQUEST{'User-Name'} eq 'valid_user' &&
        $RAD_REQUEST{'User-Password'} eq 'valid_pass' &&
        $RAD_REQUEST{'NAS-IP-Address'} eq '192.0.2.1') {
        return RLM_MODULE_OK;
    }
    return RLM_MODULE_REJECT;
}

こうして、FreeRADIUS + rlm_perl + Perlスクリプトの組み合わせにより、下図のようなシステムを構築しました。

新しいシステム構成

新システムのパフォーマンス

できあがったシステムですが、全てのサービス仕様を網羅する事に加えて、「適切なパフォーマンス」を要しているかも重要なポイントです。

ベンチマークテストを行った結果、事前に見積もった要求性能に対して、十二分に対応できる性能ができることが確認できました。

項目 要求性能 本番性能
認証要求(Access-Request) 135 1,143
アカウンティング要求(Accounting-Request) 135 875

新システムのパフォーマンス

あわせて実現したこと

今回のリプレースにあわせて、新たに実現できたこととして、以下のようなものがあります。

  • お客様のご解約後の自動接続解除
    • リプレース以前は、お客様のご解約後でもインターネット接続は、お客様にて切断しない限り接続は継続
    • リプレース後は、RFC3576のDisconnect Mesagesに対応し、自動的に切断
  • サポート部門向けの管理ツール
    • リプレース以前は、接続中の情報/過去の履歴/認証エラー等の検索機能が分散していて、使いづらいものでした
    • リプレース後は、お客様毎に接続中の情報/過去の履歴/認証エラー等の情報を集中表示するようにしました
  • 利用者特定
    • 発信者情報開示請求や、abuse対応時など、利用者を特定する機能の整備を行いました

まとめ

ISPの重要なシステムの1つであるRADIUSを半分自社開発したことで、下記の知見を得ることができました。

  • FreeRADIUS + rlm_perlの組み合わせは自由度が高い
    • FreeRADIUSはRADIUSプロトコルの終端のみで利用し、認証ロジックはPerlスクリプトに委譲可能
    • どんなに複雑なサービス仕様でも、コード化さえできれば実現可能
  • 接続履歴をデータベースに保存すると便利
    • abuse対応時など、利用者特定も簡単
    • 集計や分析などの2次利用も容易となり、障害傾向も早期に発見できるようになった
  • サービス仕様はシンプルにしておくべき
    • サービス仕様が複雑すぎたため、必要以上にコード化に苦労した
    • また、仕様にあわせたテストパターンも膨大に

最後に、シナプスでは、今後もサービスの安定提供に向けて取り組んでまいりますので、今後ともシナプスとシナプス技術者ブログをよろしくお願いします。

  1. Network Access Server↩

  2. Remote Access Server↩