policy-routing で Squid を別ポートに振分け
自宅のプロバイダ接続のルータは、上流2.5Gbps だけど、DHCPなどの設定の自由度が低いため、内側に WiFi ルータを置いた2段構成。ただし、上流ルータの LAN ポートが 1Gbps なので、2.5Gbps を活かせていない。
自宅サーバを使わない catvstb は、上流ルータの WiFi ポートを指定することで、内側 WiFi を使わないようにして、少しはトラヒックを分割した。
でも、さらなるトラヒックを活かすべく、内側ルータ内のサーバに2本目の LAN ポートを設け、内側 WiFi ルータを経由せずに上流ルータにつながるようにして、Squid の Proxy サーバのトラヒックだけこちらに流したい。
policy-routing の設定
設定の要点を Gemini に伝え、現状の netplan の設定を伝えて、policy routing の設定を提示してもらった。

---
network:
version: 2
renderer: NetworkManager
ethernets:
enp2s0:
match:
macaddress: "4C:CC:6A:F9:B0:84"
addresses: [192.168.11.3/24]
nameservers:
addresses: [192.168.11.3]
routes:
- to: default
via: 192.168.11.1
metric: 100 # メインの優先度を高く設定
enxc8a362ed15ee:
match:
macaddress: "c8:a3:62:ed:15:ee"
addresses: [192.168.1.51/24]
routes:
# メインのルーティングテーブルにはデフォルトゲートウェイを書かない
# 代わりに、Squid専用の「テーブル200」の中にだけゲートウェイを作る
- to: default
via: 192.168.1.254 # 上流ルーター
table: 200
routing-policy:
# 192.168.1.51 を「出発地」とするパケットだけをテーブル200へ飛ばす
- from: 192.168.1.51
table: 200
適用して、問題がなさそうなので、squid に以下の設定を追加。
((( /etc/squid/conf.d/policy-routing.conf ))) tcp_outgoing_address 192.168.1.51
動作を確認
Proxy ナシの Chrome と Proxy アリの Firefox を起動して、YouTube を閲覧中。catvstb でも 上流ルータをそのまま使って YouTube を視聴中。CATVSTB=赤、SquidProxy=青、通常パケット=水色でトラヒックが分散されている。自宅外からWebサーバが閲覧できることも確認できた。満足…

HTTP3+QUIC 対応で FireWall に udp/443 を追加しただけ
HTTP3+QUIC だと、QUIC 用に UDP/443 を使うらしい。
サーバの設定は後で見直すとして、ひとまず FireWall + 自宅ルータの DMZ 設定で、UDP/443 を追加してみた。
んで、apache2 で HTTP3+QUICK を探すと、標準モジュールでは対応していないとな。さすがに apache を手作業インストールで運用する気はおこらんなぁ…
Rust 版 switchbot-cli のインストール
Switchbot を使っていて、HomeAssistant などで活用しているけど、スイッチ動作を登録するとき、照明だと、リモコン信号でON/OFFを切り替えるため、点灯状態によっては、ON を押しても照明としては消えたりすることもでてくる。
このため、Homebridge では、電源ボタンではなく、全点灯=ON, 常夜灯=OFF で登録している。こういう細かい制御となるとサーバで管理した方が楽なので、コマンドライン側から Switchbot を使いたい。
Switchbot を扱っていて、調べてみると Rust 版があるらしい。以前 nodejs 版も入れたけど、monit からの google-home-player (nodejs版)の呼び出しで、色々トラブルで動かなかったりするので、Rust 版を試したい。
Rust 版 switchbot-cli をインストール
“cargo install switchbot-cli” でインストールができるというが、エラーでコンパイルに失敗。Rust の最新版が必要みたい。最新版の rustc-1.88, cargo-1.88 などを入れて、rustup コマンドで環境を登録。最終的に switchbot-cli を root でインストール。
((( rustc-1.88 などのインストール ))) $ sudo apt install rustc-1.88 cargo-1.88 rustup ((( rustup に 1.88 使用を明言 ))) $ sudo rustup override set 1.88 ((( root 権限で switchbot-cli をインストール ))) $ sudo cargo install switchbot-cli --root /usr/lib/cargo $ cd /usr/local/bin $ sudo ln -sf /usr/lib/cargo/bin/switchbot .
switchbot-cli の使い方
switchbot コマンドを使ってみる。
((( switchbot-cli に TOKEN, SECRET を登録 )))
$ switchbot
Token> xxxxxx
Secret> xxxx
: 学習リモコン (remote with screen, ID:xxxxx)
2: CO2センサー (MeterPro(CO2), ID:xxxxx)
3: CO2センサー・子供部屋 (MeterPro(CO2), ID:xxxxx)
4: switchbot-hub3 (Hub 3, ID:xxxxx)
:
18: リビングの照明 (Light, ID:xx-xxxxxxxxxxx-xxxxxxxx)
((( 使ってみる )))
$ switchbot xx-xxxxxxxxxxx-xxxxxxxx turnOff # デバイスID で操作。
$ switchbot 18 turnOn # 前述のデバイスの連番 18 でもいいみたい
$ switchbot 18 help
turnOn
every home appliance can be turned on by default
turnOff
every home appliance can be turned off by default
customize/{user-defined button name}
all user-defined buttons must be configured with commandType=customize
brightnessUp
brightness up
brightnessDown
brightness down
customize/{user-defined button name}
all user-defined buttons must be configured with commandType=customize
$ switchbot --alias リビングの照明=xx-xxxxxxxxxxx-xxxxxxxx
$ switchbot リビングの照明 turnOn
$ switchbot --alias switchbot-hub3=xxxxxxxx
$ switchbot switchbot-hub3 status
humidity: 49
version: "V2.0-1.6-1.6"
moveDetected: false
temperature: 19.1
onlineStatus: "online"
lightLevel: 1
$ switchbot switchbot-hub3 status.temperature
19.5
monit による外出/帰宅検出
HomeAssistant による外出/帰宅検出を試しているけど、オートメーションではなかなか面倒な雰囲気。
gemini に簡単な ping 監視を提案してもらったら、monit を紹介してくれた。
monit インストール
pre-script で install コマンドでの -Z オプションが原因でインストールに失敗してたけど、pre-install のスクリプトを強制的に直してインストール。
monit で外出/帰宅検出

((( /etc/monit/conf.d/iphone.conf )))
# count 10 = 5min # /etc/monit/monitrc set daemon 30
check host iphone with address iphone
if failed ping count 10 then exec "/etc/monit/script.d/iphone17.sh off"
else if succeeded then exec "/etc/monit/script.d/iphone.sh on"
((( /etc/monit/script.d/iphone.sh )))
MONIT_SUMMARY="/usr/bin/monit -B summary"
case "$1" in
on )
/usr/local/bin/google-home-player.sh "帰宅しました"
/usr/bin/touch /var/lib/monit/status/iphone
;;
off )
/usr/local/bin/google-home-player.sh "外出しました"
/usr/bin/rm -f /var/lib/monit/status/iphone
;;
* )
;;
esac
google-home-player が動かない
目的の処理は呼び出されているが、google-home-player.sh が動かない。普通にコマンドラインであればきちんと発声してくれるのに、monit の script で動かすときだけ発声しない。
色々実験すると、google-home-player.sh の中でパイプを処理する際の標準入力の所有権のトラブルが想定される。そこで、Gemini が提案してくれた、cat を挟む方式を試す。…. 効果なし
((( google-home-player.sh の末尾 )))
if [ $# -gt 0 ]; then
# コマンドライン引数を google home で喋らせる。
- echo "$@" | exec $GHP_TALKJS $GHP_ARGS
+ echo "$@" | /usr/bin/cat | exec $GHP_TALKJS $GHP_ARGS
else
# 標準入力を google home で喋らせる。
- exec $GHP_TALKJS $GHP_ARGS
+ /usr/bin/cat | exec $GHP_TALKJS $GHP_ARGS
fi
コマンド実行のプロセス環境の問題なので、最後の手段、発声処理を batch コマンドで実行させてみる。…効果なし
google-home-player.sh にて、nodejs を呼び出す際に、exec を付けているが、これが原因なのか?
AI系に色々と確認させたけど、Copilot が google-home-player を呼び出す際の js スクリプトに 発声終了の確認せずにプロセスが終わって、発生が止まっている可能性を指摘してきた。提案してくれたスクリプトの修正をして、試す。
HomeAssistant で洗濯機の監視
HomeBridge の homebridge-people-pro で色々な機器を ping で監視し、その On/Off 変化に応じて通知を飛ばすスクリプトを運用している。でも、HomeAssistant のオートメーションで同様のことが可能となる。
スマートフォン への ping での監視は短時間の切断が発生するので、自作スクリプトの処理で対応しているので homebridge を全廃とはいかないけど、ボチボチと HomeAssistant に移行したい。
洗濯機の監視
自宅洗濯機は、洗濯乾燥中に ping が通って、停止すると ping が切れるだけなので、洗濯機の停止の通知なら単純。
google-home で喋らせるスクリプトは運用できている。Ping(ICMP) で洗濯機, user_a, user_b の監視は登録済み。発声の通知は user_a, user_b のどちらかが居る場合のみにしたいので、以下のような設定となった。
((( shell_command.yaml )))
sh_google_notify_washer_stop: "/usr/bin/ssh -i .ssh/id_ed25519 user@host /usr/local/bin/google-home-player.sh '洗濯機停止"
((( automations.yaml )))
- alias: "洗濯機停止の報告"
trigger:
- platform: state
entity_id: "binary_sensor.washer"
from: "on"
to: "off"
for:
minutes: 1
condition:
- condition: or
conditions:
- condition: state
entity_id: "binary_sensor.iphone_user_a"
state: "on"
- condition: state
entity_id: "binary_sensor.iphone_user_b"
state: "on"
action:
- service: "shell_command.sh_google_notify_washer_stop"
HomeAssistantのボタン・スイッチ
HomeAssistantの設定にようやく慣れてきた。
Raspberry-Pi の別ホスト(host)で CEC を使ってテレビの ON/OFF のスイッチや、入力切替操作ができるボタンを設置してみた。
別ホストでの処理を ssh で実行
HomeAssistant のローカルから 別ホスト に ssh で login できるように設定。
$ sudo docker exec -it homeassistant bash host:/config# ssh-keygen -i .ssh/id_ed25519 host:/config# ssh-copy-id -i .ssh/id_ed25519.pub user@host
ボタンとスイッチを yaml で登録
スイッチ操作するための設定を configuration.yaml に登録する。
shell_command , template は、この後、色々と登録することになるので、別ファイルにまとめる。
((( configuration.yaml )))
# 設定を別ファイルにまとめる
shell_command: !include shell_command.yaml
template: !include template.yaml
((( shell_command.yaml )))
# スイッチ/on/off (cec-client.sh でCECで制御できるように設定済み)
sh_tv_on: "/usr/bin/ssh -i .ssh/id_ed25519 user@host /usr/local/bin/cec-client.sh tv on"
sh_tv_off: "/usr/bin/ssh -i .ssh/id_ed25519 user@host /usr/local/bin/cec-client.sh tv off"
# 入力切替のコマンド
sh_tv_src: "/usr/bin/ssh -i .ssh/id_ed25519 user@host /usr/local/bin/cec-client.sh tv src"
((( template.yaml )))
# ボタン-------------------
- button:
- name: "TV入力"
unique_id: "btn_tv_src"
press:
action: "shell_command.sh_tv_src"
# スイッチ
# サービス Ping(ICMP) で tv の ping を登録済み
- switch:
- name: "TV"
unique_id: "sw_tv_power"
state: "{{ is_state('binary_sensor.tv', 'on') }}"
turn_on:
- action: "shell_command.sh_tv_on"
turn_off:
- action: "shell_command.sh_tv_off"

homebridgeをSSL化のトラブル
homebridge-config-ui-x の更新をかけたときに homebridge が動かなくなった。
https://….:8581 で起動していたけどページが表示できず、http://…:8581 ならページが見れる。
以前、homebridgeのSSL化を行っていたけど、Let’s encrypt の SSL の更新が行われていて、homebridge の再起動時に SSL の鍵が読めなくなったのが原因。ということで、Let’s encrypt の更新スクリプトに、以下の処理を追加
# homebridge に SSLキーのアクセス権を与え、再起動 /usr/bin/setfacl -m u:homebridge:r 証明書へのPATH/fullchain.pem /usr/bin/setfacl -m u:homebridge:r 証明書へのPATH/privkey.pem /usr/bin/hb-service restart # homeassistant の再起動 /usr/bin/docker restart homeassistant > /dev/null
openDMARCの設定
gemini cli で設定確認
最近の自宅サーバでの暇つぶしは、gemini-cli を使って設定の見直し。
gemini が確認する際には、sudo 付きで systemctl restart やら LOGファイルにエラーが記録されていないか見たうえで、次々と問題点の提案&改善&実行してくれる。
openDMARCが動かなかった原因
んで、自サバで動かしているメールサーバで、メール受信時の確認として、openDMARC を導入しようとしてたけど、うまくいってなかった。そこで、「”/etc/postfix”を確認して、”/etc/opendmarc.conf”を確認して」を連発してみた。
openDMARC については、opendmarc のグループに postfix ユーザが含まれていなかったのが原因。
これで、受信メールの正当性チェックで spam が減らせるかな。
homeassistant を watchtower で更新
先日 DHCP の設定で、Docker 環境が DHCPREQUEST を出しているかもとの勘違いで、HomeAssistant をアンインストールしていたけど、改めて HomeAssistant を運用再開。
HomeAssistant の運用再開(HTTPSに変更)
HomeAssistant のイメージダウンロードして、設定を最初から…と思ったけど、前回インストールしてあったものが残ってて、一発で環境が復活。
でも、homeassistant の更新方法を確認すると、docker image をダウンロード, stop, remove ,新しいイメージを run させるとかの手順が出てきて面倒。Gemini に聞いたら、Watchtower を勧めてくれた。
また、HomeAssistant を https で起動するように設定を見直す。
$ sudo docker stop homeassistant
$ sudo docker rm homeassistant
$ sudo docker run -d \
--name homeassistant \
--privileged \
--restart=unless-stopped \
-v /var/lib/homeassistant:/config \
-v 証明書へのPATH:/certs:ro \
--network=host \
ghcr.io/home-assistant/home-assistant:stable
$ sudo /var/lib/homeassistant/configuration.yaml # 以下を追記
http:
ssl_certificate: /certs/fullchain.pem
ssl_key: /certs/privkey.pem
$ sudo docker restart homeassistant
Watchtower で HomeAssistant の更新
HomeAssistant を自動更新させる Watchtower をインストールする手順は、Gemini に出てきた設定方法をそのまま実行。
$ sudo docker run -d \ --name watchtower \ --restart=unless-stopped \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower --interval 86400 homeassistant $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e94a5eea7468 containrrr/watchtower "/watchtower --inter…" 4 seconds ago Up 1 second (health: starting) 8080/tcp watchtower 94c7a25097d4 ghcr.io/home-assistant/home-assistant:stable "/init" 6 minutes ago Up 6 minutes homeassistant
でも、現状のバージョンが 2025.9 だったので、最新の 2025.12 に早々に上げたいので、確認したら、以下のように、 –run-once を指定して実行すればいいらしい。
$ sudo docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
containrrr/watchtower \
--run-once \
homeassistant
エラーが出たので、Gemini の協力もあり、バージョン指定で更新。
$ sudo docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
-e DOCKER_API_VERSION=1.44 \
containrrr/watchtower \
--run-once \
homeassistant
無事に、2025.12.5 に更新ができた。
んん? –run-once で更新ができるのなら、watchtower を起動させっぱなしなのは、プロセス資源がもったいない。/etc/cron.monthly で “docker run … watchtower –run-once …” を実行した方がいいじゃん。docker stop/rm watchtower して cron 管理に移行させた。
Docker管理の Portainer のインストール
Docker 絡みで Gemini にお勧めを聞いたら、Docker を Web の GUI で管理ができる Portainer をすすめられた。
ということで、おすすめ設定を実行。
https 通信を使うので、オレオレ証明書のエラー画面で継続をすると、自宅サーバのアクセスで信用できない通信が表示されるようになる。そこで自宅サーバの証明書を使うように設定を追加。(Gemini に聞くと証明書の設定方法を提案してくれる。便利。)
((( 設定データ保存用のボリューム作成 )))
$ sudo docker volume create portainer_data
((( Portainer コンテナの起動 )))
$ sudo docker run -d \
-p 8000:8000 \ # Edge Agent通信用の HTTPポートの割り当て
-p 9443:9443 \ # HTTPSポートの割り当て
--name portainer \
--restart=always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data \
-v 証明書へのPATH:/certs \
portainer/portainer-ce:latest \
--sslcert /certs/fullchain.pem \
--sslkey /certs/privkey.pem
Homebridge を https に変更
Dockerの https の設定がうまくできたし、Homebridge も https で使えないか確認。ただし、homebridge は user=homebridge で起動しているので、アクセス権を与えないと、秘密鍵が読めない。かといって 証明書のアクセス権をユルユルにするのも避けたいので、Geminiに設定を提案してもらうと ACL でアクセス権を与える方法を示してくれた。(Linux での ACL の使い方、参考になる。Geminiに感謝。)
((( ACL で 読み込み権限を与える )))
$ sudo setfacl -m u:homebridge:r 証明書へのPATH/fullchain.pem
$ sudo setfacl -m u:homebridge:r 証明書へのPATH/privkey.pem
((( /var/lib/homebridge/config.json )))
"platforms": [
{ "name": "Config",
"port": 8581,
"lang": "ja",
"theme": "purple",
"menuMode": "default",
"lightingMode": "light", "sessionTimeout": 100000,
"platform": "config",
"ssl": {
"cert": "証明書へのPATH/fullchain.pem",
"key": "証明書へのPATH/privkey.pem"
}
},
((( homebridge 再起動 )))
$ sudo systemctl restart homebridge
ということで、homebridge, HomeAssistant, DockerのPortainer などの Web サービスを https 化することができ、ブラウザの「保護されていない通信」の表示を消すことができた。



