hgot07 Hotspot Blog

主に無線LANや認証連携などの技術についてまとめるブログです。ネコは見る専。

素のEAP-TLSは安全とは言えない

プライバシー保護の点では……

 

無線LANなどの認証プロトコルとしておなじみのEAP-TLS。ID・パスワードを使うEAP-TTLSやPEAPと比べて、より優れたセキュリティを実現できるものとして、二重丸が付けられた比較表などをよく見かけます。ところがこれ、うたい文句通りに受け取ってはいけないものだったりします。

  "パスワードレスなんだ~!証明書を使うなら安全だね!" 😇

ま、まて、まて……🫠

 

以下、このようなお話です。

  • 基本形のEAP-TLSには、認証のセキュリティは高くても、証明書の中身が基地局やハブの事業者にも見えるという、プライバシー保護上の問題がある。
  • プライバシー保護の観点で、基本形のEAP-TLSは、EAP-TTLSやPEAPに劣る。
  • EAP-TLSもトンネルで保護してみよう
  • OSの対応は今後の課題

 

何が問題なのか?

素のEAP-TLSの何が問題なのかというと、ズバリ、プライバシー保護が不十分です。プライバシー保護も広義のセキュリティに入れるなら、安全とは言えなくなります。

ところでさっきから頭に「素の」と書かれているのはいったい?🤔

WPA2/WPA3 Enterpriseの無線LANでは、ID・パスワード方式のEAP-TTLSやPEAPよりも高いセキュリティが欲しいといった時に、RFC 5216の (基本的な) EAP-TLSが利用されることがあります。処理の大雑把な流れとしては、正規の認証サーバに接続しているかどうかを端末が検証するための「サーバ認証」が行われ、検証結果が正しければ、反対に端末が正規の利用者のものかを検証するための「クライアント認証」が行われるという、双方向認証になっています。

サーバ認証とクライアント認証のそれぞれで、電子証明書を用いた認証が行われます。認証のセキュリティがどうのという議論は、ここでは行いません

最近問題視されるようになったのは、プライバシー保護です。例えば、公衆無線LANの利用者がどこそこの店のアクセスポイントを使って、その後はどの店に行って、夕方にはよくこの辺に居るからおそらく自宅はこの辺……といった行動情報は、プライバシーに関わるものです。公衆無線LANの事業者には、利用者から同意なくこのような行動解析を行わないことが求められています。

しかし、中にはプライバシー保護がザルの事業者もあるかもしれない(?)ので、利用者側の対策として、端末に「MACアドレスランダム化」などの仕組みが入るようになりました。利用者認証 (または端末認証)のある無線LANでは、IDも利用者の追跡に使えるので、これを保護するための仕組みがEAP-TTLSやPEAPには用意されています。具体的には、端末と認証サーバの間にTLSトンネルを作り、基地局やハブを運用する事業者にはIDを見せないようにします。詳しくは以前の記事を見てください。

hgot07.hatenablog.com

EAP-TLSのどこで情報が漏洩するか

EAP-TTLSやPEAPと違い、(基本形の) EAP-TLSにはトンネルがありません。TLS 1.2の場合、証明書の情報が平文で通信路を流れます。クライアント証明書には利用者を識別するためのIDに相当するSubjectが含まれており、これも平文で流れます。

より具体的には、Serial Number, Issuer, SubjectなどがEAP-Messageに平文で含まれており、基地局やハブの事業者にも見えます。実際の利用者と紐づかないとしても、このように長期間に渡るユニークな固定値は、利用者端末の追跡に悪用される恐れがあります (実際は悪質な事業者とはローミングしないように運用されるのですが)。

  マジか?

なんでしたら、RADIUS proxyのところでEAP-Messageを眺めてみましょう。FreeRADIUSなら、radiusd -fxx -l stdout でデバッグメッセージを出して、EAP-Messageを簡単にダンプできます。

EAP-Messageの例

EAP-Messageの例

アカウントを発行して認証処理を行うIDプロバイダが、自身も基地局を運用する場合は、データがその事業者に閉じているので、問題は生じません。一方、ローミング環境では、データ利用に関する合意がない限り、他の事業者に実IDを秘匿することが推奨されています。

なお、TLS 1.3の0-RTT (Zero Round Trip Time)なら大丈夫という説もありますが、0-RTTはリプレイ攻撃に弱いという別の問題があります。(識者におまかせ)

[2024/2/28追記] RFC 5216 2.1.4にPrivacyの記述がありますが、オプションなので常に利用できるわけではありません。

 

トンネルで保護してみよう

証明書のやり取りをトンネルで保護すればよいのでは?
(一応、EAP-TLSTLS 1.3を使えという声もあるのですが、今後の課題)

そう、こんなこともあろうかと、使えそうな手法が用意されています。EAPを考案した人たちの洞察力には恐れ入ります。

EAP-TTLSやPEAPを使う方法があります

 

 "EAP-TTLSやPEAPって、ID・パスワードを使う方式なんでは?" 🤔

 

なんと、これも違うんですよね。EAP-TTLSやPEAPでは、端末と認証サーバの間にトンネルを掘った後に、phase2として、PAPやMSCHAPV2などの認証が行われます。実は、サーバ証明書を用いた認証も、このトンネルの中で行うことができます

参考文献はこちら ↓

learn.microsoft.com

PEAPMicrosoft独自の方式で、標準化されていないので、使うなら EAP-TTLS の方でしょう。Passpointでも、EAP-TTLS は仕様に盛り込まれていますが、PEAPはありません。

具体的には、EAP-TTLSのトンネルの中でEAP-TLSを実行する方法があります。この方法を何と呼ぶのが適切か分かりませんが、EAP-TTLS/PAP のような表記に習えば、EAP-TTLS/TLS あたりでしょうか。これだと EAP-TTLS or EAP-TLSのように誤解されそうな気もします。

 

とりあえず、やってみましょう

こんなEAP-TLS用の eapol_test.conf があったとします (wpa_supplicant.conf でも同様)。EAP-TLSでは identity= のレルムさえ合っていればよく、ユーザIDは匿名で構いません。

network={
        ssid="onin_no_LAN"
        key_mgmt=WPA-EAP
        proto=RSN
        eap=TLS
        identity="anonymous@example.com"
        domain_suffix_match="idp.example.com"
        client_cert="/etc/wpa_supplicant/XxV1ZaqB.cer"
        private_key="/etc/wpa_supplicant/XxV1ZaqB.key"
        private_key_passwd=""
}

eapol_test -c eapol_test.conf -s testing123 とかすれば、SUCCESSが返ってきます (証明書が検証に通れば!)。

上のファイルを、下のように書き換えます。

network={
        ssid="onin_no_LAN"
        key_mgmt=WPA-EAP
        proto=RSN
        eap=TTLS
        identity="anonymous@example.com"
        domain_suffix_match="idp.example.com"
        domain_suffix_match2="idp.example.com"
        phase2="autheap=TLS"
        client_cert2="/etc/wpa_supplicant/XxV1ZaqB.cer"
        private_key2="/etc/wpa_supplicant/XxV1ZaqB.key"
        private_key2_passwd=""
}

(あっ、"2" ってこういう風に使うんだ……)

これだけです!

認証サーバにFreeRADIUSを使っているなら、サーバ側の変更は不要です。

 

OSの対応状況

EAP-TTLSのトンネルでEAP-TLSが使えるかどうか、各種OSの対応状況をざっくりと調べてみた結果が以下のとおりです。

Linux, OpenWrt

wpa_supplicant ベースなら、先に書いたとおりで、対応可能です。

Windows

できました 😇

p12形式の証明書ファイルを読み込ませて、まずはEAP-TLSの設定を済ませておきます。その後、設定メニューの「既知のネットワークの管理」で「高度なWi-Fiネットワークプロパティ」を編集して、認証方法をEAP-TTLSに変更します。さらに、「認証にEAPメソッドを選択する」の中でEAP-TLSを選択します。

EAP-TTLS/TLSの設定 (Windows 11)

EAP-TTLS/TLSの設定 (Windows 11)

どのクライアント証明書を使うかの設定が見当たりませんが、SSID一覧から実際にSSIDを選択して接続しようとすると紐づける証明書を聞いてきます。

ウェブベースプロビジョニングで使うms-settings: URI スキームの対応状況は、まだ確認できていません。これが使えないと、一般の利用者に使わせるのは困難です。

macOS, iOS, iPadOS

プロファイルのリファレンスを眺めてみたのですが、該当する設定が見当たりません。

Android

Android 13の設定画面によると、EAP-TTLSのフェーズ2認証に選択できるのは、PAP, MSCHAP, MSCHAPV2, GTC だけで、TLSはありません。

ウェブベースプロビジョニングで用いられるPPS MO形式のプロファイルには、そもそも Phase2 の概念がなさそうです。

APIで設定できるかどうかは未確認です。

ChromeOS

Open Network Configuration (ONC)のドキュメントによると、Innerに指定できるのは Automatic, MD5, MSCHAP, MSCHAPv2, PAP, CHAP, GTC だけで、TLSはありません。

 

うーん_('、3」∠)_

どうしますかね、この問題……

TLS 1.3が主流になればプライバシー問題は自然と解消されるという、気の長い見方もあるようです。即効性のある対策として、EAP-TTLS/TLSは悪くないと思うのですが、対応OSが限られるのが悩みの種です。

 

おしまい

OpenWrtをTOKYO FREE Wi-Fiにつなげてみよう! (他のOpenRoamingでもOK)

[2024/1/27追記] ドメイン名の指定に間違いがあったので修正しました。

2023年3月末からOpenRoaming対応になった新生TOKYO FREE Wi-Fiに、OpenWrt箱を接続してみましょう。OpenRoamingに非対応の機器も接続できるモバイルルータが作れます。といっても、Passpointプロファイルさえ取得できれば、TOKYO FREE Wi-Fiに限りません。国内外のOpenRoaming対応のフリーWi-Fiでも使える技を紹介します。

(おやくそく) プロファイルを仕込んだルータの盗難には十分気を付けましょう。

 

OpenWrt箱を用意する - Mangoはどう?

結論から述べるとMangoではダメでした_('、3」∠)_

(急ぎたい人は次章へどうぞ)

手元にお役御免になったGL.iNet Mango (GL-MT300N-V2)があったので、最初にこれを試しました。今となってはCPUがだるいほど遅いし、2.4GHz帯専用だし、簡単にメモリ不足になるので、新規に購入することは奨めません。ちょっとどころじゃなく大きくなってしまいますが、これから買うなら、同社のSlate Plus (GL-A1300)より新しいモデルがよいでしょう。

ところで、かわいい筐体で大ヒットしたMangoですが、当初はOpenWrt 19.xベースで長いことアップグレードが止まっていました。一応、GL.iNet版ではなくOpenWrt版の21.x系ファームウェアが出てPasspoint (Hotspot 2.0)も使えるようになったのですが、公式ファームウェアが出ませんでした。ところが2023年になって突然、22.x系の公式ファームウェアが登場しました。執筆時点で Version 4.3.7 が出ているので、まずこれにアップグレードします。

手元のMangoは Version 3.105 といういにしえのファームウェアが入っていましたが、まずこれを 3.203 に上げて……と思ったら、GL.iNet ADMIN PANELのUPGRADEメニューではなぜかアップグレードできません。仕方がないので、MORE SETTINGS> AdvancedからLuCIを起動して、そちらでファームウェアを焼きます。ダウンロードできる最新版が 3.216 だったので、それを焼きました。(いきなり4.x系を焼いてもよいかも)

続いて、同様の手順で 4.3.7 を焼きます。設定内容は以降できないので、初期設定からスタートします。

ほい!

Version 4.3.7にアップグレード

Version 4.3.7にアップグレード

まって、初期状態でもうメモリがぱんぱんです;;

Version 4.3.7の中身は、OpenWrt 22.03.4でした。WPA2 Enterpriseを使うのに必要な wpa-supplicant パッケージをインストールしようにも、メモリ不足で入りません。いきなりの試合終了です

 

OpenWrt箱を用意する - Slate Plusにしてみた

[2024/1/28追記] 執筆時点の純正ファームウェア (OpenWrt 21.02ベース) では、PasspointのANQPが正常動作しないことが判明しました。OpenRoamingが採用しているRCOIマッチングの方は動きますが、基地局によっては接続できないことがありそうです (RCOIが4個以上登録された基地局)。この機種を使う場合はご了承ください。

GL.iNet Slate Plusも、Slate AXやBeryl AXと比べるともっさりしたCPUですが、モバイル用途ならまだ我慢できるかなと。たまたま()手元にあったので、今回はこれを使ってみます。

Slate Plus (左)とMango (右)

Slate Plus (左)とMango (右)

執筆時点のファームウェアはバージョン4.4.6で、OpenWrt 21.02.2ベースでした。

GL-A1300 overview

GL-A1300 overview

古いモデルと違って、最初からwpad-openssl (フル版wpad)がインストールされているので、-basic から入れ替える手間がありません。

http://192.168.8.1/cgi-bin/luci にアクセスして、LuCIの方から設定していきます。Wirelessメニューの中でWPA2/WPA3 Enterpriseのクライアント設定に進みます。radio0またはradio1のAddボタンをクリックします。

Wireless Overview

Wireless Overview

Device Configuration

Device Configuration

Device Configurationのポップアップが開くので、General Setupタブの中で、適当なESSIDを入力します。Passpointの場合、これはダミーになります。Networkはwwanを選びます。つまり、上流のネットワークにつなぐという意味です。
続いてWireless Securityタブに移動します。

Wireless Security

Wireless Security

次のようにパラメータを入力します。

  • Encryption: WPA2-EAP (strong security)
  • Cipher: "Force CCMP (AES)" にする。TKIPは使ってはいけない。
  • EAP-Method: EAP-TTLSを使うので "TTLS" を選択する。
  • Use system certificate: サーバ認証を有効にするため、必ずチェックを入れる
  • Certificate constraint (Wildcard): eap.wi2.ne.jp
    (2024/1/27:上のキャプチャ画像でSubjectの方に値が入っているのは間違いです)
  • Authentication: EAP-MSCHAPv2
  • Anonymous Identity: anonymous@tokyo.wi2.cityroam.jp
  • 802.11w Management Frame Protection: Optional

IdentityとPasswordに入力する値は、以下のようにして取得できます。

まず、(新しい方の) TOKYO FREE Wi-Fiのウェブサイトにアクセスして、規約確認の後、ソーシャルアカウントなどで認証を受けます。

TOKYO FREE Wi-Fi (OpenRoaming対応)

TOKYO FREE Wi-Fi (OpenRoaming対応)

プロファイルをダウンロードできるところまで進んだら、左上の「くわしいメニュー」を選び、プロファイルの手動設定の説明に進みます。

「プロファイルの設定」画面

「プロファイルの設定」画面

ずっと下にスクロールしていくと、「ユーザ名、パスワードを作成する」というボタンがあるので、これをクリックします。

「ユーザ名、パスワードを作成する」ボタン

「ユーザ名、パスワードを作成する」ボタン

ここで表示されたユーザ名をIdentityに、パスワードをPasswordに入力します。

Wireless Securityタブの一番下にあるSaveボタンをクリックして、Wireless Overviewに戻り、Save&Applyボタンをクリックします。

Cityroamの参加機関の基地局が近所にある場合は、ESSIDに "cityroam" を指定することで、Passpointのない802.1X認証による接続確認ができます。

※ TOKYO FREE Wi-Fiではない、他所で発行されるOpenRoamingのプロファイルも、同様に使えます。PasspointプロファイルからID・パスワードを取り出す方法はこちら ↓

hgot07.hatenablog.com

OpenWrtをPasspointクライアントとして設定する

[2024/1/29追記] 汎用に使えるように改造した hostapd.sh をGitHubで公開しました。以下の手順よりも簡単に設定できるはずです

執筆時点のOpenWrt (最新版は23.x)には、まだPasspointのクライアント機能を設定する仕組みがありません。ただし、OpenWrt 21.x以降ではPasspoint対応のwpad (hostapd, wpa-supplicant)が使われているので、一部のスクリプトを書き換えるだけで、Passpointを有効化できます。

大昔に書いた(ウソ)以下の記事を参考にして、Passpointクライアントになるように改造していきます。なお、OpenRoaming (settlement-free model)のRoaming Consortium Oranization Identifier (RCOI)が決め打ちになっているのは、ご容赦ください。

hgot07.hatenablog.com

まず、/etc/config/wireless を (お好きな) テキストエディタで開き、上で設定したものに対応する config wifi-iface ブロックを見つけます。optionが沢山並んでいますが、そこに一行だけ付け加えて、保存しておきます。

option iw_enabled '1'

まだOpenWrtに存在しないオプションなので、このままでは何も起きません。

ついでに、このファイルを別名で保存しておきます (伏線)。

# cd /etc/config
# cp wireless wireless.save

次に /lib/netifd に移動して、hostapd.sh を編集します。

# cd /lib/netifd
# cp -p hostapd.sh hostapd.sh.orig
# <お好きなエディタ> hostapd.sh

1309行目あたり (wpa_supplicant_add_network() の中)に次のような行があるので、赤字の一行を追加します。

json_get_vars eap_type identity anonymous_identity ca_cert ca_cert_usesystem

json_get_vars iw_enabled  ←これを追加

1495行目あたりから、次のように追記します。

        if [ "$key_mgmt" = "WPS" ]; then
                echo "wps_cred_processing=1" >> "$_config"
        else
if [ "$iw_enabled" = "1" ]; then
                cat >> "$_config" <<EOF
interworking=1
hs20=1
auto_interworking=1

cred={
        username="$identity"
        password="$password"
        ca_cert="/etc/ssl/certs/ca-certificates.crt"
        domain_suffix_match="$domain_suffix_match"
        roaming_consortiums="5A03BA0000"
        eap=$(echo $eap_type | tr 'a-z' 'A-Z')
        phase2="auth=$auth"
}
EOF
fi

                cat >> "$_config" <<EOF
network={
        $scan_ssid
        ssid="$ssid"
        key_mgmt=$key_mgmt
        $network_data
}
EOF
        fi
        return 0
}

ファイルを保存したら、wifiコマンドで設定を反映させます。ついでにバックアップも作っておきます。

# cp hostapd.sh hostapd.sh.save
# wifi

少し待つと…… ヽ(゚∀゚)ノ

OpenRoamingに接続された状態

OpenRoamingに接続された状態

WPA2 Enterprise用に設定したSSIDとは異なる "openroaming" というSSIDに接続されていることが分かります。That's Passpoint!

 

めでたし、めでたし……

 

コイツ、消えるぞ……

あとは自分の端末をぶら下げるSSIDを吹けばOK、楽勝!と思いきや、ここで衝撃の問題が発覚

なんと、このSlate Plusたん、リブートするとWi-Fiクライアントの設定を綺麗さっぱり忘れてしまいます。具体的には、/etc/config/wireless の中で "sta" に設定された項目が、すべて消えてしまいます。

これでは、モバイルOpenRoamingルータとして使い物にならないではないですか。

色々と探ってみたのですが、どこでこのワイプが行われているのか、まだ判りません。誰か教えて~

仕方がないので、/etc/rc.local をいじって、頭に次の二行を追加しました。(伏線回収)

cp /etc/config/wireless.save /etc/config/wireless
wifi

 

今度こそ、めでたし、めでたし! (だといいなぁ)

 

 

 

Passpointプロファイルのばらしかた (分析方法)

OpenRoamingなどで使われているPasspointは、WPA2/WPA3 Enterpriseをベースにして、さらに高度な機能 (802.11u) が盛り込まれたものです。事前共通鍵 (PSK, Pre-Shared Key) を使うWPA2/WPA3 Personalと違って、Enterpriseでは、ID/パスワードやクライアント証明書に加えて、認証方式やサーバ認証のための証明書、ドメイン名など、端末に設定する項目が多くなっています。Passpointの端末設定には、さらに多くの設定項目が必要です。このため、これらの情報を手入力するのが難しいので、端末設定には「Passpointプロファイル」と呼ばれるデータを使ったり、専用の設定アプリを使ったりするのが一般的です。

例えば、OpenRoamingに対応した (新しい) TOKYO FREE Wi-Fiでは、Passpointプロファイルと、アプリの、いずれかを用いて端末の設定が可能になっています。

ところで、Passpointプロファイルの中身は、一体どうなっているのでしょうか。この記事では、Passpointプロファイルのばらしかたを紹介します。

 

Passpointプロファイルをファイルに落とす

最近のOSには、ウェブサイトからPasspointプロファイルをダウンロードして、Wi-Fi周りの設定を容易に行うことのできる仕組みが組み込まれています。このようなWi-Fi設定方法は、web-based provisioning と呼ばれています。

Passpointプロファイルの中身を覗くために、まずファイルに落としたいのですが、普通にウェブサイトで設定ボタンをタップするとWi-Fi設定に自動的に流し込まれてしまいます。ファイルとしてダウンロードする隙がありません。

また、OS自動検出機能がウェブサイトに組み込まれていることもあり、例えばWindowsAndroid用のプロファイルを取得しようにも、User-Agent を偽装しなければいけません。要するに、面倒……

Chromeブラウザを使うと、各種OS用のプロファイルを手っ取り早くダウンロードすることができます。WindowsChromeなら、F12キーを押すことで、各種OSのエミュレーションができるモードに入ります。

ChromeでF12を押したところ

ChromeでF12を押したところ

Dimensionsの設定でOSを選びます。あとは、Passpointプロファイルを配布しているウェブサイトにアクセスして、所定の操作をするだけです。Wi-Fi設定などのメニューが自動的に開くことがなく、プロファイルがファイルとしてダウンロードできます。

 

執筆時点で、プロファイルの形式はOSごとにまちまちで、統一されていません。唯一、Androidが使用している PPS-MO (Per-Provider Subscription - Mobile Object) 形式は Wi-Fi Alliance によって制定された汎用フォーマットですが、AppleMicrosoftはこれを採用していません。

 

Android用Passpointプロファイル

Wi-Fi Alliance が制定した、PPS-MO 形式が用いられています。Android 11以降で、Wireless Broadband Alliance による拡張属性にも対応しています。

プロファイルの形式は、この辺 ↓ を見れば分かります。

プロファイルをテキストファイルとして覗いてみると、Base64っぽい文字列が出てきます。

Passpointプロファイルの中身 (Android)

Passpointプロファイルの中身 (Android)

マルチパートMIMEエンコードされているので、順番にデコードしていけばよいです。

Linuxなら、

$ base64 -d  passpoint.conf > profile.txt

Base64のデコードができます。

続いて、テキストエディタなどを使って、各パートに切り分けます。

最初のパートはXML形式で、ここに様々なパラメータが埋め込まれています。

二番目のパートは、これまたBase64っぽい内容なので、デコードします。サーバ認証用のCA証明書が含まれていることが確認できると思います。

$ base64 -d part2.txt > cacert.pem
$ openssl x509 -text -in cacert.pem | less

EAP-TTLSならば、この2パートだけです。EAP-TLSの場合は、クライアント認証のためのクライアント証明書がこの後に続きます。

 

Apple用Passpointプロファイル

macOS/iOS/iPadOS共通で、mobileconfig形式のプロファイルが使われています。XMLで記述されています。自前のプロファイルを作りたいなら、Apple Configuratorアプリでも作ることができます。

プロファイルの形式は、この文書 ↓ を見れば分かります。

Passpointプロファイルは、署名付きと署名無しの二種類があります。テキストファイルとして覗いてみて、先頭が文字化けしているように見えたら、署名付きです。

以下のようにして、署名を削除できます。

$ openssl smime -verify -noverify -inform der -in passpoint.mobileconfig -out nosign.mobileconfig

 

Windows用Passpointプロファイル

Windows 10以降で、ms-settings: URIスキームによるWi-Fi設定が可能になっています。プロファイルはXMLで記述されており、これにXML署名が付いています。署名は必須で、XMLデータの末尾 (最終タグの手前) に埋め込まれています。プロファイルを覗くだけなら単に無視すればよいです。

プロファイルの形式について、あまりまとまった文書がありません。この辺 ↓ を見て頑張って解析します。

 

Passpointプロファイルの作り方

自前のプロファイルを作るのは、色々とつまづく点が多くて、結構面倒です。プロファイルの作成を容易にするためのツールを作りました (結構前の話)。試してみたい人はどうぞ。Passpointのパラメータさえ知っていれば、様々なOSのプロファイルを作成して、ウェブサイトで配布できるようになります。

github.com

おしまい

 

Passpointプロファイルのことが分かったら、次はアクセスポイントで遊んでみたくなりませんか? (・∀・)

booth.pm

GL.iNetのOpenWrt箱をPoEで動かす

GL.iNetは様々なOpenWrtベースの無線ルータを扱っている会社です。OpenWrt 21.x以降ではPasspointも動き、WireGuardなどの各種VPNが容易に使えるということで、モバイルCityroam基地局 (eduroam, OpenRoaming込み)として、同社の様々なモデルが重宝しています。

モバイルに限らず、最近よく聞くようになった「マネージドWi-Fi」の基地局としても、小規模な店舗に転がす用には、便利に使えるのではないかと思います。

小柄なルータで、基地局VPNの機能がワンボックスで済むところはとても良いのですが、残念ながらPoE (Power over Ethernet)に対応していません。PoEが使えるなら、近くにコンセントのない場所でも使いやすいのに……

方法を探してみると、ありました、PoEスプリッターという製品が。品揃えも充実しています。以前に、MikroTik hAP acを駆動するのにDC12Vプラグ付きのものを使ったことがあります。今回は GL.iNet Beryl AX (GL-MT3000) や Slate AX (GL-AXT1800) を使いたかったので、USB Type Cのスプリッターを試してみました。これです。

 

ANVISIONからは、似た製品が各種出ています。速度でいうと、100Mbps止まりのものと、1000Mbps対応のものがあるので、うっかり安い方に飛びつかないように、仕様をよく確認する必要があります。あとは電源/USBプラグの違いです。

Beryl AXのWAN端子は2.5GbEなので、1000Mbpsまで使える方のモデルを選びました。実際に取り付けてみると、こんな感じです。

Beryl AXのPoE駆動 (その1)

Beryl AXのPoE駆動 (その1)

Beryl AXのPoE駆動 (その2)

Beryl AXのPoE駆動 (その2)

まって❤ Beryl AXには5V 3Aが必要ではないの?

えぇ、このスプリッターの定格は5V 2.4Aなので、ちょっと足りないです。しかし、Beryl AXの仕様表には消費電力8W以下と書かれています。これまで何度も2.4AのACアダプタで普通に使えたので、大丈夫ではないでしょうか。 (現場猫画像略)

さらに、良いニュースと悪いニュースがあります。まずは悪い方から。

2.5GbEに対応したPoEスプリッターがないか探してみたのですが、見つかりませんでした!

監視カメラなどの用途が多いせいか、1000Mbps止まりなんですよね……

良い方はというと、
なぜか2.5Gbpsでリンクアップする! (゚∀゚)

2.5Gbpsでリンクアップ

2.5Gbpsでリンクアップ

おそらく、イーサネットの接続はヘンなチップなど介さないでスルーなのでしょう。

過度な期待はしないでください。

 

おしまい

 

GMKtec NucBox7 G2のWi-Fi 6対応無線LANデバイス

以前に紹介したGMKtec NucBox7Sは、CPUがIntel N5105なのと、無線LANWi-Fi 5だったのが少し不満でしたが、少し待ったら待望のIntel N100モデルが出てきました。メモリが8GBから12GBに増えて余裕ができ、無線LANWi-Fi 6対応になりました。

前回のがこれ。

hgot07.hatenablog.com

N100搭載になった、NucBox7 G2がこちらです。(SSD 512Gモデルあり)

化粧箱のラベル

化粧箱のラベル

さすがに2.5GbEは無理でしたが、全体的に良い感じにアップグレードされています。

さて、私の関心事はWi-Fi 6対応の無線LANアダプタなのですが、どうでしょうか。

定番のIntel AX201かと思った?残念!RTL8852BEでした!

RTL8852BE

RTL8852BE

いえいえ、むしろこの方が嬉しいです。IntelのカードはLinuxのhostapdで2.4GHz帯しか吹けず、5GHz帯が設定できないのです。RTL8852BEならMeLE Quieter3Cの内蔵チップと同じなので、5GHz帯も大丈夫でしょう。hostapdでは11axの設定ができず、あいかわらずWi-Fi 5止まりですが。

(あちらの製品なので、全ロットがRealtekかどうかは不明です)

 

現場からは以上です!

 

忙しくてまだ試せていないんですよ……

 

おしまい

 

 

 

国内メーカーのWi-Fi 6 & Passpoint対応基地局WHG-DAX1800A

アイ・オー・データ機器Wi-Fi 6無線LAN基地局、WHG-DAX1800Aです。

私の記憶が確かならば……、Passpoint対応国産機第一号は「ポジモ」で、二番手が「アライドテレシスAT-TQm5403」です。国内メーカーから発売された、おそらく初のWi-Fi 6モデルが、このWHG-DAX1800Aです。

www.iodata.jp

海外メーカーから続々とPasspoint対応機が登場するなかで、国内で有名どころの基地局メーカーからは、さっぱり出てきませんでした。執筆時点でもまだ動きのないメーカーが多数ありますが……

OpenRoamingが2020年に登場して、Wi-Fi 6かつPasspoint対応のモデルが必要になってきたところで、国内メーカーは全滅でした!

一方で、海外メーカー製はまだ高価なものが多くて、小規模な店舗などに転がす用の基地局としては導入が難しいものでした。そんな中で、NICT Beyond 5Gの研究成果を生かして、アイ・オー・データ機器さんに作っていただいたのが、このWHG-DAX1800Aというモデルです。(手前味噌)

3万円台で買えて、MikroTikみたいに設定がマニアックな上に販路が難しいようなこともない、画期的な製品です。

 

エンタープライズ向けのWi-Fi 6機なのに安い

WPA2/WPA3 Enterpriseにきちんと対応した基地局で、かつ、Wi-Fi 6に対応したモデルとしては、競争力のある価格帯です。

 

サイズ感

16cm角ぐらいで、可愛い~というほどではありませんが、他のエンタープライズ向けWi-Fi 6機よりは小柄な感じです。

WHG-DAX1800A外観1

WHG-DAX1800A外観1

WHG-DAX1800A外観2

WHG-DAX1800A外観2

 

Passpoint対応

とにかく欲しかったのがこれ、Passpointの機能です。

今でこそEdgecoreもPasspointに対応していますが、当時は台湾メーカーもさっぱりで、中国メーカーは輪をかけてガン無視という感じでした。

おっと、国内メーカー製といっても、ほとんどの基地局メーカーがそうであるように、このモデルも台湾OEMです。SEANOに外観そっくりのモデルがあり、EnGeniusブランドでも出ています。

Passpointの機能や設定画面については、色々と意見を反映していただいて、使いやすいものになっていると思います。特に、

  • バンドごとにPasspointの設定を入れなくても済むこと
  • 一つのPasspoint設定を複数バンドに一括適用できて、バンドステアリングが効くこと
  • パラメータ値はできるだけ内部でデフォルト値を生成して、利用者が入力しなくても済むこと

について、しっかり対応してもらいました。

素のOpenWrtでは、バンドごとにPasspointの設定を入れる必要があります。その感覚のままで設定GUIを作ると、失敗します。HESSIDって何?Operating ClassはIEEEの有償ドキュメントを見ないと分からないよね?……みたいな。

Wi-Fi設定1

Wi-Fi設定1

Wi-Fi設定2

Wi-Fi設定2

Passpoint設定

Passpoint設定

めがっさらくちん!

ただし、Passpointのプロファイルは一組しか設定できないようです (ファームウェア2.0.1で確認)。SSIDごとに別のプロファイルを使うようなことはできません。

 

中身と機能

他の大多数のメーカーと同様に、どうせOpenWrtベースなのだろうと思って、中身を調べようとしたのですが…… SSHが塞がれています_('、3」∠)_
(むしろ開けっぴろげのEdgecoreの方が特殊か)

裏技()を使うとこのとおり。

中のOS

中のOS

CPUは Qualcomm IPQ6018 @ 1.2GHz のようです。

このCPUならVPNも結構速いだろうと思ったのですが、strongswan も openvpn も wireguard も関連のファイルが見当たりません。残念!

製品の仕様として、リモート管理もVPN機能もないので、マネージドWi-Fiとして店に転がす用には単体で使うことができません。使うとしたら、小型・高速なVPN箱を抱かせて、基地局側のUTPケーブルにいたずらされないように物理的に封をして転がすことになると思います。

例えば、WireGuardで350Mbpsぐらい出るGL.iNet GL-MT2500あたりが使いやすそうです。(合体用の箱でも作ります?)

 

おしまい

 

 

 

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

前回 ↓ の続きです。

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ではどうでしょうね?

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

参考文献:

 

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に接続された際に通知音が鳴り、通知アイコンが表示されます。通知の中に、ポータルサイトを開くためのリンクがあります。

Androidの通知動作

Androidの通知動作

その他の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では、全画面表示のポータル画面がミニブラウザで表示されてしまいますが、利用者が特に操作しなくても、端末が通信をブロックすることはありません。

ChromeOS, Android 10における通知

ChromeOS, Android 10における通知

iOS/iPadOS

APIに対応しているバージョンでさえ、通知機能が使いものにならないので、Apple独自の方式で Captive Network Assistant (CNA) が必ず動くように実装します。

通常のCNAの使い方では、利用者が利用規約に同意したり、ログイン操作を行ったりするなど、何らかの操作があるまで端末が通信をブロックします。Venue Info Handlerでは、これを自動解除するロジックを入れてあります。

CNAが全画面表示になるのが鬱陶しいですが、執筆時点でこれ以外の通知手段が思いつきませんでした。

iOS/iPadOSにおける通知

iOS/iPadOSにおける通知

macOS

macOSも通知機能がさっぱりなので、CNAが必ず動くように実装します。

ネットワークに接続されると、CNAの巨大なポップアップが表示されます。

macOSにおける通知

macOSにおける通知

Windows 10/11

Windows 10/11では、Microsoft独自の仕組みが動くように実装します。

ネットワークに接続されると、(サンドボックスもなしに) いきなり規定のブラウザでポータルサイトが表示されます。

端末が通信をブロックすることはないのですが、キャプティブポータルの仕組みがNCSI (Network Connectivity Status Indicator) と組み合わさっているため、接続アイコンの表示が少しヘンになるかもしれません (応答が悪くなる)。

 

まとめ

どうにもこうにも、OSの対応状況がよくありません。

OSベンダ各社や、無線LAN業界には、アクセス制御が目的のキャプティブポータルから離れて、情報通知のみの用途もあることを認識してもらいたいところです。

(一応、WBAを通じて要望を上げているのですが……)

 

おしまい