キャプティブポータルの見方を変えて現地情報通知にしよう

前回 ↓ の続きです。

hgot07.hatenablog.com

キャプティブポータルって、名前が悪いですね。しかも、せっかく新しい仕組みとしてCaptive Portal Architecture (RFC 8952)ができたのに、名前がそのままなので、新旧の技術が紛らわしくなっています。画面をひったくってポータルを強制するばかりが能ではないので、用途に応じて、適切な名称が欲しいところでした。

ところで、タイトルにある「現地情報通知」とかいう妙にぎこちない日本語ですが、呼び方に散々悩んだ結果こうなってしまいました_('､3｣∠)_ 英語で書くと Venue Information Notification になるのですが、ベニューってまだ日本語に十分に浸透していないと思われるので、仕方なかったのです。

なぜ「現地情報通知」なのか

言いたいことは簡単でして、画面をひったくって、ついでに通信をブロックしてまでポータルサイトを見せつけるのをやめて、現地やサービスに関する情報に誘導できる仕組みを普及させましょうということです。

eduroamやOpenRoamingのような、WPA2/WPA3 Enterpriseの無線LANの良いところは、

安全かつ自動的につながる

という点です。反対に悪いところ(?)は、

勝手につながる

という点です。

同じじゃないかって？　はい、見方が違うだけです。

現在主流のフリーWi-FiやホテルWi-Fi、空港Wi-Fiでは、暗号化すらないオープンWi-Fiとキャプティブポータルの組み合わせが一般的です。セキュリティ的に相当ヤバいので、最近ではOpenRoamingを導入する動きが徐々に出てきました。

ところが、WPA2/WPA3 Enterpriseによる無線LANでは、あの邪悪なキャプティブポータルがないことが利点でもあり、欠点にもなっています。例えば、大学などで使われているeduroamでは、利用上の注意喚起や、無線LAN経由での学内サービスの案内などを利用者に伝えたいという要望が出ることがあります。フリーWi-FiをOpenRoamingに置き換えようとすると、施設や店舗のポータルサイトに利用者を誘導する仕組みが欲しいという、強い要望が出てきたりします。

それでは、WPA2/WPA3 Enterpriseで自動接続された先にキャプティブポータルを設置したらどうでしょうか？　これでは、せっかくの自動接続の利点が死んでしまいます🫠

無線LANの接続のたびに利用規約を提示して、利用者から同意を得る必要がないなら、わざわざ通信をブロックして画面を乗っ取るようなことは、利便性を損ねる以外の何者でもないでしょう。

それでは、どうすればよいのか？

利用者をあまりイライラさせずに、必要な時だけポータルサイトにアクセスしてもらえるような仕組みを作ったらどうでしょう。これが、現地情報通知の考え方です。

実は既に一部OSではこのような使い方ができるようになっています。Android 11以降では、無線LANに接続された際に「ぴろん♪」と通知音が鳴り、通知アイコンが表示されます。通知を見ると、ポータルサイトを開くためのリンクがあります。利用者は容易にポータルにアクセスできます。

他のOSではどうでしょうね？

実はこの辺がまださっぱりできていないのです。仕方がないので、旧式のキャプティブポータルの仕組みも併用して、現地情報通知に特化したプログラム群を作成してみました。一応、スライドと原稿にすべて書かれているのですが、ブログ形式でも紹介します。

参考文献:

GitHub - hgot07/VenueInfoHandler: API/CGI for Venue Information display on Public Wi-Fi
後藤英昭, 原田寛之, 漆谷重雄, ``eduroam/OpenRoamingにおける現地情報通知 (Venue Information Notification on eduroam/OpenRoaming),'' 大学ICT推進協議会 2023年度年次大会論文集 14PM2Y-1, 2023. (paper, slides)

Passpoint Release 3の場合

Passpoint Release 3で、Venue URLという属性値が定義されました。hostapdでも既に利用可能です。使い方はいたって簡単で、基地局側の設定で、Venue URLにポータルサイトのURLを書き込んでおくだけです。端末はこの情報を見て、ポータルサイトがあることを利用者に通知……するはずですが、OS側の対応がさっぱりです。

執筆時点で、Android 12以降、Windows 11 23H2以降で動作確認できていますが、まだ非互換性が青々としています。iOS/iPadOSは、まだPasspoint Rel.1にしか対応していないという有様。

何といっても、この手段はPasspointの環境でしか使えないという、大きな制約があります。有線LANでは使えません。というわけで、筋が悪いので、上記のVenue Info Handlerではガン無視しています。

Captive Portal APIを使う方法

現時点では、これが最も優れた汎用的な手法と思われます。Captive Portal API (RFC 8908)の概要については、前回のエントリも参照してください。

設定は実に簡単です。DHCP option 114またはRouter Advertisementで、APIのURLを指すようにします。APIは、JSON形式で次のような応答を返すようにします。CGI スクリプトで簡単に作れますね。

{
"captive": false,
"user-portal-url": "https://portal.example.com/",
"venue-info-url": "https://venueinfo.example.com/"
}

captiveがfalseになっているところがキモです。画面をひったくるようなキャプティブポータルは使わないので、falseにします。

user-portal-urlは、ログイン用の画面などを表示するためのウェブページを指しますが、今回はAPIを置いたサイトを指していれば十分です。

venue-info-urlが重要で、利用者を誘導する先のポータルサイトを、ここに指定します。

Android 11以降では、無線LANに接続された際に通知音が鳴り、通知アイコンが表示されます。通知の中に、ポータルサイトを開くためのリンクがあります。

その他のOSのCaptive Portal API対応状況を調べて、ここにまとめてあります。実を言うと、全然だめです。

iOS/iPadOSは17から通知が出るようになりましたが、Wi-Fi設定の奥に潜っていかないと見えません。通知音など一切ありません。誰が気付くんでしょうね？

macOS Ventura以降もAPIに対応していますが、通知機能がありません。

ベンダ独自のキャプティブポータル機能を使う

多くのOSで、Captive Portal APIによる通知ができないので、ベンダ独自実装を使ってワークアラウンドを試みます。

ただし、キャプティブポータルの機能は一般にアクセス制御と抱き合わせになっていて、通信がブロックされてしまうので、これを回避できるようなロジックを入れます。これがないと、せっかく自動接続できる無線LANシステムでも、接続先が切り替わった途端に、通信が途切れることになります。(歩きながらストリーミングしていたらコンビニのWi-Fiにつながって通信が切れたと話題になったアレ)

ChromeOS, Android 10

Captive Portal APIに非対応なので、Googleの独自方式を使ってキャプティブポータルを発動させます。ChromeOSでは、コンソールの通知欄に小さな表示が出るだけなので、気付きにくいという問題があります。Android 10では、全画面表示のポータル画面がミニブラウザで表示されてしまいますが、利用者が特に操作しなくても、端末が通信をブロックすることはありません。