R86S U1を買ってOpenWrtをインストールしてから今までずっとSPF+ポートが認識されていなかったので認識可能にした。
dmesg | grep mlx4
opkg install kmod-mlx4-core
dmesg | grep mlx4
最初はeth0, eth1との排他制御かと考えていたが、RJ45とSPF+でNICが分離している構造上ありえないので、有効化できるはずだと思ったためやってみた。ポートはあればあるほど都合がいいし、RJ45が使えればSPF+に対応してない機器もつなげて便利なので。
機材不足で未検証だが、基本的にはOpenWrtでR86S U1のeth2ポートをLANに繋ぐ方法でLANに繋ぐものが出来ると思う。
参考までに有効化したSPF+ポートはeth3, eth4として認識されていることを確認している。これはdmesg | grep mlx4すると分かる。
さくらのレンタルサーバーにLet's EncryptのDNS-01 チャレンジの証明書を持ち込む方法。自動更新できないので実用性はないが、一時的に使う場合に有用。
DNS-01 チャレンジの証明書を既に作っている。
sudo cp /etc/letsencrypt/live/<サイトディレクトリ>/*.pem .
sudo chown $USER:$USER privkey.pem fullchain.pem
本記事はここ昨今のOpenWrtセットアップシリーズの続きである。
OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境であれば理論上IPv6ポートは全部使えるので、そんならポート指定なしでサーバーを建てられるのでは？というのでやってみた。
| 環境 | 内容 |
|---|---|
| ISP | OCN光 |
| ISP契約 | OCN 光 with フレッツ マンション・スーパーハイスピード 隼・プラン1・西日本 |
| ISP接続方式 | OCNバーチャルコネクト(IPoE, MAP-E) |
| RouterOS | OpenWrt 24.10.0 |
| ServerOS | Ubuntu 24.04.3 LTS |
| HTTPD | nginx 1.26.1 |
| ドメインレジストラ | Value Domain |
IPv4環境下でのHTTPSアクセスが可能で、かつ以下のセットアップが終わっているものとする。
ルーターのファイアウォールでサーバーマシンのみ穴をあけ、それを塞ぐ。つまりNATの再現を行うことで、関係ない端末が攻撃されないようにする。
listen [::]:443を追加して再起動
sudo service nginx restartip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'
Addボタンを押し、次の要領で入力して保存
General Settings
| 項目 | 値 |
|---|---|
| Name | 適当につける |
| Protocol | TCP│UDP |
| Source zone | wan |
| Destination zone | lan |
| Destination address | さっき控えたサーバーのv6IPアドレス |
| Destination port | 開けたいポートを半角スペース区切りで入れる |
Advanced Settings
| 項目 | 値 |
|---|---|
| Restrict to address family | IPv6 only |
穴をあけたIP以外が外部から疎通しないことを確認
結論から言うと引っ越しでもしない限り、v4が固定なのは知っていたが、v6も固定らしい。
v6のアドレスが変わる気配がないので、OCNのテクニカルサポートに聞いた結果、PPPoEは変動IPv4でルーター再起動時にIPが変わるが、IPoEであればIPv4, IPv6ともに半固定で通常は変わらないとのことだった。
つまりVLANやip6tablesがなくてもサーバーを公開できると言う事でOCN様々と言う事である。
現状は2案検討している。
2のケースだとレンサバにv6側サイトのOGP取得用のCGIを置いておくとか、v6側サイト更新時にOGP付きのペラのHTMLを置いておくなどが検討できると思う。
Cloudflare Tunnelを使えば確かにこんなことはしなくて済むが、次の理由で使っていない。
一つは、オンプレなのに外部サービスに頼りたくない思いがあること、もう一つはCloudflareでドメイン管理する必要性があるはずだが、Cloudflareでドメイン管理すると今使っているメールサーバーのSPFレコードが正しく登録できない問題があることだ。
OCNバーチャルコネクトはIPv6を使う限り全ポート使えるはずなので、これを利用してサーバーを立てる。
ルーター側だけでなくサーバー側も対応が必要。ファイアーウォールの穴をあけていても、IPv6でlistenしてないと受けられない。
ここでは一旦80番ポートを開けるものとして進める。
vi /etc/config/firewallで以下の行を追加
config rule
option name 'Allow-Server-IPv6'
option src 'wan'
option dest 'lan'
option proto 'tcp udp'
option dest_port '80'
option family 'ipv6'
option target 'ACCEPT'
service firewall restartでfirewallを再起動するAddから次の要領でルールを追加
General Settings
| 項目 | 値 |
|---|---|
| Name | 適当な名前 |
| Protcol | TCPとUDPにチェック |
| Source zone | wan |
| Destination zone | lan |
| Destination port | 開けるポートをスペース区切り |
Advanced Settings
| 項目 | 値 |
|---|---|
| Restrict to address family | IPv6 only |
保存してSave & Apply
ufwやWindowsファイアーウォールの穴は開いているものとする。IPv6向けに穴が開いている必要があるが、通常、ufw addやWindows ファイアーウォールの追加では勝手にv6の穴が開くはずなので意図的に塞がない限り追加時に開いていると思われる。
listen [::]:80を追加するPHP
php -S "[::]:80"でIPv6向けの簡易サーバーをサクッと立てられるので疎通検証をするときに便利。
Node.js
http-serverだとhttp-server -p 80 -a "[::]"でいける。serveは未対応っぽい。
IPv6はURL形式が特殊なのでアドレス部分を[]で囲んだ書式で投げる。これはブラウザで確認する場合でも変わらない。
例：
curl -v "http://[aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh]:80/"
option dest_portに値を半角スペース区切りで追加すればよい。
例：
option dest_port '80 443 8080'
連番で開ける場合は公式ドキュメントによると、'1024:65535'のような書式にすれば、連番で開けられるようだ。
例：
option dest_port '8000:8999'
設定にoption dest_ipを追加し、これで制御できると思うがIPv6が変わる特性上、基本的に難しいと思う。勿論、端末側でIPの変更を検知しOpenWrtの設定を書き換えるバッチを組むなどは出来ると思うが、ややこしい。
VLANを使って隔離するとかできればよいのかもしれないが、具体案は検討できていない。
前回、OSインストールの記事を書いてから約四ヶ月、今回は実際にインターネットへの接続をやっていく。接続にはOCN バーチャルコネクトを利用する。
四ヶ月放置していたR86Sにはいい感じに埃が積もっていた。
OSインストールが終わっているものとする。
また、この手順ではLANケーブル(RJ45)を使って進めている。
途中でインターネットを利用する場面が何度かあるため、キャリア回線でWWWに出られるスマホがあると便利だ。
eth1にWAN, eth0にLANを接続する。
SSHで192.168.1.1に接続し次のコマンドを流しパッケージをインストールする。
opkg update
opkg install luci
opkg install map
reboot
http://192.168.1.1/にアクセスするとWeb管理画面が開くので、ここから設定をしていく。
管理画面上部のNetworkからInterfacesを開き、wan6のIPv6にある先頭4セクションを控え、http://ipv4.web.fc2.com/map-e.htmlを開き入力、計算する。出力されたoption始まりの行の内容をすべて控えておく。
wan6のIPv6にある先頭4セクション（aaaa:bbbb:cccc:dddd）とoptionの値は後で使うので全部控えておく。
wan6のEditボタンを押す。
DHCP Serverタブを開き、「Set up DHCP Server」ボタンを押す。
IPv6 Settingsタブを開きRA-Service、DHCPv6-Service、NDP-Proxyをrelay modeに変更し、保存する。
先ほどと同様にDHCP Serverタブ→IPv6 Settingsタブと開き、RA-Service、DHCPv6-Service、NDP-Proxyをrelay modeに変更し、保存する。
画面左下にある「Add new interface...」ボタンを押し、以下の要領で選択し作成する。ルーター広告はIPv6のRouter Advertisementのことなのでインターフェース名をwan6raとしている。
| 項目 | 値 |
|---|---|
| Name | wan6ra |
| Protocol | Static address |
| Device | Alias Interface: "@wan6" |
Deviceは項目選択後は画像のように@wan6表記になる。
ここでは控えておいたwan6のIPv6にある先頭4セクション（aaaa:bbbb:cccc:dddd）を利用する。
wan6raインターフェースのEditボタンを押し、General Settingsタブにある項目を次の要領で設定する。
| 項目 | 値 |
|---|---|
| IPv6 address | aaaa:bbbb:cccc:dddd::1001 |
| IPv6 gateway | aaaa:bbbb:cccc:dddd::1 |
| IPv6 routed prefix | aaaa:bbbb:cccc:dddd::/56 |
各設定項目に応じて、先頭4セクションの後ろに::1001、::1、::/56を追記するイメージ。
Save&Applyを押し、以下のサイトが開けることを確認する。
この段階ではIPv6にしか繋がらないため、続けてIPv4向けの設定をしてゆく。
次の要領でインターフェースを作成する。
| 項目 | 値 |
|---|---|
| Name | wanmap |
| Protocol | MAP / LW4over6 |
ここでは控えておいたoption始まりの行の内容を利用する。
wanmapインターフェースのEditボタンを押し、General Settingsタブにある項目を次の要領で設定する。
| 項目 | 値 |
|---|---|
| Type | MAP-E |
| BR / DMR / AFTR | option peeraddrの値 |
| IPv4 prefix | option ipaddrの値 |
| IPv4 prefix length | option ip4prefixlenの値 |
| IPv6 prefix | option ip6prefixの値 |
| IPv6 prefix length | option ip6prefixlenの値 |
| EA-bits length | option ealenの値 |
| PSID-bits length | option psidlenの値 |
| PSID offset | option offsetの値 |
Advanced Settingsタブを開き「Use legacy MAP」にチェックを入れ、保存する。
SSHで192.168.1.1に接続し/etc/config/firewallを開く。
config zone
option name 'wan'
...
list network 'wan'
list network 'wan6'
となっている箇所の末尾に以下を追記し保存。rebootコマンドで再起動する。
list network 'wan6ra'
list network 'wanmap'
ルーター再起動後、http://wa.kiriwake.jpne.co.jp/に接続し、判定ボタンを押し、試験１～４と、契約中のフレッツ東西の光がOKになっていれば疎通は問題ないと思われる。
後は適当に幾つかサイトを開いたりfast.comで回線速度を見て疎通確認を実施した。
eth0にLANを接続する事で繋がる。初期設定ではeth0がブリッジ、eth1がWAN、eth2は未設定。
ニチバン問題と同じものかはわからないがコネクションが225を超えた付近で通信が詰まる傾向があった。このため、Configuring OpenWrt to work with Japan NTT IPv6 (MAP-E) serviceのADVANCED CUSTOM CONFIGURATIONを利用し解決を試みたが、たぶん特に意味はなかった。
以下のコマンドを流すことで導入できた。
cd /lib/netifd/proto
mv map.sh map.sh.orig
wget -O map.sh https://raw.githubusercontent.com/fakemanhk/openwrt-jp-ipoe/refs/heads/main/map.sh.new
reboot
ひとまず変更して、意図的に大量のサイトを開いた状態がこちら。一見解消しているように見えるが、人為的にやった結果なので同等の結果かどうかは怪しい。
また一気に大量のサイトを開きまくると、流石に若干詰まりが見られたが、詰まっていた時はルーターさえ疎通しなかったので、単にOSのポートを食いつぶしていただけという可能性もある。
参考までに元のmap.shに戻して同じ操作をしてみたところ、ちゃんとコネクションが張れたので関係なさそう。
以前と比べてネットワーク構成が変わっており、Buffaloのルーターをスイッチングハブとして使っている影響などが関係しているかもしれないので、しばし静観の方向で…。
電源投入からOCNバーチャルコネクトのリンクアップまで20～50秒ほどかかるので気長に待つ。
OpenWrtではDHCPv6の運用が難しいため、基本的にrelay modeでよいと思う。
luci-app-temp-statusをインストールする。
2025年8月4日時点では以下のコマンドでインストールできる。
wget --no-check-certificate -O /tmp/luci-app-temp-status_0.7.1-r2_all.ipk https://github.com/gSpotx2f/packages-openwrt/raw/master/current/luci-app-temp-status_0.7.1-r2_all.ipk
opkg install /tmp/luci-app-temp-status_0.7.1-r2_all.ipk
rm /tmp/luci-app-temp-status_0.7.1-r2_all.ipk
service rpcd restart
インストールが終わるとトップ画面にTemperatureが出てくるほか、Status→Realtime GraphsにもTemperatureが出てくるようになる。
まぁまぁいい塩梅だと思う。
R86S + OpenWrtを導入するまで使っていたRTX830。価格の割にIPv6向けの機能が貧弱だったり、設定が手間だったり、マニュアルが雑目だったり、あまりいい思い入れはなかった。
OCNバーチャルコネクトの接続がBuffaloルーターより早く安定している点と、LAN向けのDNSがあるのは便利だったが、あの読みづらいマニュアルはもう少し何とかした方がよいと思う。
今のところ予想以上にトラブルや問題がなく、平然と動いているため、かなり満足している。
管理画面の操作性や充実度はRTX830を遥かに超えており、非常に体験がよかった。
設定変更についてもSave & Applyを押すまでは保留状態になるため、間違った設定が即座に反映されないのもよい。
しかもPending changesをクリックすると設定ファイルに対する差分も確認でき、大変便利だ。
電源投入からOCNバーチャルコネクトへのリンクアップまでの時間も体感RTX830と大差なく、Buffaloルーターのように接続ネゴシエーションの成功を祈っていたら1～2時間経過していたみたいなこともないのは素直にうれしい。fast.comで計測した限りでは速度やレイテンシの劣化もなく大変満足している。
Network→DHCP and DNS→Static Leasesから現在繋いでいる機器が見れるのがありがたいし、リース情報もわかりやすい。
しかも静的リースを行うときにOpenWrtが把握しているMACアドレスとドメイン名の一覧が出てくるので、手打ちしたり、確認する手間が省けるのも便利だ。リース時間も設定できるし、至れり尽くせりである。
唯一残念なところを挙げるとするとファンが微妙にうるさく、2mの距離があってもモスキート音レベルのささやかな動作音が聞こえる部分だ。これは慣れれば気にならなくなると思いたい。今の時期だとエアコンの音にかき消されてほぼ聞こえないが、それでも寝る前だと個人的には若干気にならなくもない程度だ。薄型のシロッコファンゆえにNoctuaのファンに変えるのも難しく、正直解決策としては物理的に遠くするか、間に何か防音材を放熱の邪魔にならないように挟むくらいしかないだろう。一応メーカー的には静穏ファンとのこともあり、大半の人は気にならないとは思う。
Banana Pi BPI-R4にもSPF+が2つあり、RJ45ソケットもあり、2.5万程度と安価なため、冷却装置をDIYして静穏化する場合はこちらの方が向いている可能性がある。実際にやってる人もいる。
ただまぁスペックはR86Sの方が上等なので、安く静かで多くを求めず、多少大きくてもいいならBanana Pi BPI-R4、多少の騒音を許容でき、スペックが欲しい場合はR86Sというのもありだろう。一般家庭のルーターに、そこまでスペック要るのかどうかというのはさておき…。
今回ルーター側のポート数の制約により、ルーター直結でなくスイッチングハブを通してWWWに接続している。使えるものがBuffaloのWiFiルーターのAPモード（スイッチングハブとして機能する）しかなかったので、これを使っているが、直結と比べた場合にあからさまな性能劣化が見られた。以下は数回計測した上での平均値。小数点以下は切り捨て。
直結時
| 下り速度 | 上り速度 | アンロードレイテンシ | ロード済みレイテンシ |
|---|---|---|---|
| 435Mbps | 430Mbps | 4ms | 5ms |
Buffalo経由時
| 下り速度 | 上り速度 | アンロードレイテンシ | ロード済みレイテンシ |
|---|---|---|---|
| 357Mbps | 422Mbps | 5ms | 13ms |
上りは誤差だが、下りが78Mbps低く、ロード済みレイテンシも倍以上の差が出ている。MMOを辞めた今となっては問題ないとはいえ、なんとも微妙だ…。
ただまぁ、将来的には10GbEスイッチを購入する予定であるため、恐らくソフトウェア的な制御によって起きているであろうこの問題は、いずれ解消するとは思う。
初期状態ではeMMCの一部しか解放されておらず、128GBをフルに使うにはストレージの拡張が必要と聞くので、気が向いたらやりたいところだ。eMMCのストレージを使う未来があまり思い浮かばないので増設になるかもしれないが…。
後は設定のカスタマイズなどを通してよりよい環境にしていき、IP変動環境でIPv6を利用した自宅サーバーの公開や、10GbEの導入などに向けて挑戦していきたいところだ。