先日、v6プラス/MAP-Eの静的設定が原因で、IPv4通信が不能となる事象に遭遇しました。
手動でMAP-E設定を更新することで復旧はできましたが、またIPv6プレフィックスが変わった場合に同じ作業を繰り返すのは避けたいところです。
今回は、OpenWrtで利用できる国内IPoEヘルパーであるluci-app-flethを導入し、v6プラス/MAP-E設定の自動構成を目指します。
1. luci-app-flethのインストール
国内IPoE向けのOpenWrt用スクリプトやヘルパーはいくつかありますが、今回はLuCI画面から状態を確認でき、v6プラス/MAP-E設定を扱いやすそうなluci-app-flethを使うことにしました。
上記、GitHubのlatestページから、2026/6/6時点の最新バージョン0.20 luci-app-fleth-0.20-r1.apkをダウンロードしました。
私が利用しているOpenWrtのバージョンは25.12.4です。OpenWrt 25.12系ではパッケージ管理がapkに移行しているため、ipkではなくapk版を使用しました。OpenWrtコンソールで直接wgetコマンドでダウンロードしました。
root@OpenWrt: mkdir /tmp/flethcheck
root@OpenWrt: cd /tmp/flethcheck
root@OpenWrt: wget -O luci-app-fleth-0.20-r1.apk \
"https://github.com/makeding/luci-app-fleth/releases/download/v0.20/luci-app-fleth-0.20-r1.apk"
Downloading 'https://github.com/makeding/luci-app-fleth/releases/download/v0.20/luci-app-
fleth-0.20-r1.apk'
Connecting to 20.27.177.113:443
Redirected to /github-production-release-asset/842514937/9ba28001-be24-4
#
# （途中省略）
#
on release-assets.githubusercontent.com
Writing to 'luci-app-fleth-0.20-r1.apk'
luci-app-fleth-0.20- 100% |*******************************| 36097 0:00:00 ETA
Download completed (36097 bytes) ダウンロードしたapkファイルをインストールします。
OpenWrt 25.12以降ではパッケージ管理がapkに移行しています。配布元の説明によると、現時点ではapkパッケージに署名がまだ無いため、インストール時には–allow-untrustedオプションが必要とのことです。
root@OpenWrt:/tmp/flethcheck# apk add --allow-untrusted ./luci-app-fleth-0.20-r1.apk
(1/3) Installing resolveip (2)
Executing resolveip-2.post-install
(2/3) Installing ds-lite (9)
Executing ds-lite-9.post-install
(3/3) Installing luci-app-fleth (0.20-r1)
Executing luci-app-fleth-0.20-r1.post-install
OK: 70.1 MiB in 336 packages2. luci-app-flethの設定
インストール後、Webコンソールから設定を確認します。
メニューの[Network]から[Flet’h Configuration]をクリックします。
[luci-app-fleth]の[Flet’h Configuration]メニューが表示されます。
現在のv6プラス/MAP-E情報、基本設定、補助ツールがGUIから見えるようになっています。
[Area]は[EAST]、[IPv6 Prefix Length]は[/56 => PD]、[MAP-E Provider]は[JPNE（v6プラス）]として自動認識しています。IP Address（IPv4アドレス）も自動設定されている状況です。
続けて[General Settings]メニューをクリックします。
初期状態では [Auto Configure tunnel Interface] のチェックボックスはオフの状態でした。このチェックボックスをオンにします。
次に[Tunnel Interface]を修正します。初期状態では[wan]が設定されています。現行MAP-Eインターフェースは[wanmape]として定義しています。既存のMAP-Eインターフェース名である[wanmape]を、そのままluci-app-flethの管理対象となるように設定しました。
新規に構成する場合や、過去の手動設定が複雑化している場合は、既存設定を整理したうえで、luci-app-fleth用のインターフェースとして設定するほうが分かりやすいと思います。
Prefer SLAAC Addressは、SLAACで作られるIPv6アドレスを優先して使わせるための補助設定です。
今回は、私の環境ではPrefer SLAAC Addressをオフにしても、wan6のIPv6アドレスからv6プラス/MAP-E情報を正しく認識でき、wanmapeも正常に動作しました。そのため、この設定はオフのまま検証を進めました。
設定を変更したら「Save&Apply」をクリックします。処理メッセージが表示されます。
ネットワークインタフェースを手動でリスタートするようにとのメッセージが表示されています。[Dismiss]ボタンをクリック、通知メッセージを閉じます。いったん保留として、次の[Tools]メニューを確認します。
[map.sh Management]には、まさに前回対処したICMP関連の不具合についての説明が記載されています。
OpenWrt’s map.sh has bugs: only the first port group works and ICMP is broken.
Click below to replace with the fixed version.
(OpenWrtのmap.shにはバグがあります。最初のポートグループしか機能せず、ICMPが
正常に動作しません。以下のボタンをクリックして、修正版に置き換えてください）
前回、nftコマンドで対処したICMP関連の不具合は、どうやらmap.shのバグのようです。
現在は[Original version]と表示されています。[Patch]ボタンをクリック、パッチを適用します。
再び、ネットワークインタフェースを手動でリスタートするようにとのメッセージが表示されました。
[Dismiss]ボタンをクリック、通知メッセージを閉じます。
ネットワークインターフェースをリスタートします。[Network]から[Interfaces]をクリックします。[Interfaces]から[wan6]の[Restart]ボタンをクリックします。
[wan6]インターフェースのリスタートにより、[Flet’h Configuration]メニューで設定した[map.sh Management]についての変更内容が反映されました。
反映されない場合は、ネットワーク全体、あるいはOpenWrt自体の再起動を行うのが良いと思います。
3. 動作確認
OpenWrtコンソールにて簡単にIPv4通信も確認しておきます。
root@OpenWrt:~# wget -4 -O- http://1.1.1.1/ >/dev/null && echo "IPv4 TCP OK"
IPv4 TCP OK
root@OpenWrt:~# ping -4 -c 4 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=57 time=8.703 ms
64 bytes from 1.1.1.1: seq=1 ttl=57 time=9.401 ms
64 bytes from 1.1.1.1: seq=2 ttl=56 time=9.356 ms
64 bytes from 1.1.1.1: seq=3 ttl=57 time=9.434 ms
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 8.703/9.223/9.434 ms
root@OpenWrt:~#
OpenWrtのシステムログからluci-app-fleth関連の動作ログを確認します。
ログには、以下のようにwan6のifupを契機にfleth autoが実行されたことが記録されました。
root@OpenWrt:~# logread | grep -E 'fleth|fleth-hotplug' | tail -10
Sat Jun 6 23:14:52 2026 user.notice fleth-hotplug: Interface wan6 up, running fleth auto
Sat Jun 6 23:14:52 2026 user.notice fleth: is running 1最後にクライアントPCやタブレット・スマートフォンなどでインターネット通信ができれば、確認OKです。
ベンチマーク測定
後日、「みんなのネット回線速度」でベンチマーク測定しました。
IPv4接続方式は「IPoE + IPv4 over IPv6(v6プラス)」と判定され、下り710.01Mbps、上り449.68Mbps、Ping値 12.6ms、ジッター値 0.98msでした。
変わらず、v6プラス/MAP-EのIPv4通信も快適です。
まとめ
今回、luci-app-flethを導入、現在のIPv6アドレスをもとにv6プラス/MAP-E設定が自動構成されることを確認しました。以前のようにIPv6プレフィックスを見ながら、共有IPv4アドレスやMAP-Eパラメータを手作業で確認し、OpenWrtへ静的設定し直す手間は、解消できました。操作もとても簡単でした。素晴らしい。
実際に将来IPv6プレフィックスが変更されたとき、OpenWrt上でどのようなイベントとして処理されるかまでは今回検証できていません。…なにせ5年間変わらなかったアドレスですから。
この点は、次回のIPv6プレフィックス変更が発生したときに確認する必要があります（いつになるやら）。
一方で、実際に自動化設定をして気付きもありました。
MAP-E設定が自動で復旧するようになった場合、共有IPv4アドレスの変更に気が付きにくくなる可能性があります。共有IPv4アドレスを使って、クラウドサービス側のファイアウォールや、サーバ側のfirewalldでアクセス制限している箇所があるため、これには少し注意が必要です。
前回は、通信障害の復旧作業中にIPアドレス変更にも気が付いたので、クラウド側の許可IP設定も併せて修正を行いました。今後は通信自体が自動で戻ることで、クラウド側の許可IPだけが古い状態のまま取り残されてしまう可能性があります。
そのため、共有IPv4アドレスが変わった場合に通知する仕組みは、別途検討したいと思います。
もっとも、クラウドサーバへSSH接続するときに、あれっ？繋がらない？と気が付くことにはなると思いますが。
今回の作業でMAP-E設定まわりは自動化できましたが、自動化できた部分と、監視が必要になる部分は分けて考える必要がありそうです。
謝辞
luci-app-flethを公開、メンテナンスしてくださっている作者huggy /makedingさんに感謝します。
MAP-E設定の自動構成からmap.shのPatch/RestoreまでGUIで扱えるのは本当に便利です。
大変素晴らしいツールだと思います。
（おしまい）
コメント