hgot07 Hotspot Blog

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

【注意喚起】FreeRADIUSの設定は気を付けないとEAP-TLSに大穴が開く (EAP-TLSを使っていなくても)

タイトルの通りなんですが、その昔これを見つけた時はヘンな汗が噴き出ましたよ。

eapol_testを使ったEAP-TLS認証

eapol_testを使ったEAP-TLS認証

SUCCESS... (;゚∀゚)

 

自分はEAP-TLSを使わないからといっても、デフォルトで穴が開くので要注意です。

 

不具合の内容

以下の条件がすべて満たされているとき、同一CAが発行・署名したクライアント証明書を用いて、第三者によるEAP-TLS認証が成功します。無線LANに不正に接続できたりします。

  1. FreeRADIUSでPEAP, EAP-TTLSなどを使っている。
  2. Public CAから発行されたサーバ証明書を使っている (Let's EncryptでもUPKIでも、何でもよい)
  3. EAP-TLSを運用していないのに、その機能が無効になっていない (FreeRADIUSのデフォルト)。
  4. FreeRADIUSの設定ファイル mods-enabled/eap の中で、EAP-TLSを設定する
     tls { } セクションに tls = tls-common が指定されている  (デフォルト) 。
  5. クライアント証明書の属性値を検証する機能が無効になっている  (デフォルト)。

企業内で使うセキュリティがガッチリ管理された無線LANシステムでもなければ、今は端末にプリインストールされているCA証明書ストアを使うのが一般的でしょうから、結構アウトですよね。

 

検証方法 (悪用禁止)

サーバ証明書と同じパブリックCAから、クライアント証明書 (cert.pem) とその鍵 (privkey.pem) を入手しておきます。中間CA証明書をクライアント証明書の末尾にcatして、cert+.pem を作っておきます。

次のような eapol_test.conf を作成します。

network={
  ssid="piyopiyo"
  key_mgmt=WPA-EAP
  eap=TLS
  anonymous_identity="anonymous@example.com"
  client_cert="cert+.pem"
  private_key="privkey.pem"
  private_key_passwd="<鍵のパスフレーズ>"
}

レルムは自分の環境に合わせます。

privkey.pem に鍵が付いていないなら、private_key_passwd="" とします。

 

いざ!

$ eapol_test -c eapol_test.conf -s testing123

eapol_test コマンドは、wpa_supplicant パッケージなどに入っています。

SUCCESS が出たら負けです。

 

なぜこうなるのか

FreeRADIUSの設定ファイル mods-enabled/eap の中に、tls-config tls-common { } セクションがあります。証明書類をここに設定しますが、サーバ認証ばかりではなく、EAP-TLSのクライアント認証にも、同じ設定が使われるのがデフォルトです。少し下の方に EAP-TLS の設定のための tls { } セクションがあり、そこに tls = tls-common と書かれています!

一応、tls-config tls-common { } の直前に、以下のような注意書きがあります。ちゃんと読んでいますよね?

        #  Note that you should NOT use a globally known CA here!
        #  e.g. using a Verisign cert as a "known CA" means that
        #  ANYONE who has a certificate signed by them can
        #  authenticate via EAP-TLS!  This is likely not what you want.

ところで、最近のOSでは、安易にCA証明書をインストールさせない方針になっているようです。ネットで拾ってきたCA証明書を一般利用者がインストールするなんて、リスキーですからね。

というわけで、WPA2 Enterpriseを使う無線LANシステムでは、システムにプリインストールされているCA証明書ストアを使ってサーバ認証させるのが一般的になっています。上の注意書きは、この点で時代遅れで、不親切です

一方で、EAP-TLSのクライアント認証は、クライアント証明書からルートCAにたどり着けるかという certification path validation が基本になっています。パブリックCAを使うと、第三者もログインできてしまいます。

一つの対策は、クライアント証明書の中身を検証するロジックを tls { } セクションの中で有効にすることです。でも、そもそも EAP-TLS を使う気のない管理者なら、こんなところまで見ないかもしれません。また、検証といっても、実際に何を検証すれば安全なのかという問題が残ります (証明書の意味が無くない?)。

 

有効な対策

そもそも、EAP-TLS を使わないなら、tls { } セクション全体をコメントアウトすればOKです。

EAP-TLS を使うなら、クライアント認証にはプライベートCAを使うでしょう。tls-common とは別に、例えば tls-auth を別途定義すればよいでしょう。

 

おしまい

 

ps

eduroam JPでは結構前に注意喚起の文書を出したので、きちんと対策されてい……るといいなぁ。

素の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あたりが使いやすそうです。(合体用の箱でも作ります?)

 

おしまい