はじめに
クラウドRADIUSを使ったWi‑Fi認証の話になると、まず出てくるのが次の不安です。
「クラウドRADIUSに届かなくなったら、Wi‑Fi はどうなるのか。」
このテーマを気にするのは、主に導入を検討する販売店やSIerの方だと思います。エンドユーザーは、クラウドRADIUSの到達性や再認証のタイミングまで細かく意識することは多くありません。一方で、提案する側は、お客様のネットワークにとって無理のない構成か、障害時も含めて納得感のある提案になっているかを気にします。
SMB向けWi‑Fiでは、いまでも共有パスワード運用が多く残っています。ですが、入退社や異動、端末の追加・紛失といった場面で利用者ごとに管理しようとすると、それだけでは限界があります。
そこで選択肢になるのが、SingleID と連携した WPA2/WPA3-Enterprise 認証です。共有パスワードではなく、個人ごとに証明書で認証できるので、利用者単位で管理しやすくなります。
ただ、ここで一度押さえておきたいのは、クラウドRADIUSとの通信が必要なのは、主に認証が発生するタイミング だという点です。クラウドRADIUSに届かなくなると、すぐに Wi‑Fi 全体が切れるように受け取られがちですが、実際にはそう単純ではありません。すでに接続している端末の通信そのものは続く一方で、新規接続や再認証のタイミングでは影響を受けます。
つまり今回の話は、「クラウドRADIUSに届かないと Wi‑Fi が全部止まる」という前提で考えるよりも、認証が必要になる場面でどう備えるか として考えると分かりやすくなります。
今回検証したのは、BUFFALO法人向けAP（AirStation Pro / WAPMシリーズ）側の機能である Link Integrity を使った構成です。普段は SingleID連携SSID を有効にし、障害時だけ緊急用の PSK用SSID へ切り替える構成が実際にどう動くのかを確認しました。
Link Integrity は、あらかじめ指定した監視先への疎通を見ながら、条件に応じて AP の動作を切り替えるための仕組みです。
検証構成
今回の検証で実際にフェイルオーバー動作を確認したのは、AP のデフォルトゲートウェイを監視先にした構成 です。検証では、デフォルトゲートウェイ側を意図的にダウンさせ、Link Integrity による切替挙動を確認しました。
この構成では、
- SingleID連携SSID：平常時に有効。本命の WPA2/WPA3-Enterprise 認証SSID
- PSK用SSID：平常時は無効。障害時だけ有効化する緊急用SSID
- 監視先への疎通が失われた時だけ、SSID の有効／無効を切り替える
ポイントは、PSK を最初から“普段から使えるSSID”として置いておかないこと です。常時使える状態にしてしまうと、共有パスワード運用へ戻りやすくなります。
検証で確認できたこと
1. 障害時には SSID を切り替えられる
Link Integrity により、監視先への疎通が失われると、SingleID連携SSID を無効化し、PSK用SSID を有効化する動きが確認できました。
平常時は WPA2/WPA3-Enterprise 認証を前面に出しつつ、必要な時だけバックアップ経路を使う、という構成にできます。
2. 切替は無停止ではない
切替時には、端末の通信は一度切れます。これは HA の代替ではなく、長く止まり続けるよりは、いったん切れても最低限つながる状態へ退避する ための仕組みです。
導入前には、この点を認識しておいたほうがよさそうです。
3. 復旧後は元の状態へ戻せる
今回の検証では、ICMP による再確認が一定間隔で行われ、複数回の失敗後に切替が発動する挙動を確認しました。また、疎通が復活した際には、元の状態へ戻す挙動も確認しています。
重要なのは秒単位の細かな差よりも、
- 単発失敗で即切替ではない
- 一定回数の再確認後に切替される
- 復旧後は元の状態へ戻せる
という設計になっていることです。
この検証から見えたこと
今回、確認したのは、Link Integrity によるフェイルオーバー動作です。
一方で、検証中のディスカッションでは、実運用を考えるうえで次の点も論点になることが見えてきました。
- 監視先は、最終的には SingleID のクラウドRADIUSの FQDN で考えるほうが自然ではないか
- セッションタイムアウトは長めに設定したほうがよいのではないか
- 複数AP環境があるなら、PMKキャッシュも有効にしたほうがよいのではないか
つまり、検証で見えたのは Link Integrity の動きそのものですが、その結果を踏まえると、実際の設計では 監視先 や 再認証 まであわせて考える必要がありそうだ、ということです。
インターネット障害時にこの構成は意味があるのか
ここで一つ気をつけたいのは、インターネット回線障害そのものが起きている場合、PSK 側へ切り替わってもインターネットが使えるようになるわけではない、という点です。
それでも意味があるのは、社内LANへの接続継続が重要な場合 です。たとえば BUFFALO の NAS のような社内LAN上のリソースを継続して使いたい業務では、この切替は十分に意味を持ちます。
まとめ
今回の検証で確認できたのは、BUFFALO法人向けAPの Link Integrity を使うと、SingleID連携SSID と緊急用SSID を切り替える構成が現実的に組める、ということでした。
ポイントをまとめると、次の3つです。
- クラウドRADIUSと通信するのは、主に認証が発生するタイミング
- Link Integrity によって、障害時だけ緊急用SSIDへ切り替える構成が取れる
- 実運用では、監視先を SingleID の FQDN にすることや、セッションタイムアウト、必要に応じた PMKキャッシュもあわせて考える必要がある
今回の記事は、あくまで Link Integrity の検証レポートです。
次回は、この検証結果を踏まえて、
- まずは SingleID 側の可用性を前提に運用する
- 必要に応じてセッションタイムアウトやPMKキャッシュを見直す
- さらに必要なお客様には Link Integrity による自動切替も検討する
という形で、どこまで可用性対策を求めるかを段階的に考えるベストプラクティス をまとめます。
