「認証サーバーダウン」＝「全社員業務停止」の恐怖。
こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回にわたるFreeRADIUS講座も、今回でついに最終回です。
これまで、基本構築からDB連携、GUI管理、証明書認証、多要素認証、ログ分析と、FreeRADIUSの機能をフル活用してきました。
しかし、どんなに高機能なサーバーでも、機械である以上いつかは壊れます。
先生、想像しただけで胃が痛いです…。
もし朝出社して、Wi-Fiが繋がらなくなってたら。
もしOSのアップデートでFreeRADIUSが起動しなくなったら。
全社員から「ネット繋がらないぞ！」って電話が殺到するんですよね？ 僕一人じゃ対応しきれません！
そう、認証サーバーはインフラの「心臓部」。ここが止まると全てが止まるわ。
だからこそ、トラブルが起きた時に「3分で原因を特定するスキル」と、そもそも1台壊れても動き続ける「冗長化（冗長構成）」が不可欠なの。
最後は、インフラエンジニアとして最も大切な「守り」の技術をマスターして締めくくりましょう！
今回は、FreeRADIUS運用の総決算。
エラーログから原因を特定するフローチャートと、サーバーを2台並べて可用性を高めるフェイルオーバー構成、そして自作スクリプトによる死活監視までを徹底解説します。
🔐 FreeRADIUS完全攻略講座（バックナンバー）
これまでの知識がトラブルシューティングの基礎になります。
第1章：トラブルシューティングの基本フロー
「繋がらない！」と連絡が来た時、闇雲に設定ファイルをいじってはいけません。
以下の手順で冷静に切り分けを行いましょう。
Step 1: サービスの状態確認
まずはFreeRADIUS自体が起動しているか確認します。
sudo systemctl status radiusd
- Active: active (running) → プロセスは生きています。Step 3へ。
- Active: failed → プロセスが死んでいます。Step 2へ。
Step 2: 起動エラーの原因特定（radiusd -X）
サービスが落ちている場合、systemctl start で無理やり起こそうとする前に、必ずデバッグモードで起動して「なぜ死んだか」を聞き出します。
# まずサービスを完全に止める sudo systemctl stop radiusd # デバッグモードで起動 sudo radiusd -X
画面の最後の数行に Error や Fatal という文字と共に原因が表示されます。
Step 3: ネットワークとポートの確認
プロセスは生きているのに繋がらない場合、ファイアウォールかネットワークの問題です。
# ポートが開いているか確認 sudo ss -ulnp | grep radiusd
udp 1812 と udp 1813 が表示されていますか？
表示されていなければ、設定ファイル（radiusd.conf）の listen セクションが間違っている可能性があります。
表示されているなら、firewall-cmd --list-all でファイアウォールの設定を確認してください。
Step 4: 認証テスト（radtest）
サーバー内部からは繋がるかを確認します。
radtest testuser password localhost 1812 testing123
- これで成功する → クライアント（AP）とサーバー間の通信経路や、Shared Secretの間違いが疑われます。
- これで失敗する → ユーザーID/PASS間違い、DB接続エラーなどが疑われます。
第2章：よくあるエラーメッセージと対処法（逆引き事典）
デバッグモード（radiusd -X）で表示される代表的なエラーとその対策をまとめました。
Case 1: “Address already in use”
意味： ポート（1812/1813）が既に使用されています。
原因： systemctl で起動したまま、radiusd -X を実行しようとした場合によく起きます。
対策： sudo killall radiusd で全てのプロセスを殺してから、再度実行してください。
Case 2: “Could not link driver rlm_sql_mysql”
意味： MySQL用のドライバが見つかりません。
原因： 第3回で解説した freeradius-mysql パッケージがインストールされていないか、バージョン不整合です。
対策： sudo dnf install freeradius-mysql を実行してください。
Case 3: “Ignoring request to auth address … from unknown client”
意味： 知らないクライアント（ルーター）からのリクエストなので無視しました。
原因： clients.conf に、接続元のルーター（AP）のIPアドレスが登録されていません。
対策： clients.conf に正しいIPとSecretを登録し、再起動してください。
Case 4: “Access-Reject” (Password incorrect)
意味： パスワードが間違っています。
原因： 単純な入力ミスか、DBへの登録形式ミス。
対策： EAP-PEAP(MSCHAPv2)の場合、パスワードは Cleartext-Password で登録する必要があります。MD5などでハッシュ化していないか確認してください。
Case 5: “Child PID … is dying”
意味： 処理プロセスがクラッシュしています。
原因： メモリ不足、またはスレッド数の設定ミス。
対策： radiusd.conf の max_servers などの値を下げるか、サーバーのメモリを増設してください。
第3章：冗長化（Redundancy）の基本戦略
トラブル対応も大事ですが、そもそも「1台壊れてもサービスを止めない」構成にしておくのがプロの仕事です。
RADIUSサーバーの冗長化には、大きく分けて2つのアプローチがあります。
| 方式 | 仕組み | 難易度 | コスト |
|---|---|---|---|
| クライアントサイド フェイルオーバー |
Wi-Fi APの設定で「プライマリ」「セカンダリ」の2台を指定する。 | 低 | 低 |
| ロードバランサ (VIP) 方式 |
RADIUSの前にロードバランサ（仮想IP）を置き、負荷分散する。 | 高 | 高 |
今回は、追加機材が不要で、AlmaLinuxサーバーをもう1台用意するだけで実現できる「クライアントサイドフェイルオーバー（Active/Standby）」構成を採用します。
第4章：セカンダリサーバーの構築と同期
2台目のサーバー（セカンダリ）を用意し、1台目（プライマリ）と同じ設定をコピーします。
1. セカンダリサーバーの準備
第1回〜第3回の手順に従い、FreeRADIUSとMariaDBをインストールします。
IPアドレスは 192.168.1.101 とします。
2. 設定ファイルの同期
プライマリサーバーの設定ファイル（/etc/raddb/）を、セカンダリにコピーします。rsync コマンドを使うのが便利です。
プライマリサーバー上で実行：
# raddbディレクトリをセカンダリへ転送 sudo rsync -avz -e ssh /etc/raddb/ root@192.168.1.101:/etc/raddb/
※特に clients.conf、mods-enabled/、sites-enabled/、そして certs/（証明書）の同期が重要です。
証明書が異なると、フェイルオーバーした瞬間にクライアントPC側で「証明書エラー」が出て繋がりません。
3. データベースの同期（レプリケーション）
ユーザー情報はDBにあるため、DBも同期する必要があります。
本格的には「MariaDBレプリケーション（Master-Slave）」を組むべきですが、簡易的には mysqldump で定期コピーでも運用可能です。
プライマリでバックアップ：
mysqldump -u root -p radius > radius_backup.sql
セカンダリでリストア：
mysql -u root -p radius < radius_backup.sql
これをcronで夜間に実行すれば、前日までのユーザー情報は同期されます。
第5章：Wi-Fiアクセスポイント側の設定
サーバーが2台あっても、Wi-Fiルーター（NAS）がそれを知らなければ意味がありません。
APの管理画面で、RADIUSサーバーの設定を変更します。
設定項目（例）
- プライマリサーバー IP: 192.168.1.100
- プライマリ ポート: 1812
- プライマリ Secret: mysecret123
- セカンダリサーバー IP: 192.168.1.101
- セカンダリ ポート: 1812
- セカンダリ Secret: mysecret123
多くの業務用AP（Cisco, Aruba, Yamaha, Buffalo Proなど）には、このように2台目を設定する欄があります。
これにより、APは普段プライマリに問い合わせ、応答がない場合（タイムアウト）のみセカンダリに問い合わせるようになります。
⚠️ 重要：タイムアウト設定
AP側の「RADIUSタイムアウト」設定が長すぎると（例：30秒）、プライマリが死んだ時にユーザーは30秒待たされることになります。
推奨は「3秒〜5秒」程度です。
第6章：自作スクリプトによる死活監視
サーバーが死んだらすぐに気づけるよう、簡単な監視スクリプトを作ってみましょう。radtest コマンドの結果を見て、失敗したらメールやSlackに通知する仕組みです。
監視スクリプト例（monitor_radius.sh）
#!/bin/bash
# 監視対象
TARGET_IP="192.168.1.100"
USER="monitor_user"
PASS="monitor_pass"
SECRET="testing123"
# radtest実行
RESULT=$(radtest $USER $PASS $TARGET_IP 1812 $SECRET)
# 結果判定
if echo "$RESULT" | grep -q "Access-Accept"; then
echo "OK: RADIUS is alive."
exit 0
else
echo "CRITICAL: RADIUS is DOWN!"
# ここにメール送信やSlack通知コマンドを書く
# mail -s "RADIUS DOWN" admin@example.com < /dev/null
exit 1
fi
このスクリプトを、監視用の別サーバー（またはセカンダリサーバー）のcronに登録して、5分おきに実行させれば、簡易監視システムの完成です。
*/5 * * * * /path/to/monitor_radius.sh
講座まとめ：あなたはもう「認証基盤の守護者」だ
全8回、本当にお疲れ様でした。
ここまで読み進め、手を動かしたあなたは、もうFreeRADIUS初心者ではありません。
認証基盤の構築から、セキュリティ強化、ログ分析、そして障害対応までこなせる「認証のエキスパート」です。
FreeRADIUS完全攻略講座 修了チェックリスト：
- ✅ FreeRADIUSのインストールと基本設定ができる。
- ✅ MySQL(MariaDB)と連携し、大量のユーザーを管理できる。
- ✅ daloRADIUSを使ってGUIで運用できる。
- ✅ 電子証明書を発行し、EAP-PEAP認証を構築できる。
- ✅ Google Authenticatorで多要素認証を実装できる。
- ✅ アカウンティングログを分析し、利用状況を可視化できる。
- ✅ ログからトラブル原因を特定し、冗長構成で可用性を担保できる。
認証システムは、地味ですがインフラの中で最も重要な役割を担っています。
あなたが構築したこのサーバーが、会社のセキュリティを守り、社員が安心して働ける環境を支えていくのです。
この講座で得た知識を武器に、ぜひ現場での課題解決に役立ててください。
リナックス先生は、あなたのエンジニアとしてのさらなる飛躍を応援しています。
また別の講座でお会いしましょう！
▼ エンジニアとしてのキャリアを加速させる ▼
冗長構成を試す
「VPS」で実験環境
サーバー知識を年収に
「ITエンジニア転職」
コメント