luci-app-statisticsとcollectdを入れて下図のように各メトリクスのグラフを見れるようにした。collectdは、システム情報を定期的に収集し、さまざまな方法で値を格納するメカニズムを提供する小さなデーモンで、luci-app-statisticsはそれをLuCI上に表示するためのものっぽい。
確認環境
| Env | Ver |
|---|---|
| OpenWrt | 24.10.0 |
セットアップ
- LuCIを開く
- System→Software
- luci-app-statisticsを入れる
- 画面リロード
- Statics→Graphからグラフが見れることを確認
この時点で幾つかのプラグインが導入されたが、消したり入れたりして、結果として以下のものを導入した。
Collectdのプラグイン設定
/etc/collectd.confをいじると変更できる。
基本的にはLoadPlugin hogeでhogeプラグインを読み込み、以下の書式で設定するようだ。設定がなければLoadPlugin hogeだけでよい。
<Plugin hoge>
Foo true
Bar 1
Baz "fuga"
</Plugin>
Collectdのプラグイン
collectd-mod-cpu:CPU使用率
| 設定 | 内容 | デフォルト |
|---|---|---|
| ValuesPercentage | trueであれば、パーセンテージで取れる |
true |
| ReportByCpu | trueであれば、コアごとに取れる |
true |
| ReportByState | trueであれば、システム、ユーザー、アイドルなど、状態ごとに取れる |
true |
設定はデフォルトのままで良さそう。
collectd-mod-interface:ネットワーク転送量
Network→Interfaces→Deviceにあるものが見れる。
br-lanとMAP-E、PPPoEが見たいので以下のようにした。
LoadPlugin interface
<Plugin interface>
Interface "br-lan"
Interface "map-wanmap"
Interface "pppoe-wanppp"
</Plugin>
collectd-mod-load:負荷(Load Average)
uptimeコマンドで出てくる内容と思われる。1を超えていれば過負荷、割っていれば余裕がある。
Wikipediaによると、1ならその時間平均で全てのプロセスが実行され、1.73なら73%のプロセスが実行待ちになったと言う事のようだ。これを1分、5分、15分の平均で出しているとのこと。
設定項目がない。
collectd-mod-memory
メモリの使用量を取れる。
| 設定 | 内容 | デフォルト |
|---|---|---|
| ValuesAbsolute | 物理メモリ使用量の絶対数で報告するかどうか(つまりどういうこと?) | true |
| ValuesPercentage | メモリ使用量をパーセンテージで報告するかどうか | false |
設定はデフォルトのままで良さそう。
collectd-mod-thermal
デバイスの温度を取れる。
| 設定 | 内容 | デフォルト |
|---|---|---|
| ForceUseProcfs | Linuxインターフェースではなく、procfsから熱源を取得する | false |
| Device | 温度を取得するデバイス名 | |
| IgnoreSelected | trueにするとDeviceで指定したデバイスを集計外にする |
false |
R86S U1の場合、thermal_zone1以外無価値に見えたので、thermal_zone1のみとした。thermal_zone0はマザーボードの温度のようだが、固定値しか出てこない。
LoadPlugin thermal
<Plugin thermal>
Device "thermal_zone1"
</Plugin>
これだけだと余計なグラフが出てくるため、設定後に余計なグラフデータを削除する。
collectd-mod-uptime
公式にマニュアルはなさそうだが、起動時間を見れる。
LoadPlugin uptime
collectd-mod-rrdtool
collectdが取得したメトリクスを保存したり、メトリクスのグラフを書くのに使われている模様。特に設定せずとも勝手に設定されるため設定を気にする必要性はなさそう。
ログは標準では/tmp/rrd/OpenWrt/に保存されているようなのでストレージの摩耗は気にしなくていい。(/tmp/はオンメモリストレージ)
トラブルシューティング
Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される
上図の青枠のように壊れて表示されていない画像や、集計対象外のものが表示されている場合、/tmp/rrd/OpenWrt/配下にある不要なメトリクスを削除することで非表示にできる。
例えば上図にあるthermal-cooling_device*にはまともにデータが入っていないため、画像が壊れて表示されている。rm -Rf thermal-cooling_device*で消すと出てこなくなる。
上図の状態になると、下図のように不要なグラフが表示されなくなる。
但しcollectd.confで以下のようにデバイスを絞っていないと、再び出てくると思われるので、設定で表示したいものだけに絞ってから消した方がよい。
LoadPlugin thermal
<Plugin thermal>
Device "thermal_zone1"
</Plugin>
参考
OCNバーチャルコネクト環境でIPv6サーバーをポート443で公開した時にやったことを派生させて更にIPv4にも対応させるプラン。
OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けないが、PPPoEを使って取得したIPv4であれば開けるので、これとIPoE側のIPv6の併用でデュアルスタックでWell-known portsの開放を行い、サーバーを運用できるようにするのが目的だ。
確認環境
| 環境 | 内容 |
|---|---|
| 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 |
今回の要件
- OCNバーチャルコネクト環境でIPv6サーバーを公開した時にやったことに追加でIPv4も開通させる
- IPv4はPPPoEで取得できるものを使う
- サーバーマシン以外の端末に影響を与えない
やり方
サーバー側の準備
ufwではv4にも穴が開いている状態とする
- nginxの設定を開きIPv4向けに
listen 443 ssl;を追記して保存する - nginxを再起動する
PPPoEインターフェースの作成
- SSHでOpenWrtに入る
/etc/iproute2/rt_tablesを開き次のようにpppoeの行を追加、保存# # reserved values # 128 prelocal 255 local 254 main 253 default 300 pppoe 0 unspec # # local # #1 inr.ruhep- 反映する
service network restart
- LuCIに入る
- Network→Interfacesを開く
- Add new interfaceから、Nameをwanppp、ProtocolをPPPoEとしたインターフェースを作成する

- General SettingsタブのDeviceにONUと疎通しているポートを指定し、PAP/CHAP usernameとPAP/CHAP passwordにISPの接続情報を入れる

- Advanced Settingsタブを開き、Use DNS servers advertised by peerのチェックを外し、Use gateway metricを
10、Override IPv4 routing tableをpppoe (300)にする

- Saveボタンを押して保存する
- wanインターフェースのEditを押す
- Advanced Settingsタブを開き、Use gateway metricを
1にする - Saveボタンを押して保存する
ファイアーウォールの作成
- 引き続きLuCI上で作業する
- Network→Firewallを開く
- ZonesのAddボタンを押す
- Nameを
wan_pppoeにし、MasqueradingとMSS clampingにチェックを入れ、Covered networksでwanpppを選択し保存する

- lan⇒wanのゾーン設定のEditボタンを押す
- Allow forward to destination zones:に
wan_pppoeを追加し、保存する

- Network→Interfacesを開く
- wanpppインターフェースのEditボタンを押す
- Firewall Settingsタブを開き、Create / Assign firewall-zoneに
wan_pppoeが設定されていることを確認する。設定されていなかったら設定する

サーバーだけをPPPoEのIPv4通信の対象にする
- 引き続きLuCI上で作業する
- Network→Routingを開き、IPv4 Rulesタブを開く
- General SettingsタブのIncoming interfaceを
lanに、SourceをサーバーのIPにする(例:192.168.1.5/32)

- Advanced Settingsタブを開く
- Tableに
pppoe (300)を設定し、保存する

NATを設定する
- 引き続きLuCI上で作業する
- Network→Firewallを開き、Port Forwardsタブを開く
- Addボタンを押す
- Nameに適当な名前を付け、Restrict to address familyを
IPv4 only、Source zoneをwan_pppoe、External portを443、Internal IP addressを転送先のサーバーIP、Internal portを443にして、保存する

- 最後にこれまでの内容をSave & Applyする
疎通確認
- Network→Interfacesを開き、wanpppのIPv4を拾う
- ドメインレジストラの設定でAレコードにこれを登録
- 適当な外部サーバーからcurlを投げて中身が返ってきたらOK
curl -4 -v https://example.com
IP変動対策にDDNSを設定する
/etc/hotplug.d/ifaceに40-pppoeというファイルを755で作り、以下の内容を記述する。
#!/bin/sh
[ -n "$DEVICE" ] || exit 0
[ "$ACTION" = ifup ] || exit 0
[ "$INTERFACE" = wanppp ] || exit 0
vdpw=ここにDDNS更新用のパスワード
pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
logger -t "DDNS - PPPoE IP" $pppoeaddr
# hoge.example.comに対して更新リクエストを飛ばす例
logger -t "DDNS - DOMAIN: hoge" $(wget -O - "https://dyn.value-domain.com/cgi-bin/dyn.fcg?d=example.com&p=$vdpw$&h=hoge&i=$pppoeaddr")
# When making requests for multiple domains, wait 60 seconds between each request
このスクリプトはhotplugイベントが発生したときにファイルパス順に呼ばれるスクリプトらしい。
ひとまずデバイスでなく、インターフェイスが起動したときで、かつインターフェース名がwanpppの時に実行されるように組んである。
注意点として、このエンドポイントはレートリミットがシビアで、60秒以内に送ると503を返してくるようなので、複数回投げる場合はsleep 61とかして間隔をあけると良さそうだ。数が増えてきたらバリュードメインAPIのDNS設定APIを利用した方が早いだろう。
ただしこのAPIはTTLの制御に難があり、処理方法によっては3600秒に固定される罠が潜んでいるので注意が必要だ。
トラブルシュート
curlで「Connection refused」や「接続が拒絶されました」と出る
/var/log/ufw.logにログがあればufwで穴をあける(まずこれはない)- ファイアーウォールかルーティングかNATの設定のどこかがおかしいので見直す。
同一LANにぶら下がっている端末でDNS解決に失敗する
PPPoEインターフェース(wanppp)の設定を開き、Advanced SettingsからUse DNS servers advertised by peerのチェックを外すと直る。
雑感:かなり苦しい
IPv4, v6のデュアルスタックに出来たのはいいが、幾つかの端末で繋いだところIPv4側に流れるケースがあった。メインのv6でなく、オプションのv4に行くという状況はやや残念だ。
構成的にもマルチセッションという微妙な形態で、v4とv6でインターフェースが二系統あり、セキュリティもNATとFWがあり、なかなか複雑な状態になってしまった。
Mastodonにおいてはv4IPのインスタンス(兵庫丼)との疎通はTLレベルでは出来たものの、画像が出なくなるという頭が痛い問題に出会った。
Misskey.ioからは疎通できず、こちらからはユーザープロフィールまではアクセスできるがフォローを押しても音沙汰がない。
結論としてはリッチなアプリケーション通信を伴う用途において、この方式は向かない気がした。恐れくこれはルーターより外側がIPoEとPPPoEで別系統になっている関係で、通信が混乱して上手くいかないパターンがあるのではないかと感じている。
DDNSも制約が厳しいし、Value DomainのAPIはあるだけマシではあるものの、超絶使いづらい問題もあり、この環境においてのデュアルスタックはあきらめようと思った。
まぁいい勉強にはなったので、そのうち何かに活かせるだろう、きっと。
R86S U1を買ってOpenWrtをインストールしてから今までずっとSPF+ポートが認識されていなかったので認識可能にした。
確認環境
- R86S U1
- OpenWrt 24.10.0
前提条件
- インターネット環境があること
手順
- 認識されているかどうか確認し、何も出てこなければ次のステップへ
dmesg | grep mlx4 - ドライバをインストール
opkg install kmod-mlx4-core - 再び認識されているかどうかを確認する
dmesg | grep mlx4
なぜこれをしようと思ったか?
最初はeth0, eth1との排他制御かと考えていたが、RJ45とSPF+でNICが分離している構造上ありえないので、有効化できるはずだと思ったためやってみた。ポートはあればあるほど都合がいいし、RJ45が使えればSPF+に対応してない機器もつなげて便利なので。
有効化したSPF+ポートをLANに繋ぐ方法
機材不足で未検証だが、基本的にはOpenWrtでR86S U1のeth2ポートをLANに繋ぐ方法でLANに繋ぐものが出来ると思う。
参考までに有効化したSPF+ポートはeth3, eth4として認識されていることを確認している。これはdmesg | grep mlx4すると分かる。









