hgot07 Hotspot Blog

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

Edgecore EAP111のWireGuard VPN機能を試す

サクサクと行きます。

以前書いたEAP105の記事とほぼ同じことを試しているだけです。設定も同じです。

 

hgot07.hatenablog.com

Edgecore EAP111について

Edgecoreから出ているWi-Fi 6アクセスポイントです。

EAP105のWi-Fi 7みたいな目玉はなく、IP55防塵防水規格をうたっていることと、廉価なことぐらいで、機能・性能的にはあまりパッとしません。しかし、あまりコストをかけずに数をばら撒きたい用途には良さそうです。

あと、実はこれがOpenRoamingのような公衆無線LAN用途では重要で、WireGuard VPNによって有線部分の保護ができます。専用コントローラではなく、Linux箱でも受けられます。(執筆時点でまだスタンドアロン環境でしか使えませんが)

 

見た目は特に味気ないはんぺんですね。

EAP111外観

EAP111外観

EAP111外観 (裏)

EAP111外観 (裏)

技術情報がネットにあまり見つからないので、実際に買ってみるまで、ちょっと不安なところがありました。特に、どのクラスのチップセットが使われているのかが、気になります。

sshでログインしてlogを覗いてみたところ、プロセッサは MediaTek MT7981 のようです。GL.iNet Beryl AX (GL-MT3000)と同じなので、WireGuardで 300Mbps は出そうな予感。段々と高まってきました。

 

設定

EAP105と同じなのでサクッと省略。

 

WireGuardの速度

こちらもサクッと、結果だけです。

iperf3の結果

iperf3の結果

あぁ、予想より少し良い感じです (・∀・)

350Mbpsはあるでしょう。

 

課題

執筆時点でまだecCLOUDからVPNの設定ができないので、大規模実装にすぐ採用できないところがつらいです。Edgecoreさん頑張って!

あと、このモデルは TIP OpenWiFi 版もあります (購入時に選択)。外付けアンテナのモデルもあります。冴えないように見えて、実力者な予感がします。

しばらく様子を見ながら、育ててみたいと思います。

 

おしまい

 

Linuxのwpa_supplicantでOpenRoaming/Passpointに接続する

2年前に、OpenWrt箱をOpenRoamingに接続する方法を書きました。Linuxではwpa_supplicantを使って接続するのですが、そういえば、その設定を記事にしていなかったなと。メモを、未来の自分へ……

 

hgot07.hatenablog.com

アカウントの取得

OpenRoamingのアカウントは、事業者でなければ発行できません。匿名利用者の悪用を防ぐ、ローミングシステムのセキュリティのためです。

上の記事などを参考にして、お好きなプロバイダからアカウントを取得してください。現在、認証方式としてEAP-TTLSやEAP-TLSが主流ですが、この記事ではEAP-TTLSを想定します。

 

Linuxのwpa_supplicant

Linuxは、ディストリビューションによってネットワーク設定が異なるところが、イケてません。メジャーなディストリビューションでも説明をカバーするのが困難なので、ここではwpa_supplicant の設定だけを示します。

執筆時点の wpa_supplicant の最新版は 2.11 です。

LinuxをWPA2 Enterpriseのネットワークに接続する方法については、ネットにいくつか記事があります。設定の基本は、wpa_supplicant.conf に

network = {
  ...
}

のようなブロックを書くことです。

OpenRoaming / Passpointの場合は、この network ブロックの代わりに、cred ブロックを使います。network ブロックは不要なので消去して、以下のように書きます。もちろん <...> の部分は各自のものに置き換えます。

country=JP
interworking=1
hs20=1
auto_interworking=1

cred={
        roaming_consortiums="5A03BA0000"
        ca_cert="/etc/ssl/ca-bundle.pem"
        domain_suffix_match="<ドメイン名>"
        username="<ユーザ名>"
        password="<パスワード>"
        phase2="auth=MSCHAPV2"
        eap=TTLS
}

roaming_consortiums は、Roaming Consortium Organization Identifier をカンマ区切りで並べたものです。例にある 5A03BA0000 は、OpenRoamingのsettlement-free (要するにFree Wi-Fi)の Baseline の値です。

ca_cert は、サーバ認証に使うルートCA証明書を指定するものです。ここでは、システムに付属する証明書ストアを指定しています。openSUSE Leapの例なので、他のディストリビューションではパスが違っているかもしれません。

domain_suffix_match は、サーバ証明書のドメイン名 (CN/SAN)を指定するものです。プロバイダから取得した値を設定します。

WPA2 Enterprise (WPA3も同様) では、サーバ認証を省略してはいけません。サーバ認証がないと、偽基地局に誘導されてID/パスワードを奪われたりする恐れがあります

usernamepassword には、プロバイダから取得したユーザ名とパスワードを設定します。ユーザ名にはレルム (@以降)が付いている必要があります。PasspointではないWPA2 Enterpriseでは、username ではなく identity というパラメータ名でした。

wpa_supplicant 2.11以前のcred ブロックには、anonymous_identity のようなパラメータはありません。EAP-TTLS の outer-identity は常に anonymous@レルム の形でRADIUSサーバに渡されます。つまり、任意の outer-identity を設定できない制約があります。新しい版で改良されるようです。

wpa_supplicant.conf の詳しい書き方は、こちらで ↓

 

Passpoint対応の無線LANアダプタ

2026年時点で、Wi-Fi 5 Wave 2以降の新しい無線LANアダプタの多くが、Passpointに対応しています。ただし、Linuxで使えるチップセットは限られているので、頑張って探すしかありません。

Linuxで認識できるアダプタを使うと、wlan3 のようなデバイスが見えるはずです。以下のようにしてOpenRoaming / Passpointに接続します。

# wpa_supplicant -i wlan3 -c wpa_supplicant.conf

少し待つとこのとおり ↓

接続成功例

接続成功例

この段階で、無線LANの接続は完了していますが、まだアドレスが付いていません。DHCPでアドレスを取得する方法としてdhclient が紹介されているサイトが多いのですが、openSUSEではうまく動きませんでした。代わりにdhcpcdを使います。

# dhcpcd wlan3

接続を自動化する方法はディストリビューションごとに違うので、省略します。

 

おしまい

 

TP-Link Archer TX10UB NanoをLinuxで使う

TP-Link Archer TX10UB Nano、これです。

TP-Linkお得意の、出っ張りが少ないWi-Fi USBドングルです。中身は Realtek RTL8851bu でした。

まだまだ 11ac 世代のドングルが多く出回っているのですが、11ax は色々と効率化されているので、これからの実験には新しい方を使いたいというわけで、こちらを選んでみました。

ところで、例によって製品名が長すぎて、覚えるのが大変ですよ、TP-Linkさん orz 

 

結論 (いきなり):
ちょっとどころではない、ハマりどころがありました。

 

Linuxで使えるかな?

例によって wpa_supplicant で子機として、hostapd で基地局として動くかどうかが問題です。

私はメジャーなUbuntuよりも管理が楽と考えるopenSUSE Leapを主に使っているので、これで動くかどうかも心配です。Ubuntuでは動くけど他ではダメというドライバが、結構あるので。

さて、openSUSE Leap 15.6 のPCに挿してみたところ、ストレージデバイスと誤認識されて、動きませんでした。

GitHubにそれっぽいドライバがあったので、試してみました。残念ながら、make でも dkms でも途中でエラーが出てしまいました。ちなみに、これ ↓ です。

新しいカーネルならもしかして……と、期待を込めて openSUSE 16.0 のPCに挿してみたのですが、こちらもストレージデバイスとして認識されます。なんで……

デバイス番号が違っているのかと思って、色々と調べてみたのですが、よく分かりません。GitHub Copilotくんにエラーメッセージを食わせてみました。

lsusb shows "Bus 005 Device 002: ID 0bda:1a2b Realtek Semiconductor Corp. RTL8188GU 802.11n WLAN Adapter (Driver CDROM Mode)" but this isn't a device like that. It's a Wi-Fi 6 dongle. How can I fix it?

(答え)

The (Driver CDROM Mode) message means your USB Wi-Fi dongle is presenting itself as a CD-ROM (mass storage) device instead of a network adapter. This is a common technique manufacturers use to ship Windows drivers on the dongle itself. On Linux, you need to switch the device out of CD-ROM mode and into Wi-Fi mode, then load the correct driver.

おっと、予想外の原因が!

Leap 16.0では dkms install . がエラーなく成功して、usb_modeswitch -KW -v 0bda -p 1a2b したところ、無事にphyが生えてきました。iw phy で確認できます。

 

こんなんわかるかー・・・・・(ノ`Д´)ノ彡┻━┻

 

[2026/3/24修正] なお、Tumbleweed (20260318) ではカーネルが 6.19.8 と新しく、追加のドライバは不要で、カーネルに付いてきた rtw89_8851bu が使えました。

 

STA(子機)モードの確認

wpa_supplicant.conf を書いて、wpa_supplicant を起動してみたところ、あっさりと動きました。WPA2 Enterprise に Passpoint の設定まで入れて大丈夫だったので、OpenRoaming でも使えますねこの子。

WPA2 Enterprise + Passpointで接続成功

WPA2 Enterprise + Passpointで接続成功

APモードの確認

サクサクと hostapd.conf を書いて、基地局として動かしてみました。

例によって、Passpoint / OpenRoaming の設定まで入れてみます (笑)

こちらもあっさり動作して、めでたし、めでたし!

 

なお、2.4 GHz帯は問題なく動くのですが、5 GHz帯はW52のチャンネルしか動作しません。国内において、W53とW56ではDFSが必須なのですが、このオプションが動きません。

ちょろっと調べてみた限りにおいて、RealtekのチップでDFSは働かないようです。残念。まぁ、本格運用の基地局を作るなら、ちゃんとPCIeのモジュールを使うべきでしょう。

 

おしまい

GL.iNetのWi-Fi 7対応機GL-BE9300 (Flint 3)でPasspointを使う

Passpointの設定例は別記事にしたので、手っ取り早く設定投入したい人はそちらをどうぞ。

hgot07.hatenablog.com

例によって、Passpointの検証機として買いました。こんなデカいものを買うつもりはなかったのですが、VPN機能と組み合わせてマネージドWi-Fiの基地局として使えるものを開発したいので、やむを得ず(苦笑)

 

トライバンドWi-Fi 7対応機

GL.iNet GL-BE9300 (Flint 3)は、6 GHz帯にも対応している、トライバンドのWi-Fi 7対応機です

同社から出ている小型の GL-BE3600 (Slate 7)もWi-Fi 7対応機ですが、こちらは6 GHz帯のないデュアルバンドです。そう、Wi-Fi 7だからといって6 GHzに対応しているわけではないのです。

とりあえず、ばばーん!

GL.iNet GL-BE9300 (Flint 3)

GL.iNet GL-BE9300 (Flint 3)

Flint 3化粧箱

Flint 3化粧箱

Flint 3 リアビュー

Flint 3 リアビュー

デカい……ですね。

4本のアンテナは本体に固定されており、いちいち取り付けたりする手間もなく、いい感じに立てるだけで設置完了です。

 

 

QS⚡DK

sshでログインしてみると、ファームウェアはQualcomm SDKベースで、プロセッサとして Qualcomm Immersive Home 3210 の IPQ5332 が使われていることが分かります。

Qualcomm SDK

Qualcomm SDK

Qualcomm IPQ5332

Qualcomm IPQ5332

姉妹機(?)の GL-BE3600 (Slate 7) は、携帯できる (できなくもない)小型のルータです。構成はよく似ていて、IPQ5312 が使われているようです。

OpenWrt謹製のファームウェアはまだ出ていないようで、若干の方言のあるQualcomm SDKに、ちょっと不安を感じてしまいます。特にPasspointでは。

 

wpadもhostapdも見当たらない

ちゃんと /usr/sbin/hostapd は存在して、設定も hostapd と同じなので、一安心。ただし、opkg で見ると、wpadやhostapdの見慣れたパッケージが見当たりません。

MediaTekのチップを採用したルータでは、wpad/hostapdと互換性のないfirmwareが入っていることがあり、Beryl AXが出た当時はPasspointが動かなくて泣きました。Qualcomm SDKはOpenWrtより若干古いものの、MediaTekと比べると若干の安心感があります。Qualcommには、早めにOpenWrtにコミットしてねとだけ、声を大にして言いたい

 

Passpointの設定

例によって、WPA2/WPA3 Enterpriseの設定までは既にできているものと仮定します。

あとは、別記事のとおりにPasspointの設定を /etc/config/wireless に追加するだけです。

問題発生!

実は、当初、Passpointがうまく動かなくて困りました。こんな感じ ↓ で、Passpoint対応のネットワークだと識別できても、プロファイルのFriendly Nameが表示されません。

設定失敗例

設定失敗例

調べてみると、hostapdに渡すべきパラメータが /tmp/run/hostapd-wlan0.conf に書き込まれていないことが判明しました。さらに調査を進めると、以前のQualcomm SDKや、OpenWrt 24.10 と違って、interworking関係のパラメータの名前が変更されていました。以前は "iw_" が頭についていたものが、新しい Qualcomm SDK では削られています。例えば、iw_internet というパラメータは、internet として /etc/config/wireless に書かなければなりません。

hostapd の設定をするためのスクリプトを探してみると、/lib/wifi/hostapd.sh がそれでした。あー、なるほど、色々と変更されていますね…… (こまるよ、こういうの)

新しい記法に習って /etc/config/wireless を書き直したところ、やっとこさ、Friendly Nameが表示されました。

Friendly Nameの表示

Friendly Nameの表示

 

「このネットワークに接続できません」の呪い

Friendly Nameがうまく表示されたものの、いざ接続しようとすると、「このネットワークに接続できません」の表示が _(゚。3」∠)_ 

Microsoftさんは、いつになったら、このコミュ障なエラー表示を直してくれるんですかね?トラブルシューティングのきっかけが掴めません##

これも色々と試行錯誤したところ、複数の原因がありました。

一つは、Windows 11が何らかの情報をキャッシュしていて、以前に接続失敗したものを延々と引きずるという問題です。リブートしてみたら2.4 GHz帯はつながりました。

これで一気に解決したかと思いきや、5 GHz帯がつながりません……

結局、hs20_operating_class の値が影響していたようです。(へー、このパラメータ、ちゃんと使われているんだ……)

W52のチャンネルが使われているのに、W56用の値が設定されていました。きちんとバンドに合わせて Operating Class を設定する必要がありました。詳しくは別記事の方に書いてあります。

 

バンドステアリングとか、MLOとか、色々と試さないといけないのですが、手が回っていません。

 

おしまい

 

番外Q&A

これを使うと、OpenRoamingに対応した基地局が個人でも作れるの?

きちんとWBAやベンダに登録した人なら、技術的には可能です。ただし、基本的には、通信事業者でない個人にやってほしくはありません。OpenRoamingの認証連携ネットワークが個人に開放されると、通信を傍受できて、OpenRoaming全体のセキュリティに影響が出るからです。

 

 

 

 

Passpoint setting for GL.iNet Flint 3 and Slate 7

To enable Passpoint on GL.iNet Flint 3 and Slate 7, using the factory default firmware which is based on Qualcomm SDK, do the following:

    1. Upgrade the firmware to the latest version (4.8.4 for GL-BE9300 Flint 3, 4.8.3 for GL-BE3600 Slate 7, as of this writing).
    2. Setup each Wi-Fi interface with "wpa3-mixed+ccmp" (WPA2 Enterprise with optional PMF) or "wpa3+ccmp" (WPA3 Enterprise). Using LuCI is recommended for the configuration.
    3. Login the device using ssh.
    4. Edit /etc/config/wireless and add interworking configuration like the following to each "config wifi-iface" section. 
    5. Restart wireless networks by typing "wifi".

Example options for Passpoint

Parameter values need adjustment depending on your system and environment. <...> is a place holder.

        option hs20 '1'
        option access_network_type '3'
        option internet '1'
        option disable_dgaf '1'
        option asra '0'
        option esr '0'
        option uesa '0'
        option osen '0'
        option venue_group '2'
        option venue_type '8'
        option hessid '<one of the MAC addresses of the wireless device>'
        list roaming_consortium '<Roaming Consortium OI in 5 or 3 octets>'
        list venue_name 'eng:exampleLab'
        list venue_url '1:https://example.com/'
        option network_auth_type '00'
        option ipaddr_type_availability '0c'
        list domain_name 'example.com'
        option hs20_oper_friendly_name 'eng:exampleLabNet'
        option hs20_operating_class '5179'

Note: Recent Qualcomm SDK omits the leading "iw_" in the parameter names, while OpenWrt uses the names like "iw_internet", "iw_venue_name", etc.

Please see Table E-4 in IEEE Std 802.11-2020 for the Operating Class. For example, 0x51 (=81) means 1-13ch in 2.4 GHz band, and 0x79 (=121) means 100-144 ch in 5 GHz band. The 5 GHz codes for Japan are:

  • 0x73 = 115 : W52 (36-48ch)
  • 0x76 = 118: W53 (52-64ch)
  • 0x79 = 121 : W56 (100-144ch)

Please refer to /etc/wifi/hostapd.sh for the parameter details.

 

Voilà! :-)

Connected to OpenRoaming/Passpoint network

Connected to OpenRoaming/Passpoint network

 

 

 

strongSwanでWindows/Android/iOS/macOS全対応のroad warrior向けIKEv2サーバを建てる

タイトルだけ見て、「うわー、面倒なやつだ!」と思った人は、おそらく実際に設定しようと試みた人だと思います。

「面倒くさそう」と思った人は、いじったことがなさそう。

「面倒なとこある?」と思った人は、いじったことがないか、それなりの手練れと思われます。

もう少し詳しく、やりたいことを書くと、このようになります。

  1. L2TP/IPsecじゃなくてIKEv2にする
  2. レガシーな ipsec.conf ではなく、モダンな swanctl.conf で設定する。
  3. Windows, Android, iOS, macOSのすべてで使える
  4. 利用者の負担とトラブルを最小限にするため、ID・パスワード方式の認証として、端末にルートCA証明書やクライアント証明書を新たにインストールするのを避ける。
  5. 端末側は、VPN設定だけで完結して、他のパラメータをいじらなくても、大抵のウェブサイトにアクセスできるようにする。

いかがでしょうか?☺️

そんなに面倒なことがあるものかと思った人、検索して、実際にVPNサーバを建ててみてください。

この記事で紹介している設定例は、以下の環境でテストしました。

  • strongSwan 5.9.12, openSUSE Leap 15.6
  • strongSwan 5.9.13, Ubuntu Server 24.04.3 LTS

 

何が問題か

L2TP/IPsecはもうだめです

road warrior向けということで、全トラフィックをVPNサーバ経由で送受信できるように設定します。

長年L2TP/IPsecが使われていましたが、最近は排除されつつあります。AppleがiOSからL2TP/IPsecを外し、Androidも外したので、もはやroad warriorの用途ではIKEv2が主流になるはずです。

例えば、京都大学では、様々なVPN方式を調べた上でIKEv2の採用に至っています。

  • 針木 剛, ''京都大学におけるIKEv2 サービスの構築,'' AXIES 2016. [PDF]

拠点間ルータとして売られている製品でも、road warrior向けの設定はできることが多いのですが、なぜかIKEv2の仕様があまりイケていないことがよくあります。

というわけで、IKEv2でVPNサーバを構築したいのですが、ウェブにはまだあまり情報がありません。さらに、strongSwanの設定が ipsec.conf を使う古いインタフェース (stroke) から swanctl.conf を使う新しいもの (vici) に移行しており、IKEv2と組み合わせるとグッと減ります。

拠点間VPNの設定とroad warrior用VPNの設定が、検索でごっちゃになってくるのも、なかなか面倒です。

どうする? 🫠

 

IKEv2サーバの設定の方が楽

L2TP/IPsecでは、設定項目が多くて大変でした。strongSwanとxl2tpdを組み合わせたりとか。

IKEv2になるとさらに面倒なのかと及び腰になりますが、実はIKEv2の方が設定が簡単です! もう二度とL2TP/IPsecを触りたくないぐらい。

 

主要なモバイルOSをサポートしたい

なぜか分かりませんが、拠点間ルータ製品のIKEv2 VPN機能では、Android, iOSだけ対応みたいな仕様が目につきます。少なくとも Windows, Android, iOS, macOS には対応しておかないと、使いにくいでしょう。私はWindowsのノートPCを使って出先から作業したいのに……

 

利用者の負担とトラブルを最小限にする

大勢のエンドユーザを対象としたサービスを想定する場合、いかに利用者の負担や、接続トラブルを減らすかが、課題となります。

セキュリティ上は、サーバ認証のためのルートCA証明書をプライベートにして運用したいところですが、証明書を端末に仕込む手間が面倒なので、本記事の設定例ではパブリックCAの証明書を使うことにします。具体的には Let's Encrypt の証明書を使います。

同様に、クライアント証明書の扱いも面倒なので、ID・パスワード方式にします。

もし証明書を使うなら、エンドユーザに手作業を強いるのではなく、VPNプロファイルなどを使った自動設定にすべきでしょう。

 

VPNの鬼門、MTU問題

頑張ってIKEv2の接続までたどり着いたのに、アクセスできないウェブサイトが続出するなどで、投げ出してしまった人は少なくないと思われます。例えば、Twitterは見えるのに、Facebookは見えないといった具合です。

原因はほぼMTUのミスマッチでしょう。

大学のネットワークでは大丈夫なのに、自宅や公衆無線LANではおかしい、といった状況もよくあります。逸般の誤家庭でもない限り、家のインターネット回線ではMTUが1460 byteや1340 byteといった小さ目の値になっているので、これが問題になりがちです。

参考:

support.ntt.com

公衆無線LANでも、MTUが小さいことがよくあります。

 

いざIKEv2サーバを建てる

strongSwanの設定

レガシーな ipsec.conf ではなく、モダンな swanctl.conf を使う設定です。

/etc/swanctl/swanctl.conf に以下のように書きます。ID・パスワードを別ファイルに書いて include することもできます。ファイルのパーミッションに注意しましょう

connections {
    ikev2-eap {
        local_addrs = <VPNサーバのIPアドレス>
        remote_addrs = 0.0.0.0/0

        local {
            auth = pubkey
            certs = cert.pem
            id = <サーバ証明書のドメイン名>
        }
        remote {
            auth = eap-mschapv2
            eap_id = %any
        }
        children {
            net {
                local_ts = 0.0.0.0/0
            }
        }

        version = 2
        send_cert = always
        proposals = aes256-sha256-modp2048,aes128-sha256-modp2048,aes256-sha256-modp1024
        dpd_delay = 30s
        dpd_timeout = 120s
        rekey_time = 0
        fragmentation = yes
        mobike = yes
        pools = ipv4-pool
    }
}

 

pools {
    ipv4-pool {
        addrs = 172.16.250.0/24    # 端末に割り当てるIPアドレス
        dns = 8.8.8.8                      # 端末に設定するDNSサーバのIPアドレス
    }
}

 

secrets {
    eap-user1 {    # ユーザID・パスワード(平文)を列挙
        id = user1
        secret = user1password
    }
}

 

 

/etc/swanctl の下に、証明書と鍵のファイルを置きます。

  • /etc/swanctl/x509/cert.pem  ← Let's Encryptの証明書 cert.pem
  • /etc/swanctl/x509ca/chain.pem ← Let's Encryptの中間証明書チェーン chain.pem
  • /etc/swanctl/x509ca/chainX.pem ← Let's Encryptの中間証明書チェーン chain.pem を個々の証明書にばらしたもの、すべて (Xは番号など)。
  • /etc/swanctl/private/privkey.pem  ← Let's Encryptの証明書に対する鍵 privkey.pem

Let's Encryptの証明書は頻繁に更新されるので、シンボリックリンクにしておくのが楽でしょう。

 

[2026/6/5追記] Let's Encryptは、2026/5/13にGeneration Yという新しいツリーを導入しました。これに伴い、以前は chain.pem に一つだけ中間CA証明書が入っていたところが、二個入るようになりました。さて、なんと strongswan は複数証明書の入ったPEMファイルを扱えないという残念仕様でした。というわけで、ばらしたものを x509ca/ の下に置く必要があります。自動でばらすならこんな感じ ↓

awk '
/-----BEGIN CERTIFICATE-----/ {n++}
{ print > ("cert" n ".pem") }
' chain.pem

 

ただし、Ubuntuでは、privkey.pem をシンボリックリンクにすると Permission denied, skipped になります。AppArmorの設定をいじるか、元のファイルをコピーするかで対処する必要があります。

OS依存なので説明を省略しますが、ファイアウォールのポート 500/udp と 4500/udp を開けておきましょう。

え、これだけ?🤔 -- はい、ほぼこれだけです!☺️

 

strongSwanの起動は service strongswan start でできますが、その前に次節にあるMTU関係の設定も済ませておきましょう。

なお、strtongswan-startup という似たような名前のスタートアップスクリプトは、ipsec.conf を使うレガシー環境のためのものです。間違えないように。

 

MTU関係の設定

ウェブの多くの記事によれば、MTU問題のワークアラウンドとして net.ipv4.ip_no_pmtu_disc=1 が挙げられています。これだけでは残念ながら解決できません。通常、PMTUD (Path MTU Discovery) は有効なままにしておくべきでしょう。

他にもっとよい方法があるかもしれませんが、手元の環境では以下の設定でよく動いています。

まず、/etc/strongswan.d/charon/kernel-netlink.conf の中にMTUを設定するパラメータがあるので、mtu = 1300 のように書きます。

[2026/3/9修正] 初稿では mtu = 1340 と書いていましたが、とある携帯電話網で調子が悪いことが判ったので、少し下げました。

これで多くのサイトにアクセスできるようになりますが、まだ閲覧できないサイトがあります。

追加で、MSS Clampingの設定を入れます。iptablesの環境なら以下のとおり。

# iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -s 172.16.250.0/24 -j TCPMSS --clamp-mss-to-pmtu

openSUSE Leapでこの設定を永続化するには、/etc/firewalld/direct.xml に下のように書いておきます。

<?xml version="1.0" encoding="utf-8"?>
<direct>
  <rule ipv="ipv4" table="mangle" chain="FORWARD" priority="10">
    -p tcp --tcp-flags SYN,RST SYN -s 172.16.250.0/24 -j TCPMSS --clamp-mss-to-pmtu
  </rule>
</direct>

[2026/2/27追記] firewalld でリロードしても nft list ruleset でルールが見えない場合、おそらく iptables-nft コマンドが入っていません。iptables パッケージが要ります。

[2026/2/27追記] 他のサーバと同じ設定にしたつもりなのに、Windows 11はつながるけどAndroid 13がダメという事象にしばらく悩みました。Let's Encryptから発行された証明書がECCになっていて、ルートCA証明書までのパスは合っているはずなのに、なぜか検証に失敗していました。RSAの証明書に切り替えたら正常に。

 

Ubuntu Serverでこの設定を永続化するには、/etc/ufw/before.rules の先頭にこのように書けばよいみたいです (普段Ubuntu使っていないので自信なし)。

*mangle
-F
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -s 172.16.250.0/24 -j TCPMSS --clamp-mss-to-pmtu
COMMIT

 

IP forwardingとIP masqueradeの設定、Let's Encryptの証明書の取得・更新

これらは、他に沢山ある、優れた記事を参照してください。

 

端末の設定

設定項目が少ないのでAndroidの例だけ示します。

AndroidのIKEv2 VPN設定

AndroidのIKEv2 VPN設定

接続の名前は、自分で覚えやすいものを適当に付ければよいです。

サーバーアドレスは、IPアドレスではなく、FQDNで設定します。Windowsではこれに相当する入力欄が証明書の検証にも使われます。

AndroidではIPSec IDという項目がありますが、証明書のドメイン名を指定します。CA証明書は、ここではLet's Encryptを使っているので、ISRG Root X1のものを指定します。

[2026/2/27追記] 端末にプリインストールされた証明書群を指定できればよいのですが、Android 12には選択肢がなかったので、やむを得ずルートCA証明書をインストールする必要がありました。

 

ちなみに、swanctl.conf の中に send_cert = always がないと、iOSはサーバ認証に失敗するようです。

これより簡単に設定したいなら、プロファイルを配るしかないでしょうね。

 

あと、同じID・パスワードを設定した複数の端末は同時に接続できないという制約があります。同時接続したい端末には、別々のIDを設定する必要があります。

 

動作確認

色々なウェブサイトが閲覧できるかどうか試してみましょう。

speedguide.net のTCP Analyzerを使うと、MTU/MSSの値を確認できます。
(注:Windows 11で接続しても10と表示されます)

IKEv2接続時のMTU/MSS

IKEv2接続時のMTU/MSS

MTUが小さくなっていることが分かります。

続いて、別のVPNトンネルを通したIKEv2接続を試してみると、このとおり。

他のVPNを通したIKEv2接続時のMTU/MSS

他のVPNを通したIKEv2接続時のMTU/MSS

MTUがさらに小さく絞られていることが分かります。

 

誰が接続しているのかを調べる

[2026/3/30追記]

現在誰が接続中なのかを調べるには、swanctl --list-sas を実行すればよいです。張られている SA (Security Association)の詳細が表示されます。

 

MOBIKEがおもしろい

IKEv2には MOBIKE (Mobility and Multihoming Protocol) というオプションがあります。IKEv2で接続した状態で、端末上流のセルラー回線やWi-Fiを切り替えて、IPアドレスが変化しても、VPN接続が維持されます。実際に見てみると驚くでしょう。

 

strongSwanのトラブルシューティング

一にも二にも、ログを見ることです。strongswanで検索しても引っかからないことがあるので、ipsec や charon でも検索しましょう。

例示した swanctl.conf では、proposalsを最小限しか書いていません。一応、比較的新しいAndroid, iOS, Windowsでは動作確認しましたが、OS側のアップグレードによってミスマッチが起こるかもしれません。暗号アルゴリズム、ハッシュ、DHグループのミスマッチもログに出るので、必要なものを追加すればよいでしょう。

 

おわりに

IKEv2がうまく動くようになることを願っています。一つでもまともに動く環境ができたら、証明書認証などへの対応も、進めやすくなるでしょう。

もしこの記事が役に立った場合、ここでは投げ銭とかできないので、他の記事にあるアフィリエイトリンクの一つでも踏んでもらえると嬉しいです。

 

おしまい

位置情報タグの拾われやすさを比べてみた (Find Hub対応とTile)

海外旅行で怖いのが、鞄など身の回りのものの盗難や、スーツケースのロストです。

国内でも、自動車やバイクの盗難が怖いです。

万一に備えて、位置情報タグを装備したくなるわけですが、数あるタグの中でいったいどれが他人に電波を拾ってもらいやすいのだろうかという疑問が沸きます。そう、タグにはGPS機能がないし、自主的に通知する機能もないので、他人のスマホで検出してもらわない限り見つからないのです。

結論から述べると、今回試した3機種は、ほぼ同等の飛距離でした。というか、明らかに悪い4個目があり、難癖つけられたくないので、あえて隠しました 🫠

 

Find Hub対応タグ

独自規格だと、利用者が少なくて、拾ってもらえる確率が下がります。後述するTileがその例です。長年Tileを使っていましたが、2025年にはGoogle Find Hubに対応した製品が沢山出てきたので、比べてみようと思いました。

私はApple製品を常用するユーザではないので、AirTagは選択肢に入りません。

写真の3機種を自宅に置いたり、車に積んでおいたり、スーツケースに入れてホテルに置き去りにしたりと、同じ場所において、誰かが電波を拾ってくれたかどうかを、遠隔から眺めてみました。

比較した3機種

比較した3機種

実際に飛距離を測ることは難しいので、通りがかった人に拾われるのを待ちます。Find Hubで表示される検出時刻を見ると、現在時刻に近いものが拾われやすいだろうと考えます。

しっかり記録をつけていたわけではありませんが、数か月眺めていた結果、ほぼ互角という状況でした。若干、HiKOKIのものが掴みやすいようでしたが、たまにEufyに負けることがあり、誤差の範囲かと思います。

ただし、Bluetoothの制限か、距離はあまり飛びません。Tileの長距離版 (90mとか150m)と比べると心許ないです。窓際に置いておけば、4階程度でも通りから拾ってもらえますが、部屋の内側におくと全然だめです。

それぞれの説明は以下のとおり。

メジャーどころなので、あっさりと。

電池交換可能ですが、カバーを開くための穴が小さくて、SIMピンかゼムクリップが必須です。

Eufyの専用アプリもあって、機能は豊富なのですが、あまり安定していません。置き忘れ防止機能(β)を使う方法が分かりません。というか、これ、動いていないのでは?

Find Hubで見ると、リビジョンの違いのせいか、バッテリ残量が表示されない個体と表示されるものがありました。

小柄だし、Find Hub対応機種としては距離も出ている方なので、無難な選択肢でしょう。

しかし、この長ったらしい名前はなんとかならないのか…… (覚えられない顔)

 

 

HiKOKI トラッカープロ

なんか強そうなのが出てきたので、もしかして距離が出るかと思って、試しに買ってみました。値段はちょっとお高めです。

 

木ネジで取り付けられそうな穴があるのですが、ねじ止めすると電池交換のたびに外すことになります。電池交換のためには4点のビスを外す必要があり、当然、ドライバーが必要になります。タッピングビスなので、舐めそうで怖いです。裏側には両面テープが貼られています。

トラッカープロ 裏面

トラッカープロ 裏面

開けてみるとこんな感じです。分厚いCR2450電池は長持ちしますが、店頭での入手性はあまり良くないです。

トラッカープロ 開封図

トラッカープロ 開封図

ごつい見た目とは裏腹(?)に、飛距離はそれほど伸びません。ただし、大きさと価格を気にしないならば、僅差の性能でEufyに勝つと思います。

 

Dyoac エアタグ

これ、商品名は何というのですかね……

米国製チップとか、強そうな印象はありますが、まぁそこはそれ。

 

カード型はどうなのだろうと思って、洒落で買ってみただけです。飛距離はあまり期待していなかったのですが、Eufyと同等かと思います。

冒険したい人はどうぞw

 

Tileとの比較

老舗のTileです。長年使っていて、アプリはよくできていると思います。

しかし、専用アプリがないと拾ってもらえないこと、利用者が少ないことなどが泣き所です。海外にも何度か持ち出していて、場所によっては国内よりも電波を拾われる確率が高いとはいえ、五十歩百歩でしょう。

海外の空港では、拾われる確率が高めでしたが、羽田空港ではFind Hub対応タグもTileも、全く反応しません。自分のスマホに反応したと思った瞬間に、手荷物受取のカルーセルの上に出てきます。空港の各所にセンサーがあればよいのにと思いました。

Tileの強みは、150mの長距離版があるところでしょう。場所依存はあいかわらずですが、Find Hub対応タグが反応しない状況でTile Proが拾われているという場合がちらほらあります。拾われる条件の傾向が結構違う印象です。

とはいえ、国内では、長距離版でさえ、何時間もピクリとも反応しないことがあります。ヨーロッパの方が普及しているのでしょうか?傾向が違うことに賭けて、保険として両者を付けておくのがよいと思われます

Find Hubのタグは本当に距離が出ません。パリ北駅近くのホテルの4階では、近くの部屋の人が拾っていたようですが、通りから拾われるのはTile Proの方でした。

 

 

盗難対策には、どちらもイマイチだなと思いましたが、ないよりはずっとマシといったところでしょうか。

 

番外

Find Hub対応で、AirTagと同じサイズをうたうキーチェーン付きの機種も試しに買ってみました。Eufyと同じ鞄に入れて国内外で長期間試してみたのですが、電波が拾われる確率が明らかに低かったです。車に積んだ状態も試しましたが、駐車場で拾われることはほとんどありませんでした。部屋の中なら、確実に反応します。

機種により意外に性能差があるようなので、選んだ方がよいです、マジで。

 

おしまい