お知らせ

現在サイトのリニューアル作業中のため、表示が崩れているページが存在することがあります。

R86S U1を買ってOpenWrtをインストールしてから今までずっとSPF+ポートが認識されていなかったので認識可能にした。

確認環境

  • R86S U1
  • OpenWrt 24.10.0

前提条件

  • インターネット環境があること

手順

  1. 認識されているかどうか確認し、何も出てこなければ次のステップへ
    dmesg | grep mlx4
    
  2. ドライバをインストール
    opkg install kmod-mlx4-core
    
  3. 再び認識されているかどうかを確認する
    dmesg | grep mlx4
    

なぜこれをしようと思ったか?

最初はeth0, eth1との排他制御かと考えていたが、RJ45とSPF+でNICが分離している構造上ありえないので、有効化できるはずだと思ったためやってみた。ポートはあればあるほど都合がいいし、RJ45が使えればSPF+に対応してない機器もつなげて便利なので。

有効化したSPF+ポートをLANに繋ぐ方法

機材不足で未検証だが、基本的にはOpenWrtでR86S U1のeth2ポートをLANに繋ぐ方法でLANに繋ぐものが出来ると思う。

参考までに有効化したSPF+ポートはeth3, eth4として認識されていることを確認している。これはdmesg | grep mlx4すると分かる。

本記事はここ昨今のOpenWrtセットアップシリーズの続きである。

OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けない。しかし、IPv6であれば、理論上全部のポートが使えるはずで、それであればサーバーを建てられるのではないかと考えたので、やってみた記録。

セキュリティを考慮し、サーバー以外にはアクセスできないよう、NATのような仕組みで構築する。

確認環境

環境 内容
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アクセスが可能で、かつ以下のセットアップが終わっているものとする。

今回の要件

ルーターのファイアウォールでサーバーマシンのみ穴をあけ、それを塞ぐ。つまりIPv4のNATにあったセキュリティの再現を行うことで、関係ない端末が攻撃されないようにする。

やり方

サーバーとDNSの設定

  1. nginxの設定を開きlisten [::]:443を追加して再起動
    1. sudo service nginx restart
  2. サーバーマシンのIPv6(Global Unique Address, GUA)を控える
    ip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'
    
  3. Value DomainのDNS設定を開きAAAAレコードに、先ほど控えたIPv6アドレスを登録する

ルーターのファイアウォールに穴をあける

設定ファイルを編集する方法
  1. vi /etc/config/firewallで以下の行を追加
    config rule
            option name 'Allow-Server-IPv6'
            option src 'wan'
            option dest 'lan'
            option proto 'tcp udp'
            option dest_ip 'さっき控えたサーバーのIPv6アドレス'
            option dest_port '443'
            option family 'ipv6'
            option target 'ACCEPT'
    
  2. service firewall restartでfirewallを再起動する
LuCIでやる方法
  1. LuCIに入りNetwork→Firewall→Traffic Rulesを開く
  2. Addボタンを押し、次の要領で入力して保存
    General Settings

    項目
    Name Allow-Server-IPv6
    Protocol TCP│UDP
    Source zone wan
    Destination zone lan
    Destination address さっき控えたサーバーのIPv6アドレス
    Destination port 443

    Advanced Settings

    項目
    Restrict to address family IPv6 only
  3. 穴をあけたIP以外が外部から疎通しないことを確認

  4. 穴をあけたIPが外部から疎通することを確認

備考

OCN光のIPoE(MAP-E)方式のIPはv4, v6ともに基本的に変動しない

結論から言うと引っ越しでもしない限り、v4が固定なのは知っていたが、v6も固定らしい。

v6のアドレスが変わる気配がないので、OCNのテクニカルサポートに聞いた結果、PPPoEは変動IPv4でルーター再起動時にIPが変わるが、IPoEであればIPv4, IPv6ともに半固定で通常は変わらないとのことだった。

つまりVLANやip6tablesがなくてもサーバーを公開できると言う事でOCN様々と言う事である。

IPv4アクセスをどうするか?

現状は2案検討している。

  1. どっかにペラのページを置いておき、「IPv6でアクセスしてください」みたいなお知らせページにしておく
  2. SNSなどのOGP対策で、簡単なプロキシを組んでおき、OGPだけ出るようにしておく

2のケースだとレンサバにv6側サイトのOGP取得用のCGIを置いておくとか、v6側サイト更新時にOGP付きのペラのHTMLを置いておくなどが検討できると思う。

Cloudflare Tunnelを使わない理由

Cloudflare Tunnelを使えればIPv4を利用でき、デュアルスタック対応もできるだろう、しかしなぜ使わないのかという話。

基本的にオンプレミス至上主義だからというのが答えにはなるが、実務的な理由もある。

まずCloudflare Tunnelを利用する場合、ネームサーバーを委任する必要があるが、CloudflareのDNSはさくらインターネットのSPFレコードを扱おうとするとバリデーションエラーを吐いて使えない。他にも、管理画面のUIがお世辞にもよくなく、言葉を選ばず言えばクソである点もある。勿論、余計なレイヤーを増やすことによる運用コストの増大もあるため、使わなくて済むのであれば、それに越したことはないという考えだ。

またCloudflareのWAF機能やhCAPTCHAがユーザーとして嫌いなのもあり、自分が嫌いなものをユーザーに提供したくないのもあるし、Cloudflareのエラー画面を見て嬉しく思う人もいないと思うので、あのインフラには乗りたくない思いもある。

IPv4のデュアルスタック対応としては、VPNにリバプロをかけるのも検討したが、レガシーに縋っていても仕方がなく、今のところはIPv6に注力する方向にしようとしている。世界のIPv6移行に末端からでも貢献出来たらいいなくらいの気持ちでやっていくのだ。

疎通検証に使える簡易サーバーの作り方

PHP

php -S "[::]:80"でIPv6向けの簡易サーバーをサクッと立てられるので疎通検証をするときに便利。

Node.js

http-serverだとhttp-server -p 80 -a "[::]"でいける。serveは未対応っぽい。

疎通確認に使えるcurl例

IPv6はURL形式が特殊なのでアドレス部分を[]で囲んだ書式で投げる。これはブラウザで確認する場合でも変わらない。

curl -v "http://[aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh]:80/"

ドメインを利用する場合に、リクエスト先をAレコードとAAAAレコードで明示的に分ける場合は、以下の書き分けができる。

# IPv4向け
curl -4 -v "http://example.com/"
# IPv6向け
curl -6 -v "http://example.com/"

複数ポートの開き方

option dest_portに値を半角スペース区切りで追加すればよい。LuCIでも同じ書き方で通用する。

例:

option dest_port '80 443 8080'

連番で開ける場合は公式ドキュメントによると、'1024:65535'のような書式にすれば、連番で開けられるようだ。

例:

option dest_port '8000:8999'

関連記事

基本的な考え方としてはWindowsマシンをWiFiのAPにした時と同じと思われる。ゲートウェイのDNSを参照するのでhostsを書き換えると成立する。

現状IPv6で行うのは現実的ではなさそうだ。

IPv6ではやる意味自体がないので本記事はIPv4向けだ。

確認環境

  • OpenWrt 24.10.0

手順

SSHでやる方法

  1. hostsを開いてIPとドメインを紐づける
    vi /etc/hosts
  2. DNSを再起動する
    service dnsmasq restart

LuCIでやる方法

  1. Network→DHCP and DNSを開き、DNS Recordsタブを選択
  2. Addボタンを押し、紐づけるドメインとIPを設定する
  3. Save & Applyボタンを押す

IPv6ではやる意味がない

IPv6だと外部DNSに登録したGUAとドメインの紐づけを利用してLAN内のアクセスが出来るためやる必要性がない。IPv6ではGUAを打っても、相手がLANの中にいれば外に出ずに、そのままつながる。これはtracertを打てば分かる。

前回、OSインストールの記事を書いてから約四ヶ月、今回は実際にインターネットへの接続をやっていく。接続にはOCN バーチャルコネクトを利用する。

色々あって四ヶ月放置していたR86Sにはいい感じに埃が積もっていた。

確認環境

  • R86S U1
  • OpenWrt 24.10.0
  • OCNバーチャルコネクト

手順

OSインストールが終わっているものとする。

また、この手順ではLANケーブル(RJ45)を使って進めている。

途中でインターネットを利用する場面が何度かあるため、キャリア回線でWWWに出られるスマホがあると便利だ。

R86Sに接続する

eth1にWAN, eth0にLANを接続する。

パッケージのインストール

SSHで192.168.1.1に接続し次のコマンドを流しパッケージをインストールする。

opkg update
opkg install luci
opkg install map
reboot

Web管理画面へのアクセス

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の値は後で使うので全部控えておく。

WAN側IPv6のDHCP(DHCPv6 client)の設定

wan6のEditボタンを押す。

DHCP Serverタブを開き、「Set up DHCP Server」ボタンを押す。

IPv6 Settingsタブを開きRA-Service、DHCPv6-Service、NDP-Proxyをrelay modeに変更し、保存する。

LAN側IPv6のDHCPの設定

先ほどと同様に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向けの設定をしてゆく。

MAP-E用インターフェースの作成

次の要領でインターフェースを作成する。

項目
Name wanmap
Protocol MAP / LW4over6

MAP-E用インターフェースの設定

ここでは控えておいた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」にチェックを入れ、保存する。

Firewallの設定

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/に接続し、判定ボタンを押し、試験1~4と、契約中のフレッツ東西の光がOKになっていれば疎通は問題ないと思われる。

後は適当に幾つかサイトを開いたりfast.comで回線速度を見て疎通確認を実施した。

ストレージの拡張(2025/08/26追記)

イメージを焼いた関係で、初期パーティションが狭い。R86S U1のeMMCは128GBもあるので、これを拡張する。

  1. GPartedのサイトからイメージを落とし、最新のRufusで適当なメディアにイメージを焼く。
  2. GPartedを焼いたメディアをR86Sに接続
  3. R86Sを起動しDeleteボタン連打でBIOSに入る
  4. Boot OptionでGPartedの起動順位をトップにする
  5. 再起動し一番上のGParted Live(Default settings)で起動
  6. 起動するとGPartedの画面が出ているのでパーティションを最大まで広げる

やり終えてから思ったが、OpenWrtインストール時に使ったUbuntuServerにpartedくらい入ってるだろうし、それでやってもよかったかもと思った。

発生したトラブル

192.168.1.1に繋がらない

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のルーターをスイッチングハブとして使っている影響などが関係しているかもしれないので、しばし静観の方向で…。

ルーター起動後、Windowsでネットワークアダプタが認識中のままになる、インターネットに繋がらない

電源投入からOCNバーチャルコネクトのリンクアップまで20~50秒ほどかかるので気長に待つ。

LAN側IPv6のDHCPの設定でDHCPv6-Serviceの値はrelay modeかserver modeか?

OpenWrtではDHCPv6の運用が難しいため、基本的にrelay modeでよいと思う。

おまけ

eth0をWAN、eth1をLANにする方法

  1. NetworkからInterfacesを開く
  2. wanとwan6のDeviceをeth0に変更
  3. Devicesタブに切り替る
  4. br-lanの「Configure…」ボタンを押す
  5. General device optionsのBridge portsをeth1にして保存
  6. Save & Applyを押す

CPU温度を見る方法

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の姿

まぁまぁいい塩梅だと思う。

撤去されたYAMAHA RTX830

R86S + OpenWrtを導入するまで使っていたRTX830。価格の割にIPv6向けの機能が貧弱だったり、設定が手間だったり、マニュアルが雑目だったり、あまりいい思い入れはなかった。

OCNバーチャルコネクトの接続がBuffaloルーターより早く安定している点と、LAN向けのDNSがあるのは便利だったが、あの読みづらいマニュアルはもう少し何とかした方がよいと思う。

今回セットアップした感想

今のところ予想以上にトラブルや問題がなく、平然と動いているため、かなり満足している。

RTX830との比較

管理画面の操作性や充実度はRTX830を遥かに超えており、非常に体験がよかった。

設定変更についてもSave & Applyを押すまでは保留状態になるため、間違った設定が即座に反映されないのもよい。

しかもPending changesをクリックすると設定ファイルに対する差分も確認でき、大変便利だ。

電源投入からOCNバーチャルコネクトへのリンクアップまでの時間も体感RTX830と大差なく、Buffaloルーターのように接続ネゴシエーションの成功を祈っていたら1~2時間経過していたみたいなこともないのは素直にうれしい。fast.comで計測した限りでは速度やレイテンシの劣化もなく大変満足している。

DHCP設定の静的リースのUIが便利すぎる

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スイッチを購入する予定であるため、恐らくソフトウェア的な制御によって起きているであろうこの問題は、いずれ解消するとは思う。

次の作業に向けて

設定のカスタマイズなどを通してよりよい環境にしていき、IP変動環境でIPv6を利用した自宅サーバーの公開や、10GbEの導入などに向けて挑戦していきたいところだ。

参考記事

2025/07/31 12:31 ジャンル::雑記

今月はかなり忙しく、記事を書く余裕など本来なかったはずなのだが、かつてTwitterでいわれていたところの忙しいほどツイート数が伸びるの法則的な奴なのか、やけに記事数が伸びた。この記事も含めると19記事であり、過去を見ても多い部類だ。

参考までにこれが忙しかった今月のスケジュールと、暇だった去年の11月のスケジュール。青色は固定スケジュールで睡眠とか風呂とかそういう系、水色は一般追加スケジュール、黄色やオレンジは重要なスケジュールみたいな感じだ。今月はスケジュールに未記載の予定も多々あり、表示内容以上に忙しい月だった。

5月はそこまで忙しくなかったが記事は多いので、別に忙しさとの相関関係はないのだが、忙しいのに記事数が伸びたなというので、記念に書置きしておく。

本記事のような小ネタ系が多いので伸びたというのが正しい気はするが、それでも記事は記事なので、まぁ…。