検索条件

から
検索タグ ソフトウェア::OpenWrt
タグで絞り込み Webサービス(1) Webサービス::Value-Domain(1) ジャンル(8) ジャンル::ガジェット(2) ジャンル::自宅サーバー(8) ジャンル::買い物(1) ネットワーク(6) ネットワーク::DNS(1) ネットワーク::IPv4(2) ネットワーク::IPv6(2) ネットワーク::OCNバーチャルコネクト(2) 技術(1) 技術::監視(1)
日付で絞り込み 2025年(9) 2026年(2)
全11件 (1/3ページ) 一覧表示に切り替え

2026/02/22(日)OpenWrtからValue-Domainに複数サブドメインのDDNSを行うツールを作った

投稿日：

Value-DomainのダイナミックDNSエンドポイントは60秒以内に叩くとエラーが返ってくるので、これを回避するためのDDNSの仕組みを作った話。

やったこと

まず、Value-DomainのDNS APIに対し、既存のaレコードをバルクで差し替えるためのツールとしてvd-ddns_v4.plを作った。

そしてhotplug.dにPPPoEインターフェースのIPが変わったときに、このスクリプトを蹴る処理を書いた。

この記事の前提構成

OpenWrtにIPv4用のPPPoEインターフェースがある。

やったこと

  1. 今回利用するのに必要なPerl周りをセットアップする。ストレージの空きが3.2MBほど必要
  2. value-domain-dns-utilを/root配下とか適当な場所に放り込む
    • opkg install openssh-sftp-serverでSFTPを導入しておくとファイル移動に便利

  3. vi /etc/hotplug.d/iface/40-pppoeとかして、OpenWrtのインターフェースが変化したときのHookを作る

     #!/bin/sh
 # デバイスが存在しなければ終了
 [ -n "$DEVICE" ] || exit 0
 # リンクアップでなければ終了
 [ "$ACTION" = ifup ] || exit 0
 # インターフェース名がPPPoEのものでなければ終了
 [ "$INTERFACE" = wanppp ] || exit 0
 # pppoe-wanpppのIPv4アドレスを取得
 pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
 # ログに吐く
 logger -t "DDNS - PPPoE IP" $pppoeaddr
 # DDNSもどきを叩く
 /root/vd-dns-util/vd-ddns_v4.pl 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' example.com $pppoeaddr hoge fuga piyo
 # 結果をログに吐きたいが何故か動いていない
 if [ $? -eq 0 ]; then
 logger -t "DDNS - UPDATE SUCCEED"
 else
 logger -t "DDNS - UPDATE FAIL"
 fi

  4. PPPoEインターフェスをRestart

  5. Value-Domainのコンパネで指定したドメインのaレコードが更新されていることを確認

備考

一般的にDNSレコードの浸透時間は更新前に浸透していたTTLに依存し、Value DomainのAPI経由で普段から操作している場合は120秒以下にならないため、最大120秒のダウンタイムが発生するが、理論上は公式のDDNS機能と大差ないはずと思われる。

aレコードのみの対応にしているのは私の環境だとIPv6は変動しないが、v4はそれなりの頻度で変わるためだ。

運用しているMastodonのv4が変わったのに気づかないまま疎通できないインスタンスが出てくることがしばしばあり、手動で対応するのが手間なのと、毎回一日くらい気づくのに遅れるので今回自動化に踏み切った。前々からやり勝ったのだが、中々腰が重く進んでいなかった。

そもそもこの手のものは監視システムで検知できて然るべきなので、おいおい監視システムの構築もしていきたいところだ。

コメント（0件）

2026/02/22(日)OpenWrtにPerlを入れてHTTPSやJSON、自作ライブラリを扱えるようにする

更新日：
投稿日：

確認環境

OpenWrt 24.10.0

やり方

opkg install perl
opkg install perlbase-essential
opkg install perlbase-json-pp
opkg install perlbase-scalar
opkg install perlbase-xsloader
opkg install perlbase-dynaloader
opkg install perlbase-list
opkg install perlbase-bytes
opkg install perlbase-findbin
opkg install perlbase-http-tiny

# OpenWrtにはPerlのSSLモジュールがないので親切な人が作ってくれてるものを使わせていただく
# https://jw2013.github.io/openwrt-packages/
opkg install libustream-mbedtls
wget https://jw2013.github.io/openwrt-packages/public.key
opkg-key add public.key
echo 'src/gz pkgs-by-jw2013 https://jw2013.github.io/openwrt-packages/24.10/x86_64' >> /etc/opkg/customfeeds.conf
opkg update
opkg install perl-net-ssleay
opkg install perl-io-socket-ssl
rm public.key

増加する容量

キビバイトやメビバイトのバイト変換やトータルビバイトはLLMに換算させた欠化を書いているので誤りが混ざっている可能性がある。大まかには合っていると思うが…。

pkg size byte
perl 1.27 MiB 1,331,692
perl-io-socket-ssl 124.00 KiB 126,976
perl-net-ssleay 153.61 KiB 157,297
perlbase-autoloader 3.04 KiB 3,113
perlbase-b 106.07 KiB 108,616
perlbase-base 4.27 KiB 4,372
perlbase-bytes 1.23 KiB 1,260
perlbase-class 3.02 KiB 3,092
perlbase-config 18.55 KiB 18,995
perlbase-cwd 11.31 KiB 11,581
perlbase-dynaloader 4.50 KiB 4,608
perlbase-errno 3.22 KiB 3,297
perlbase-essential 23.79 KiB 24,361
perlbase-fcntl 7.36 KiB 7,537
perlbase-feature 2.68 KiB 2,744
perlbase-file 72.30 KiB 74,035
perlbase-filehandle 1.81 KiB 1,853
perlbase-findbin 1.98 KiB 2,028
perlbase-http-tiny 12.98 KiB 13,292
perlbase-i18n 21.21 KiB 21,719
perlbase-integer 1.12 KiB 1,147
perlbase-io 67.71 KiB 69,335
perlbase-json-pp 11.96 KiB 12,247
perlbase-list 23.14 KiB 23,695
perlbase-locale 10.98 KiB 11,244
perlbase-mime 6.50 KiB 6,656
perlbase-params 4.02 KiB 4,116
perlbase-posix 40.45 KiB 41,421
perlbase-re 285.55 KiB 292,403
perlbase-scalar 1.60 KiB 1,638
perlbase-selectsaver 1.27 KiB 1,300
perlbase-socket 19.49 KiB 19,958
perlbase-symbol 1.94 KiB 1,987
perlbase-tie 18.40 KiB 18,842
perlbase-unicore 779.16 KiB 797,860
perlbase-utf8 1.24 KiB 1,270
perlbase-xsloader 2.54 KiB 2,601
total 3.08 MiB 3,230,188
コメント（0件）

2025/10/14(火)Openwrt本体でメトリクスをグラフで見れるようにした

更新日：
投稿日：

luci-app-statisticsとcollectdを入れて下図のように各メトリクスのグラフを見れるようにした。collectdは、システム情報を定期的に収集し、さまざまな方法で値を格納するメカニズムを提供する小さなデーモンで、luci-app-statisticsはそれをLuCI上に表示するためのものっぽい。

確認環境

Env Ver
OpenWrt 24.10.0

セットアップ

  1. LuCIを開く
  2. System→Software
  3. luci-app-statisticsを入れる
  4. 画面リロード
  5. 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使用率

collectd-mod-cpu

設定 内容 デフォルト
ValuesPercentage trueであれば、パーセンテージで取れる true
ReportByCpu trueであれば、コアごとに取れる true
ReportByState trueであれば、システム、ユーザー、アイドルなど、状態ごとに取れる true

設定はデフォルトのままで良さそう。

collectd-mod-interface：ネットワーク転送量

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>

参考

コメント（0件）

2025/08/27(水)OpenWrtのSSH接続を公開鍵認証方式に限定する

投稿日：

確認環境

Env Ver
OpenWrt 24.10.0

手順

  1. LuCIを開きSystem→Administrationを開き、SSH-Keysタブを開く
  2. Add Keyの左にあるテキストボックスに公開鍵を張り付ける
  3. SSH Accessアクセスタブを開く
  4. Password authenticationのチェックを外す
  5. Save & Applyを押す
  6. SSHにパスワード接続できなくなっていることを確認
  7. SSHに鍵認証接続できるようになっていることを確認

あとがき

この状態ではパスワード認証であるLuCI本体がセキュリティホールになっているため、LuCIも公開鍵認証で入れるようにできるとより理想的に思うが、どのみちローカル以外の接続は弾いているため、そこまでしなくてもいいかというのも思わなくはない。

どこかを踏み台にされない限り不正な攻撃を受けることはないし、そこまで考えるか…？みたいな。

コメント（0件）

2025/08/22(金)OCNバーチャルコネクト環境でIPoE・PPPoE併用のIPv4、IPv6デュアルスタックでサーバーを公開する

更新日：
投稿日：

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

今回の要件

やり方

サーバー側の準備

ufwではv4にも穴が開いている状態とする

  1. nginxの設定を開きIPv4向けにlisten 443 ssl;を追記して保存する
  2. nginxを再起動する

PPPoEインターフェースの作成

  1. SSHでOpenWrtに入る
  2. /etc/iproute2/rt_tablesを開き次のようにpppoeの行を追加、保存 
    #
# reserved values
#
128     prelocal
255     local
254     main
253     default
300     pppoe
0       unspec
#
# local
#
#1      inr.ruhep
  3. 反映する
    • service network restart
  4. LuCIに入る
  5. Network→Interfacesを開く
  6. Add new interfaceから、Nameをwanppp、ProtocolをPPPoEとしたインターフェースを作成する
  7. General SettingsタブのDeviceにONUと疎通しているポートを指定し、PAP/CHAP usernameとPAP/CHAP passwordにISPの接続情報を入れる
  8. Advanced Settingsタブを開き、Use DNS servers advertised by peerのチェックを外し、Use gateway metricを10、Override IPv4 routing tableをpppoe (300)にする
  9. Saveボタンを押して保存する
  10. wanインターフェースのEditを押す
  11. Advanced Settingsタブを開き、Use gateway metricを1にする
  12. Saveボタンを押して保存する

ファイアーウォールの作成

  1. 引き続きLuCI上で作業する
  2. Network→Firewallを開く
  3. ZonesのAddボタンを押す
  4. Nameをwan_pppoeにし、MasqueradingとMSS clampingにチェックを入れ、Covered networksでwanpppを選択し保存する
  5. lan⇒wanのゾーン設定のEditボタンを押す
  6. Allow forward to destination zones:にwan_pppoeを追加し、保存する
  7. Network→Interfacesを開く
  8. wanpppインターフェースのEditボタンを押す
  9. Firewall Settingsタブを開き、Create / Assign firewall-zoneにwan_pppoeが設定されていることを確認する。設定されていなかったら設定する

サーバーだけをPPPoEのIPv4通信の対象にする

  1. 引き続きLuCI上で作業する
  2. Network→Routingを開き、IPv4 Rulesタブを開く
  3. General SettingsタブのIncoming interfaceをlanに、SourceをサーバーのIPにする（例：192.168.1.5/32）
  4. Advanced Settingsタブを開く
  5. Tableにpppoe (300)を設定し、保存する

NATを設定する

  1. 引き続きLuCI上で作業する
  2. Network→Firewallを開き、Port Forwardsタブを開く
  3. Addボタンを押す
  4. Nameに適当な名前を付け、Restrict to address familyをIPv4 only、Source zoneをwan_pppoe、External portを443、Internal IP addressを転送先のサーバーIP、Internal portを443にして、保存する
  5. 最後にこれまでの内容をSave & Applyする

疎通確認

  1. Network→Interfacesを開き、wanpppのIPv4を拾う
  2. ドメインレジストラの設定でAレコードにこれを登録
  3. 適当な外部サーバーから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はあるだけマシではあるものの、超絶使いづらい問題もあり、この環境においてのデュアルスタックはあきらめようと思った。

まぁいい勉強にはなったので、そのうち何かに活かせるだろう、きっと。

2026-05-23追記：この状態で安定運用しているがv4側が疎通しない相手については諦めた

OpenWrtからValue-Domainに複数サブドメインのDDNSを行うツールを作ったのもあり、IPv4が変わったときも自動で切り替えることでダウンタイムを減らす運用ができたので、今のところ不満はない。

ただFediverseで繋がらないところは繋がらないので諦めることにした。

コメント（0件）