Posts

今日は穏やかなんで背割堤を歩けた。

近年はやたらオオバンが増えた。

数年前までは鴨ばかりだったが。

それより、相変わらず退屈で困る。

最早、この世には用が無い(笑)

暇だから、シングルコアのラズパイB＋をPPPoEマルチセッションでルーターにして、クライアントPCからスループットを測定した。
100Mbpsのサービスではボトルネックにはなるが、十分使えるレベル。

クライアントからこのルーターにデフォルトルートを切り替えて使う意味は無いので、配下にDNATで攻撃LOG収集用のサーバーでもぶら下げるかな・・・それにしても暇だな(笑)

自宅ネットワークの入り口が二つになったが、意味あるのか？(笑)

一応VPNサーバーも載せてる。
firehol level1～3のipsetも問題なく載せられた。
Pi2Bと比べると、起動時間はかなり長い。

午後も暇だから攻撃収集用サーバーを組むか(笑)

B+がもう一台余っており、今後使うことはないんで、無駄な攻撃収集用サーバーとして無駄に活用するか・・・ これぞ、無駄が無駄を呼ぶ典型パターン(笑)

というわけで、正規サーバーのSDカードをベースにB+で攻撃収集用サーバーをセットアップした・・・
それにしても暇な一日であった(笑)

正規サーバーは国内限定にしており、殆どアクセスが無くつまらないんで、暇に任せて用意した・・・
このようなスキャンや、その他攻撃を眺めるのが趣味なのか？(笑)

163.5.148.15 - - [03/Jan/2026:14:52:11 +0900] “GET /workspace/drupal/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 497 “-” “libredtail-http”
163.5.148.15 - - [03/Jan/2026:14:52:12 +0900] “GET /panel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 497 “-” “libredtail-http”
163.5.148.15 - - [03/Jan/2026:14:52:12 +0900] “GET /public/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 497 “-” “libredtail-http”
163.5.148.15 - - [03/Jan/2026:14:52:13 +0900] “GET /apps/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 497 “-” “libredtail-http”

別室のデスクの下にあるスペースに、メインサーバーと並べて配置。
無駄が無駄を呼ぶ構成の完成(笑)
メインサーバーは冷却効率を上げるためにアルミ板の上に置いてあるのが面白い。

ヘッドレスでラズパイのSDカードを使いまわす場合、Predictable Network Interface Namesの命名ルールが邪魔になるので、無効化する。

① predictable naming を無効化

sudo nano /boot/cmdline.txt

1行の末尾に追記（改行しない）：

net.ifnames=0 biosdevname=0

② オンボードLANを eth0 に固定する udev ルール作成（必須ではない）

sudo nano /etc/udev/rules.d/70-onboard-eth.rules

中身（Pi 2 / 3 / B+ 共通）

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS==“smsc95xx”, NAME=“eth0”

③ /etc/network/interfacesを編集

オンボードNICのデバイス名をeth0に変更

④ SDカード移植後、machine-id を再生成

rm -f /etc/machine-id
systemd-machine-id-setup

●machine-idを直接生成して書き込む場合

・例として、別システムの /mnt/media/ にシステムディスクをマウントして書き込む場合
cat /proc/sys/kernel/random/uuid | tr -d ‘-’ | sudo tee /mnt/media/etc/machine-id

⑤ まとめ（実務視点）

・/etc が書ければ今回の作業は全部できる
・/boot は初回だけ
・SD 移植後は /etc だけ触れば復旧可能
・ヘッドレス運用でも詰まない

2016年4月頃からは、本サーバーのみならずルーターもRaspberry Pi 2B（以下 Pi2B）で運用していたが、偶然見つけたNICが二式実装されている小型PC、LIVA-Zを衝動買い(笑)
2020年10月に、LIVA-Z をルーターとして入れ替えで導入し、すでに5年以上が経過している。

overlayfs を使ってシステムディスクを読み取り専用化しているため、ストレージ寿命の不安は小さいが、一般的にこの手の小型PCは電源周りが先に逝くことが多い。

負荷が低い用途なので、トータルで10年程度は持ちそうではあるものの、「いつかは壊れる」という前提で、次の置き換え候補を考えておくのは無駄ではない。

現状はRaspberry Pi によるWi-Fi AP付 PPPoEルーターの構成にある記事の構成となっているが、暇な年末年始の時間を使い、現在LIVA-Z で運用しているルーター構成をほぼそのまま移植してみた。

●移植した構成

・iptables / ipset を用いたフィルタリング
・各種スクリプト類（更新・定期処理含む）
・常時稼働前提の最低限構成

LIVA-Z 側と極力差が出ないようにし、「置き換えたらどうなるか」をそのまま再現する形にしている。

●処理能力の差は明確

まず感じたのは、純粋な処理能力の差。

特に、

・ipset のアップデート所要時間
・大量ルールを一気に適用する場面

では、LIVA-Z の方が明らかに速い。

この点については ARM SoC の Pi2B が劣るのは当然で、性能面では割り切りが必要になる。

●それでも問題にならない理由

一方で、実運用において重要な スループット に関しては、結果は意外だった。

100Mbps クラスのサービス環境下では、Pi2B でも LIVA-Z と体感上ほとんど差がない

回線速度がボトルネックになる以上、ルーター側のCPU パワーは余剰になりがちだ。
USB NIC を追加した Pi2B でも、スループット面で不満を感じる場面はなかった。

●Pi2Bを代替候補として見る理由

Pi2B をあらためて「LIVA-Z の代替」として見ると、以下の点が大きい。

・低コスト

本体も周辺部品も安価で、壊れても精神的ダメージが少ない。

・構造がシンプル

電解コンデンサレスのボード構成で、経年劣化要因が少ない。

・バックアップと復旧が容易

SDカードを丸ごとバックアップしておけば、故障時も即リカバリ可能。

この 復旧性の高さ は、小型PCにはない安心感がある。

結論：LIVA-Zが止まったら、素直にPiで行く

処理能力では LIVA-Z に及ばないものの、100Mbps 環境でのルーター用途に限れば Pi2B でも十分現実的だという結論になった。

養老で養老

ルートを変え、稲荷神社の参道を往復してから来た。
結構な人出で、初詣を前倒しする人が増えているようだ。

今日は下り線

オリエンタルカレー、また値上げ
カツカレーにしようかと思ったが、高すぎて引いた・・・
円安インフレが本当にヤバい。

連休なので奮発してミル挽き珈琲。
連休は関係ないけど（笑）

それにしても、素のカレーと珈琲で1,230円とは・・・
珈琲は自宅で飲むインスタント、ネスカフェ・ゴールドブレンドの方が美味い。
これで最後にするか。