hgot07 Hotspot Blog

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

公衆無線LANにおけるWi-Fi 6E、WPA3に泣く

2022年9月2日、日本国内でも無線LANの6GHz帯の一部が開放され、Wi-Fi 6Eの利用が解禁になりました。

www.itmedia.co.jp

そわそわしている人がそこそこいると思います。学校・大学などのキャンパス無線LANや、公衆無線LANでも、積極的に導入すべきものでしょうか?

バンド幅以外のWi-Fi 6Eの目玉の一つ(?)は、WPA3必須化でしょう。Wi-Fi 6の5GHz帯でもWPA3は利用できましたが、6GHz帯ではWPA3が"必須"となっています。

ところが、家庭内乱^H LANと違って、大勢が利用する無線LANシステムでは、色々と困ったことが出てきてしまいました。とある国際リナカフェの業界人が話していたことをこっそり披露します。

結論から書くと、「公衆無線LANでは6GHz帯を別扱いするしかなさそう」ということです。

 

要点

WPA2/3 Enterpriseを使う無線LANシステムを想定します。

要点をざっくりと書きだしてみると、こんな感じです。

  • WPA2以前に脆弱性KRACKsが見つかったので、ガチな対策が含まれたWPA3が出てきた。ただし、WPA2の実装にも攻撃を緩和するパッチが出ている。
  • 2.4GHz帯と5GHz帯では、WPA2 Enterpriseが広く長く使われてきた
  • 無線の状況が変化したときにバンド間で自動切換が可能な、バンドステアリングという技術があるIEEE 802.11r (Fast Basic Service Set (BSS) Transition) が有効ならば、切替時に認証処理をスキップして、通信断の時間を短縮できる。
  • Wi-Fi 6Eの6GHz帯では、WPA3が必須で、WPA2は使えない。
  • WPA2とWPA3の切り替えには、比較的長い通信断が伴う
  • WPA2への後方互換性がある(とされる) WPA3 Transition Mode (TM) というものが存在する。
  • 古めのOSや無線LANドライバは、Transition Modeに設定された基地局にうまく接続できないことがある。

ぇ、えー!?

 

どうする?

様々な端末が接続される公衆無線LANシステムでは、まったく接続できないというトラブルを嫌って、バンドステアリングさえオフにすることがあります。

しかし、バンドステアリングは魅力的です。最近の端末なら利用できるので、公衆無線LANでも有効にする流れでしょう

WPA3はまだまだ対応端末が少ないので、2.4GHz帯と5GHz帯で使ってしまうと、ほとんどの人が接続できない公衆無線LANシステムができあがります

 

6GHz帯もバンドステアリングの仲間に入れられるかどうかを考えてみます。通信断の時間を短縮するには、すべてのバンドでWPA3が使えるようにするしかありません。

こんなこともあろうかと WPA3 Transition Modeを……(マテ

残念ながらWPA3 Transition Modeは鬼門で、使用する端末が限定的でない場合、これを使うのは避けた方がよいと言われています

はい、行き詰まりましたね_('、3」∠)_

それで、どうするのが現時点で無難かというと、「バンドステアリングを有効にしつつ、6GHz帯だけSSIDを分ける」しかないということになりそうです。確定した結論ではなくて、業界でもeduroam界隈でも、議論は現在進行形です。

あとは、

  • 全バンドでバンドステアリングやFast Transitionを諦めて、SSIDを共通化する。
  • どうせ5GHz帯同様に大して飛距離がないのだから6GHz帯に夢を見ない😇

といったところでしょうか。

 

Wi-Fi 6Eは要る?

既設のWi-Fi 6の基地局を早急に6Eに更新する必要性は、公衆無線LANの用途では無いと考えられます。そわそわしなくても大丈夫です。

基地局を新規導入するなら、数年後の状況に備えて、Wi-Fi 6Eに投資しておくのもよいでしょう。

SSIDを分けたり、端末を限定してでも、広帯域が欲しい」という用途なら、突っ込んでみたらよいのでは?(無責任)

 

おしまい

Edgecore Networks EAP101のPasspoint機能を試す

台湾の会社 Edgecore Networks から、Wi-Fi 6対応の基地局として EAP101, EAP102、またコントローラとして EWS101 が出ています。この会社は、Telecom Infra ProjectOpenWiFi に積極的に取り組んでおり、基地局が Passpoint (Hotspot 2.0) に対応しているとの話だったので、気になっていました。国内ではALAXALA、APRESIA、BeMapなどから販売されています。

2022年頭に国内業者に様子を聞いてみたところ、Wi-Fi 6 と Passpoint に対応していますとの返事だったので、早速検証機を借りたのですが、届いてみてびっくり。Passpoint周りの設定項目がない!本社の製品紹介のサイトを見ると Hotspot 2.0 対応と高らかにうたわれています。まさかおま国仕様かと思ったのですが、どうやら世界的にもまだ非対応だったもよう。

あぁ、またか……_('、3」∠)_ 中国や台湾のメーカーはこういうことがよくあります。別メーカーでも踏みました。きちんと現物確認してからでないと怖くて買えません。

もうすぐ対応版ファームウェアが出るから……、3月には出る見込み、6月頃……とどんどんずれ込んできて、執筆時点 (2022/8/21) でも、実はまだ公式には非対応なんです。ところが、3月頭に出た v11.5.0 あたりから Hotspot 2.0 対応のプログラムが入り始めて、コマンドラインからゴソゴソすると、動くじゃぁありませんか!

v12から公式対応との噂がありますが、一足先に色々と試してみました。

 

外観

Edgecore EAP101

Edgecore EAP101背面

ん-、結構大き目ですね。PoEでもDC 12Vでも駆動できます。

Wi-Fi 6はどこの製品も熱い感じ(ダブルミーニング)で、ちょっとごついヒートシンクが付いています。

 

Edgecore EAP101 LED部分

5Gと書かれるとドキッとします。セルラーじゃないんだよ!

 

Edgecore EAP101, EWS101

手前がコントローラのEWS101です。こちらはちっちゃい。

 

管理画面の様子

ブラウザからコンソールにログインしてみると……、あれ、今一瞬 LuCI と見えたような?

EAP101 グラフィカルコンソール

気のせいじゃなく、まんま、OpenWrt の LuCI ですね。

 

Wi-Fi設定は分離型

Wi-Fi の設定は2.4GHz帯と5GHz帯の二系統に分かれていて、個別にSSIDなどの設定が必要です。この辺、OpenWrtの流儀なのかもしれませんが、RADIO以外の設定が一括でできるMerakiのようなスタイルの方が扱いやすいと思います。バンドステアリングも自然に見えるので、個別設定をしなくても済むように、改良して欲しいところです。

 

実を言うと中身はOpenWrt

OpenWiFiというのがどういうものか、まださっぱり調べられていませんが、前のキャプチャ画像にある通り、現行のファームウェアは OpenWrt ベースでした。

ちなみに、最新のファームウェアはここ ↓ (国内ベンダから入手しない場合は動作保証外なのでご注意を)

執筆時点の最新版は v11.6.4-1333 でした。

なんと、EAP101もEAP102も、sshのポートが開いていて、CLIでもアクセスできるんです!他のOEM各社では軒並み、sshのアクセスが塞がれています。CLIが開放されているのは、基地局のオープン化やホワイトボックス化の流れで、とても嬉しい。

早速sshでアクセスしてみると……、

EAP101 CLIコンソール

\ ばばーん /

もう全然隠そうともせずに、arm_cortex-a7のOpenWrtですね(笑)

opkgも使えるかと思って試してみたのですが、パッケージ管理周りは使えないようです。うーん、WireGuard VPNが使いたかったのに……。

 

Passpointを有効にしてみる

まずは、Passpoint対応のドライバ類が入っているかどうかを調べます。

以前の備忘録()を引っ張り出します。

hgot07.hatenablog.com

コマンドラインで、

  # strings /usr/sbin/wpad | grep hs20

を実行してみると……、

wpadがHotspot 2.0対応かどうか調べる

ぞろぞろと hs20 関係のシンボルが表示されました。これならいけそう!

先に、Wi-Fi周りの設定をGUIで済ませておくと楽です。WPA2 Enterpriseのモードにして、RADIUSサーバも接続しておきます。

CLIの方で、/etc/config/wireless をエディタで開いて、該当するセクションを探します。例えば、config wifi-iface 'radio0_1' みたいなものです。そのセクションに、hs20とinterworking関係のオプションを追加していきます。

        option iw_enabled '1'
        option iw_interworking '1'
        option iw_access_network_type '3'
        option iw_internet '1'
        option iw_disable_dgaf '1'
        option iw_asra '0'
        option iw_esr '0'
        option iw_uesa '0'
        option iw_osen '0'
        option iw_venue_group '2'
        option iw_venue_type '8'
        option iw_hessid '00:00:00:02:02:02'
        list iw_roaming_consortium 'xxyyzz0000'
        list iw_nai_realm '0,example.com,13[5:6],21[2:4][5:7]'
        list iw_nai_realm '0,example.org,13[5:6],21[2:4][5:7]'
        list iw_venue_name 'P"eng:testSite"'
        list iw_venue_url '1:http://www.example.com/info-eng'
        option iw_network_auth_type '00'
        option iw_ipaddr_type_availability '0c'
        list iw_domain_name 'example.com'
        option hs20 '1'
        option hs20_oper_friendly_name 'eng:testSite'
        option hs20_operating_class '5179'

Passpoint の仕様書を見ないと、何が何やら分からないですね、これ。がんばって!ww

パラメータ名と、それぞれに何を詰めるかは、hostapd.confのテンプレートが参考になります。

Operating Classは、IEEE 802.11 の仕様書を見る必要があります。ただ、どれが正解なのか分からなかったので、適当にエイやと値を詰めています。

要注意なのが iw_venue_url で、オプションだから不要だろうと思って省略すると、iw_enabled '1' にした途端に、そのSSIDのビーコンが消えます。これを見つけるまで、かなりの日数を費やしました_(゚。3」∠)_

さて、きちんとPasspointが使えるでしょうか?

Hotspot 2.0が有効になった表示例

ヽ(゚∀゚)ノ ちゃんとPasspointが使えるようになりました。正式対応版が楽しみです。

 

めでたし めでたし

 

ps

リモート管理をするマネージドWi-Fiの用途でVPNが必要なので、WireGuardやOpenVPNはぜひ欲しいところです。というか、opkgを使えるようにして欲しい。

あと、EAP101でもそれなりの価格なので、小規模な店舗やSOHO向けに、4万円を切るぐらいの廉価モデルがあればいいのになぁと。 (GL.iNet GL-AXT1800なら、無線部分は弱いでしょうが、WireGuardも付いて1.6万円程度なのだし)

Windowsで使うXMLデータに署名する (xmlsec1編)

Windows用のプログラムを開発していると、XMLデータに署名が必要ということがまれによくあります。ウェブサイトからWi-Fi設定を流し込むプロビジョニングでも、設定用のXMLデータに署名が必要で、まぁなんとも面倒くさいことです。たかがWi-Fi設定にコード署名用のEV証明書(*1)が必要だとか、いったい何を考えて設計したのやら……。

さて、Wi-Fiプロビジョニング用のウェブサイトを作るにあたって、この署名が一つの難関になり、ネット上の情報が乏しいので結構苦戦しました。備忘録を残しておきます。

*1 今のところ……(意味深)

 

XML署名ツール

署名付きXML (SignedXML) を生成するためのツールは色々とあるようです。

  1. WindowsのConvertTo-SignedXml (Windows 8.1 SDKなどに入っている)
  2. xmlsec1などのフリーのコマンド
  3. 有償ツール
  4. 自作品 (!)

今回、オープンソース化が前提で無償でLinuxサーバ上に実装したかったので、ConvertTo-SignedXmlや有償ツールは選外となります。頑張れば自作もできますが、正しく署名できるか検証する必要があるので、まずは既存のツールを探します。

xmlsec1 という署名ツールがありました! (・∀・)

ただし、Linuxのインストール時に自動的に入るようなメジャーなツールではないので、追加のパッケージを探すことになります。開発元はこちら ↓

www.aleksey.com

このxmlsec1、ちょっとクセがあって、使うのがちょっと面倒です。今回、代わりになるものが見つけられなかったのですが、他に良いものがあれば知りたいです。

 

XMLデータに署名してみる

Windowsms-settings: URI スキームで、ウェブサイトから Wi-Fi 設定を行うためには、XMLデータに署名が必要です。この署名の手続きを示します。

元のXMLデータの中身は、こんな感じです。

<?xml version="1.0"?>
<CarrierProvisioning xmlns="http://www.microsoft.com/networking/CarrierControl/v1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Global>
    <CarrierId>{df909a2c-511f-c769-b424-11333792de13}</CarrierId>
    <SubscriberId>1234567890</SubscriberId>
  </Global>
  <WLANProfiles>
    <WLANProfile xmlns="http://www.microsoft.com/networking/CarrierControl/WLAN/v1">
      <name>Example IdP</name>
      <SSIDConfig>
        <SSID>
          <name>GreatAP</name>
        </SSID>
      </SSIDConfig>
      <MSM>
        <security>
          <authEncryption>
            <authentication>WPA2</authentication>
            <encryption>AES</encryption>
            <useOneX>true</useOneX>
          </authEncryption>
          <OneX xmlns="http://www.microsoft.com/networking/OneX/v1">
            <authMode>user</authMode>
            <EAPConfig>
              <EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
                <EapMethod>
                  <Type xmlns="http://www.microsoft.com/provisioning/EapCommon">21</Type>
                  <VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
                  <VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
                  <AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">311</AuthorId>
                </EapMethod>
                <Config>
                  <EapTtls xmlns="http://www.microsoft.com/provisioning/EapTtlsConnectionPropertiesV1">
                    <ServerValidation>
                      <ServerNames>idp.example.jp</ServerNames>
                      <TrustedRootCAHash>ca bd 2a 79 a1 07 6a 31 f2 1d 25 36 35 cb 03 9d 43 29 a5 e8</TrustedRootCAHash>
                      <DisablePrompt>false</DisablePrompt>
                    </ServerValidation>
                    <Phase2Authentication>
                      <MSCHAPAuthentication/>
                    </Phase2Authentication>
                    <Phase1Identity>
                      <IdentityPrivacy>true</IdentityPrivacy>
                      <AnonymousIdentity>anonymous@example.jp</AnonymousIdentity>
                    </Phase1Identity>
                  </EapTtls>
                </Config>
              </EapHostConfig>
            </EAPConfig>
          </OneX>
          <EapHostUserCredentials xmlns="http://www.microsoft.com/provisioning/EapHostUserCredentials" xmlns:baseEap="http://www.microsoft.com/provisioning/BaseEapMethodUserCredentials" xmlns:eapCommon="http://www.microsoft.com/provisioning/EapCommon">
            <EapMethod>
              <eapCommon:Type>21</eapCommon:Type>
              <eapCommon:AuthorId>311</eapCommon:AuthorId>
            </EapMethod>
            <Credentials>
              <EapTtls xmlns="http://www.microsoft.com/provisioning/EapTtlsUserPropertiesV1">
                <Username>user001@example.jp</Username>
                <Password>piyopiyo123</Password>
              </EapTtls>
            </Credentials>
          </EapHostUserCredentials>
        </security>
      </MSM>
    </WLANProfile>
  </WLANProfiles>
</CarrierProvisioning>

この内容が、wifi.xml という名前のファイルに格納されていると想定します。何やらだらだらと長いですが、肝心なのは最後の二行だけなので安心しましょう。1行目のXML宣言を除いた部分が署名の対象になります。

「これを xmlsec1 に読み込ませて署名すればよいだけでは?」
ざんねん!下準備が必要です。

末尾にある </CarrierProvisioning> というタグの前に、以下のようにテンプレートを挿入します。

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue></DigestValue></Reference></SignedInfo><SignatureValue></SignatureValue><KeyInfo><X509Data><X509Certificate></X509Certificate></X509Data></KeyInfo></Signature></CarrierProvisioning>

<Signature>...</Signature> の部分が署名です。Signatureブロックの内側は、無理に一行にまとめないで、改行を入れても大丈夫です。元データの最後のタグが、改行無しに書かれていることに注意します。もしここに改行があると、元データに余計な一行が入ったデータに対して署名が生成されることになります。(今回はどちらでもよいのですが、署名の範囲を注意するという意味で)

 

署名用の鍵と証明書、必要に応じてCA証明書を束ねた、PKCS #12形式のファイルを用意します。以下の例では、パスワードを空にしています。

  $ cat cert.pem ca.pem | openssl pkcs12 -export \
     -inkey privkey.pem -password "pass:" -out signercert.pfx

いざ、署名!

  $ xmlsec1 --sign -pkcs12 signercert.pfx --pwd "" wifi.xml > signed-wifi.xml

 

出来上がった署名付きXMLデータを覗いてみると、Signatureブロックの中で、DigestValueやSignatureValueに値が入っていることが分かります。また、末尾にはPKCS #12形式ファイルに埋め込んだ証明書のデータがBase64エンコードされて埋め込まれています。パブリックCAを使うなら、Root CA証明書は不要のはずです。

 

おしまい

 

1X認証でPAPを使ってはいけない

???「知ってる。パスワードが平文で送られるからでしょ?」

現場猫「でもサーバ認証があれば大丈夫っしょ、へーきへーき」

 

それでは、現場をご覧ください。

RADIUSサーバが平文パスワードを受け取っている様子

\ User-Password = "piyopiyo" /

頭ではわかっていても、実際に目の当たりにすると迫力が違います。

この時の端末側の設定は、以下のとおりです。

端末側でPAPを設定している例

 

まずはサーバ認証

無線LAN802.1X認証で用いられる EAP (Extensible Authentication Protocol) のうち、EAP-TTLSやPEAPでは、端末と認証サーバ (RADIUSサーバ) の間で互いを認証してTLS接続を確立する Phase 1 と、IDとパスワードを用いたユーザ認証を実施する Phase 2 の二段階の認証があります。

IDとパスワードのやりとりはTLSトンネルで保護された通信路で行われるので、一旦TLS接続が確立すれば、第三者に盗聴される危険性は無くなります (暗号強度のレベルで)。しかし、ここで接続しようとしている基地局と、その裏にある認証サーバは、正規のものでしょうか?端末からサーバを認証するのが、よく「サーバ認証」と呼ばれている処理です。

EAP-TTLSは、サーバ認証を行うことが前提の認証方式です。ところが、端末によっては、サーバ認証を実施しない設定も可能です。手動設定の場合は特にそうですが、なんと、Wi-Fiプロファイルをネットから流し込むようなプロビジョニングでさえ、サーバ認証が有効にならないケースがあります。見つけたところには注意喚起していますが、たぶんあちこちあるでしょう。

というわけで、サーバ認証が無効な場合、偽の認証サーバによってパスワードが窃取される危険性があります。サーバ認証が確実ではないことも想定しておく方が安全です。

 

Phase 2認証の方式

Phase 2認証には、PAP (Password Authentication Protocol) や MSCHAPv2 (Microsoft Challenge-Handshake Authentication Protocol Version 2) などが指定できます。PEAPでは原則としてMSCHAPv2を使います。

それでは、なぜ、パスワードをサーバに平文で伝えるなどという、PAP なんていう代物が生き残っているのでしょうか。EAP-TTLSと言えばPAPというぐらい、どういうわけかメジャーな選択肢になっていました🤔

一昔前の EAP-TTLS の実装で MSCHAP や MSCHAPv2 がまともに動かなかったことが、大きな要因の一つと考えられます。10年ほど前、MSCHAPv2の壊れた実装が市場に流通していて、大変困ったことがあります。

RADIUSサーバの裏にあるデータベースに、MSCHAPv2で使える形式 (NTLM) のパスワードが格納されておらず、平文もないという状況で、どうしても802.1X認証が使いたいという事例もあります。

冒頭のキャプチャ画像にあるとおり、PAPでは端末がRADIUSのUser-Password属性に平文パスワードを詰めてサーバに送ってしまうので、サーバからパスワードが丸見えになります。MSCHAPv2では、端末が保持しているパスワードと、サーバが保持しているパスワードがそのまま相手に送られることはなく、チャレンジ - レスポンスという形でやり取りが進みます。厳密にはMSCHAPv2にも脆弱性が知られているのですが、何もないPAPより、解読の時間稼ぎにはなるでしょう。

 

PAPの悪用例

サーバ側で平文のパスワードが容易に取得できるとなれば、パスワードを窃取する以外にも、様々な攻撃が可能になります。

例えば、端末から送られてきたUser-Passwordの値をそのまま使って、802.1Xの認証を不正に成功させる (Access-Acceptを返す) ことができます(*1)。すると、攻撃者は、自分のLANに端末を接続させて、MITM (中間者) 攻撃や、端末への直接の攻撃が可能となります。

2022年の Wireless Global Congress における FBI の話によれば、暗号化の実装が進んだお陰で難易度が高くなった「盗聴」よりも、基地局や端末などのデバイスの「脆弱性を突く」ことの方が、現実的な攻撃手段とのことです。つまり、攻撃者のLANに端末が接続させられることは高リスク😱 と言えるでしょう。

 

*1 FreeRADIUSの場合、設定ファイルに数行追記するだけで実装可能。

 

対策

とにかく、サーバ認証を確実に行うことが第一です

その上で、サーバ認証が行われない場合に備えて、PAPを使わないようにすることでしょう。

 

EAP-TLS使えよ!」
ごもっともなのですが、それは運用の手間とのバランスの話になるかと思います。(きちんとrevokeまで作り込んでいますか?)

 

おしまい

 

Wi-Fi 6対応VPNトラベルルータGL-AXT1800でPasspointを動かしてみる (成功)

今、GL-AXT1800 (Slate AX)が熱い! (物理)

Wi-Fi 6対応機なので仕方ないのでしょうが、ちょっと発熱が多いです。

2022年頭にGL.iNetから発表された、Wi-Fi 6対応のVPNトラベルルータ GL-AXT1800 (Slate AX)、半導体不足の影響もあってか、なかなか日本で買えるようになりませんでした。首を長くすること6,000ミリか月、やっとAmazonで買えるようになりました。

 

似た型番の GL-AX1800 は立派なツノが生えた据え置き型だったので、せっかく同社から Wi-Fi 6 に対応した製品が出たといっても、ちょっと手が出せませんでした。小さいは正義!さっそく新型の GL-AXT1800 を注文してみました。

(Slateの愛称を持つ GL-AR750S-Ext と比べたら、随分大きくなってしまいましたが……)

このモデル、なんと最初から OpenWrt 21.02 が入ってきます。ということは、19.07ベースだったこれまでの機種と違って、純正ファームウェアのままでPasspoint の基地局として使えそうな予感です。(速攻で買ってもし動かなくても知りませんorz)

GL-AXT1800 (Slate AX)

GL-AXT1800 (Slate AX)

では、早速…… ヾ(⌒(ノ'ω')ノ

 

ギャラリー

Berylと同様に、ゴロンとでかいACアダプタが付いてきます。携帯できなくもないですが、ポケットルータにはちょっと厳しい感じ。本体は意外とずっしり重いです。
※ 以前のBerylの紹介時には、やや不安定な感じがありましたが、現在は大丈夫なはず。

てっきり、Berylと同じ型かと思ったら、一回りちょっと大きかったです。

端子の位置も違う。

裏面がBerylよりもスカスカで、中にファンらしきものが見えます。無線LANを使っていない状態では、まだ回っていません。

GL.iNet純正の管理画面。きびきび動いて好印象です。

ただ、純正の方はあまり細かい設定ができないので、OpenWrtのLuCIを使ってみます。特にパッケージを追加する必要はなく、すぐに使える状態でした。

おぉ、ちゃんと OpenWrt 21.02 ベースです! (超重要)

wpad-basicが入っていたら、フル機能版のwpad-opensslに入れ替えます。入れ替えたつもりだったのですが、パッケージマネージャの動きが少し怪しくて、古い方がAvailableに表示されません。うーん?

とりあえず、sshでログインして、
  # strings /usr/sbin/wpad | grep hs20
で何やらぞくぞく ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ•̫͡•ʔ•̫͡•ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ 出てきたので、Passpointも大丈夫でしょう。

 

WireGuardを試してみる

そっちが先かよ!?

仕様書は製品紹介ページで。

www.gl-inet.com

や、WireGuardに550Mbpsって書かれているけど、盛り過ぎじゃないですか?

というわけで、早速試してみます。設定は以前の記事と同様ですが、今回は純正ファームウェアのままで行きます。

hgot07.hatenablog.com

あれ、WireGuardのパッケージが二種類ある!? kmod-wireguard-backportの方が標準で入っていたのですが、もしかしたら、21.02でWireGuardの速度が19.07の半分になっていた問題の対策かも。このまま -backport を使ってみます。

 

まずは、GL.iNet版の設定画面を(怖いもの見たさで)見てみます。

 

あぁ、やっぱり_('、3」∠)_

どうやらお仕着せのVPNサービスを使う前提で作られているようです。手作業で高度な仕込みもできるのかと思いきや、何を入力したらよいか分からない画面が出てきます。ひどい……

WireGuardの設定が済んで、リンクアップも正常、ピア間のpingも返る。よーし、次、Speedtest!と思いきや、トラフィックがWireGuard側ではなくLANから出て行ってしまいます🤔  (知ってた)

何やら、特殊なルーティング設定が入っているみたいです。まずは、以前Mangoに仕込んで正常だったもの ↓

純正ファームウェアではこのとおり ↓

コマンドラインから 2001: from all fwmark 0x100/0x3f00 lookup 1 のルールを削除したところ、defaultがWireGuardのトンネルを向くようになりました。

このルールがどこで設定されているのか探ってみましたが、よく分からなかったので宿題。ただ、このままではリブートするたびに手動で直す羽目になって、マネージドWi-Fiとしては失格なので、なんとかします。しました。

mwan3がこのルールを設定していたので、どうせ使わないので、このパッケージを削除(笑)。これで、リブートしてもすべての通信がWireGuard側を通るようになりました。

 

気になる速度はというと、ぎゃぼ!

ほぼカタログスペックの値が出ています。素晴らしい!(・∀・)

研究室内のGbEで、相手は向いの部屋にあるLinux箱(Core i5-4590 @ 3.3GHz)です。CPUが古いせいか、load averageは0.3~0.4ぐらい。GatewayRyzenにしたい……

 

Passpointを動かしてみる

それでは、本題のPasspointの検証を。

設定は以前の記事の通りです。設定内容をブログに残していた自分、えらいぞ。

hgot07.hatenablog.com

ほいきた!

ヽ(・∀・)ノ

Passpoint (Hotspot 2.0) が正常に動いています。接続はどうでしょうか?

接続も無事に成功!

というわけで、Passpointが吹けて、WireGuardでリモート管理と回線保護ができる、安価な Wi-Fi 6 対応基地局が手に入りました。Wi-Fi 6の性能や、多数端末接続時の性能、バンドステアリング、安定性など、無線LAN部分の評価も必要ですが、今回はこの辺で。

 

おしまい

 

 

twitterでマウスホバーによるポップアップが出なくなって困った件 (解決済み)

ウェブ版のtwitterには、利用者のアイコンの上にポインターを持っていくと、その利用者のプロフィールがポップアップする機能があります。ある日、突然これが効かなくなりました

この機能が搭載された頃は、邪魔だと散々の不評だったようです。誰だろうと思った時にわざわざその人のページに行かなくても済む (嫌なものだったらできるだけ見ないで済む) ので、自分は便利に使っていました。ところが、システムに特に何か変更を加えたわけでもないのに、自宅のノートPCだけ、ポップアップが出なくなってしまいました。Firefox Syncで同期している他のPCはどれも正常です。プラグインFirefoxの不具合も疑ってみたのですが、どれもハズレ。Firefoxを一旦アンインストールしてみてもだめ。

似たような症状で困っている人がいないかと検索しようにも、検索語が「ポップアップ」では別の機能の話ばかり出てきます。さぁ、困った……_('、3」∠)_

 

散々探し回って、もう英語しかないと、手当たり次第に検索してみます。あぁ、この機能は hover と呼ばれているのですね。知らないと正解(?)に辿り着けないやつでした。

それで、さらに色々と単語の組み合わせを変えて検索していたところ、タッチスクリーンが付いている機種ではtwitterのマウスホバーが停止されるという情報に行きつきました。ぇ、ウェブサイトでそういうところまで余計なことをしないといけないの……

いや、まて。このノートPCにはタッチパネルなんて付いていないぞ?

 

さらにぐるぐる検索を続けていたら、こんな記事を発見。

www.reddit.com

んー、タイトルはビンゴっぽい。何々?about:configに入って、ui.primaryPointerCapabilities を作って6を入れろと?

またまたー、どうせ他に原因があって簡単には治らないんでしょう?🤔

 

ありゃ、直ったわ (゚∀゚)

 

なんか、ぐっしょり汗をかいたように疲れた。その割に、ワークアラウンドだけで、根本的な解決策は不明。複雑なウェブサイトきらい。

 

おしまい

無線LANの認証もパスワードレスになる

タイトルの通りです

あと、認証はします。(重要)
認証のない無線LANなんて、利用者にとっても、事業者にとっても、危なすぎるので。

 

従来の無線LAN

公衆無線LANでも、学校などのキャンパス無線LANでも、利用者認証のあるシステムではIDとパスワードを使う方式が広く使われてきました。フリーWi-Fiでも、数日立つとメールアドレスの入力を促されるなど、はげしくちょっと面倒くさいです。

学術系の無線LANローミング基盤 eduroam のように、WPA2 Enterprise (IEEE 802.1Xベース、通称1X認証) で自動接続ができるシステムでも、最初のWi-Fi接続設定の段階でIDとパスワード (とその他もろもろ) を打ち込まないといけないことが多いです。

毎年、新学期になると、「eduroamにつなげない」という声がちらほら出てきます。IDやパスワードの打ち間違いもよく観測されていて、「ずっとlと1を間違えていたわ」みたいなことがあります。

1X認証のうち、EAP-TTLSやPEAPといった方式では、サーバ認証の設定が本来必要です。この辺の七面倒くさい設定を楽にしてくれる設定ツールとして、eduroam CAT や geteduroam がありますが、これらも学校から発行されたIDとパスワードを打ち込まなくてはなりません。

いや、これ、面倒でしょう!  (間違えやすいし)

みなさん、機関から発行されたIDとパスワードでログインする方式に、慣らされすぎていません?

 

パスワードレスな無線LAN

ID/パスワードを打ち込まなくても利用者認証される無線LAN、実は身の回りにも少しあります。

最近のキャリアWi-Fiは、SIMカードを使うEAP-AKA認証などが用いられていて、スマホSIMカードを挿すだけで利用できたりします。キャリアごとのプロファイルのインストールが必要な場合もありますが、パスワードとかどこにも出てきません。

「最近の」ということは、昔はどうだったのかというと、ID/パスワードの設定が必要な時期がありました。現在でも、スマホではなくPCを接続しようとすると、ID/パスワードの入力が必要になったりします。

大学によっては、EAP-TLS認証を採用していて、クライアント証明書を端末にダウンロードしてWi-Fi設定を行うこともあります。電子証明書を手入力なんて、無理ですからね。

これから普及が期待されるPasspointやOpenRoamingでは、端末の設定項目が多いために、ID/パスワードの手入力は無理です。そこで、既に接続されている回線を利用して、Passpointプロファイルをダウンロードして、Wi-Fi設定を行うことになります。どんな感じかというと、例えば以下のOnline Sign-Up (OSU)システムで体験できます。

osu.odyssys.net

ボタンをいくつかクリックするだけでWi-Fi設定が完了します。ただし、上記のサービスは利用者の紐付けがないので、匿名利用ということになっています。

これで利用者認証と言えるの?
はい、実はダウンロードしたプロファイルにはEAP-TTLSの設定が含まれていて、ID/パスワードが埋め込まれています。興味のある人は、プロファイルをデコードしてみてください。

カフェなどにあるQRコードでも、ID/パスワード入力なしでつながるのでは?🤔
あー、あれはセキュリティ上、最悪の方から二番目ぐらいです。
WPA2 Enterpriseではなくて、共通鍵を利用するWPA2 Personalが使われています。つまり、利用者認証がない上に、偽基地局問題があります。

 

パスワードレスの無線LANの時代へ

無線LANの利用者認証でも、ID/パスワードの入力を無くせないでしょうか?

ウェブ方面では、最近、パスワードレスが盛んに叫ばれるようになってきました。FIDO2とか、普及にはまだ時間がかかりそうですが。

学校のユースケースを見てみましょうか。まず、利用者は自分の無線LAN用ID/パスワードを知るために、学校の情報システムにログインします……って、あれ?もうログインしていますね。それなら、なんでID/パスワードをコピペしないといけないのでしょうか。

既にログイン済みのシステムがあるなら、電子的手段でWi-Fiプロファイルを端末に仕込めばよいではないですか。

同じことが、SNSのように他の認証システムでログインしてから利用者登録するタイプの公衆無線LANにも言えます。

あっさり解決できそうですね。

ということは、ID/パスワード方式のメリットはないのでは?🤔

現在、利用者が何らかのネット接続手段を持っているというのが一般的になっているので、無線LANに最初に接続するとき (onboardingと呼ばれる) にネットが使えない場面はだいぶ少なくなっているでしょう。しかしながら、外国に行ったら携帯電話網がすぐ使えるとは限らないので、現地で紙ベースでID/パスワードを発行してもらうことがあるでしょう。観光地や会議場の無線LANも同様です。

しかし、セキュリティ強化の観点からWPA2 EnterpriseやPasspointが導入されてきているので、ID/パスワードの手入力の運用は、やはり限界があります。他にネットのない状況で、オープンな無線LANシステムを利用して Online Sign-Up (OSU) を実現する方式が、Wi-Fi AllianceやWireless Broadband Allianceなどをはじめ、業界で検討されています。

個人的には、現地で電子的手段で安全に提示できるアイデンティティがないなら、オンラインでの利用者登録というアプローチには懐疑的です。ただし、人手により利用者の紐付けを行った上で認証コード付きのヴァウチャーを発行する仕組みならば、よい落としどころになりそうな気がします。

 

長ったらしいID/パスワードを利用者に入力させるのは止めましょう!

無線LANもパスワードレスを目指しましょう!

 

スマホは認証デバイスになるし、ウェブサイトのシングルサインオンも利用できそうです。つまり、どこかで認証が既に通っているなら、無線LANのアカウント発行から端末の設定まで、自動化すればよさそうですね。

というわけで、Wi-Fiプロファイルを端末に流し込む仕組みを、自分でも試してみました。ちょっと、というか現状ではかなり(?)面倒くさいのですが、前述のGlobalReachもやっているし、がんばれば可能です😂

Passpointプロファイルのプロビジョニングの例

Passpointプロファイルのプロビジョニングの例

 

余談

そうは言っても、やっぱりID/パスワードが見たいんじゃー!という人もいると思います。自分もそうです。サポート端末以外でも利用できるように、特に大学では、ID/パスワードと設定情報を提供すべきだと考えます。EAP-TLSの場合は、証明書のダウンロード機能も。

 

おしまい