2026年1月30日金曜日

android自作アプリがWIFIで内部サーバに接続できない問題

  外部からは、モバイル回線だと接続できるけれど、家でWIFIだと内部サーバに接続できないという問題があり、いろいろ解決まで時間がかかった。ちなみに、Chromeなどでは問題なく接続できるので、自作アプリに問題あるのは予想できた。

 ChatGPTでも解決できず、googleAIに質問したところ、解決。android:networkSecurityConfig="@xml/network_security_config"が厳格すぎたせいだった。自作アプリには、かなりセキュリティ対策を厳密にしているらしい。もともと、androidはgoogle製なので、的確な回答ができたのだと思う。

 WIFIかどうかをアプリ内で判別し、URLを切り替えたり、ポート制限もしているので、合わせて、network_security_configでLocalIpの設定を入れたらOkだった。

2026年1月27日火曜日

スマホから支払記録のセキュリティ改善

 買い物などしたとき、少し時間あるときはスマホで支出内容をraspiにネット経由で記録して、あとでPCで自作家計簿を開くと確認ボタンですぐ反映できるようにしている。転記したら一時置き場所のraspiのデータは削除します。これまでは、一時的データなのでとくに認証とかしてなかったのですが。少し工夫してみました。

 C#版とQt版としばらく併用していて、先々Qt版に切り替える予定ですが、いずれもデータ取り込みについては、同じraspiサーバ(bottle)を使っているので、大幅に作り変えたくないと考えました。家計簿ソフトはさわらず、bottleのみ改善しました。

 いったん外部から接続できなくして、認証ページをつくり、指定した時間、認証ページが使っているアドレスからのアクセスのみ受け付けるような仕組みを組み込みました。これによって、一定時間のみスマホからデータ入力ができるようになりました。入力が終わって、指定時間がすぎれば、自動的にまた接続できなくなるので、それほど手間なくできそうです。

2026年1月26日月曜日

raspiにbind9

LAN内のラズパイ、ルータ、プリンタ、アクセスポイントなど、ホスト名でアクセスできるように 内部DNSにしてみた。以前行ったbind9の設定の仕方を思い出しながら、うまくいかなかったところは、chatGPTの助けも借りながら、なんとか完了。

・ルータは静的ルーティング設定で、自分のドメインのものはすべて、ルータに行くように設定。LAN側サーバアドレスをラズパイにして、ラズパイにbind9を入れます。

・ufwで、tcp,udpでローカル内からの53番ポートのアクセスを許可します。

・各種設定はネット上の情報を参照して行った。 host コマンドで最後に確認。

※今回、/etc/resolv.conf に問題があることがchatGPTから指摘受ける。どうやらnetworkManagerから生成されたものが、ルーターに行くようになっていて、raspi(127.0.0.1)が使われてないことがわかる。ただ、/etc/resolv.conf は 直接編集できず、
nmcli connection showでeth0でいいか確認して、
sudo nmcli connection modify "eth0" \
ipv4.ignore-auto-dns yes \
ipv4.dns 127.0.0.1 \
ipv6.ignore-auto-dns yes \
ipv6.dns ::1
これを反映
sudo nmcli connection down "eth0"
sudo nmcli connection up "eth0"
確認するとcat /etc/resolv.confー>nameserver 127.0.0.1

まだ、よくわからないところもあるが、とりあえず、指定したホスト名で内部はアクセスできるようになった。

※さらに、これだけではよくないらしくnamed.conf.optionsに追加して

options {
directory "/var/cache/bind";
recursion yes;  clientが「全部教えて」>BINDは、自分の zone を探し、なければ、無ければ 権威DNS …を 最後まで代行して答える。これが無いと「権威サーバーに聞いてね」で終わる。
allow-recursion { localnets; localhost; };再帰を 誰に許すか。localnets とは?BINDが認識している 直結ネットワーク  
allow-query { localnets; localhost; };DNS問い合わせそのものを誰に許すか。LAN内 → 正引き・逆引きともにOK  外部 → そもそも答えない   内部専用DNSなら 必須

# 外向きは forwarder に任せる(安定)
forwarders {
1.1.1.1;
8.8.8.8;
};
dnssec-validation auto;
listen-on { 127.0.0.1; 192.168.1.0/24; };BINDが どのIPアドレスで待ち受けるか。
挙動   127.0.0.1 → 自分自身
192.168.1.x → LANからのDNS
書かないと? デフォルトで 全インターフェース IPv6含めて全部待ち受けることも
不要な露出を防ぐため明示推奨
};

2026年1月25日日曜日

raspiでcloudflareのリバースプロキシを使うためにufwいれてみた

raspiの外部公開もそろそろセキュリティが気になってきたのでOS更新にあわせて、cloudflareを使ってみることした。そのためにufwを設定する必要があった。

sudo ufw allow sshをまず最初に入れるのが鉄則
curl https://ifconfig.meで、グローバルIp確認、それを次にいれる
sudo ufw allow from <自分のIP> to any port 443 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcpで、LAN限定にしたいなら
sudo ufw delete allow sshで、最初の設定削除
cloudflareのリバースプロキシを使うのが目的なので、そちらにのみ許可する設定です
# IPv4
curl https://www.cloudflare.com/ips-v4
# IPv6
curl https://www.cloudflare.com/ips-v6 でIp確認
これをみて
sudo ufw allow from 173.245.48.0/20 to any port 443 proto tcpを続ける
sudo ufw allow from 2400:cb00::/32 to any port 443 proto tcpも同様
ここまでの確認は sudo ufw status numbered この時表示なる番号をもとに、削除もできる
例。sudo ufw delete 2 # ルール番号指定で削除

sudo ufw allow from 192.168.1.0/24 to any port 80 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 443 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 8080 proto tcp(bottle確認用)
でLAN内からのWEBアクセスは可能にしておく

注意:Cloudflare IPは変わることがある→ cron スクリプトで自動更新

そこで、このあとは、次のようなスクリプトを用意
#!/bin/bash
# ファイル名: update-cloudflare-ufw-home.sh
# LAN内 + Cloudflare + WAN自動IP用 ufw 443自動更新
# cronやsudoでも安全に動作
# --- 設定 ---
LAN_CIDR="192.168.1.0/24"   # LAN内ネットワーク
UFW_PORT=443
TMP_DIR="$HOME/tmp"
# --- 0. 一時ディレクトリ作成 ---
mkdir -p $TMP_DIR
# --- 1. Cloudflare IP取得 ---
curl -s https://www.cloudflare.com/ips-v4 > $TMP_DIR/cf-ips-v4.txt
curl -s https://www.cloudflare.com/ips-v6 > $TMP_DIR/cf-ips-v6.txt
# --- 2. 既存Cloudflare 443ルール削除(LANルールは残す) ---
# IPv4
if [ -f "$TMP_DIR/cf-ips-v4.txt" ]; then
  for ip in $(cat $TMP_DIR/cf-ips-v4.txt); do
      sudo ufw delete allow from $ip to any port $UFW_PORT proto tcp 2>/dev/null || true
  done
fi
# IPv6
if [ -f "$TMP_DIR/cf-ips-v6.txt" ]; then
  for ip in $(cat $TMP_DIR/cf-ips-v6.txt); do
      sudo ufw delete allow from $ip to any port $UFW_PORT proto tcp 2>/dev/null || true
  done
fi
# --- 3. LAN内ルール再登録(もしまだない場合) ---
sudo ufw allow from $LAN_CIDR to any port $UFW_PORT proto tcp
# --- 4. Cloudflareルール追加 ---
if [ -f "$TMP_DIR/cf-ips-v4.txt" ]; then
  for ip in $(cat $TMP_DIR/cf-ips-v4.txt); do
      sudo ufw allow from $ip to any port $UFW_PORT proto tcp
  done
fi
if [ -f "$TMP_DIR/cf-ips-v6.txt" ]; then
  for ip in $(cat $TMP_DIR/cf-ips-v6.txt); do
      sudo ufw allow from $ip to any port $UFW_PORT proto tcp
  done
fi
# --- 5. WAN自分IP取得・追加 ---
MYIP=$(curl -s https://ipinfo.io/ip)
if [ -n "$MYIP" ]; then
    sudo ufw allow from $MYIP to any port $UFW_PORT proto tcp
fi
# --- 6. 状態確認 ---
sudo ufw status verbose
以上のスクリプトをcronに追加
crontab -e
0 6 * * * /home/pi/update-cloudflare-ufw-home.sh

※対策はあくまでインバウンドのみです。インバウンドのみcloudflareのセキュリティ対策を経たトンネルを使います。アウトバウンドは通常の経路です。ルータは443のみオープンにして、80は閉じても大丈夫です。SSL更新もcloudflareにまかせるか、こちらでやる(DNS-01というらしい。数日前設定したばかりだが。)か、選べる。

※cloudflareにまかせるには AやCNAMEをproxiedにして
sudo systemctl status certbot.timerでこちら管理しているようならとめて、起動しないように
sudo systemctl stop certbot.timer
sudo systemctl disable certbot.timer
確認はsudo systemctl status certbot.timer
sudo systemctl is-enabled certbot.timerでinactive ,disabledならok

cloudflare側は 「SSL/TLS」メニュー> Origin Certificate を入れている場合 → Full (strict) 
・「Edge Certificates」タブ>Always Use HTTPS:オンにすると自動で HTTPS にリダイレクト
・ Cloudflare → SSL/TLS → Origin Server>「Create Certificate」で Origin Certificate を作成>サーバに設置、この証明書があれば Let’s Encrypt は不要になる

sudo a2enmod ssl
sudo a2ensite default-ssl
sudo systemctl reload apache2
sudo mkdir -p /etc/ssl/cloudflare
sudo chmod 700 /etc/ssl/cloudflare

origin_cert.pemとorigin_key.pemとして保存
sudo chmod 600 /etc/ssl/cloudflare/*

sudo nano /etc/apache2/sites-available/default-ssl.conf
SSLEngine on
SSLCertificateFile /etc/ssl/cloudflare/origin_cert.pem
SSLCertificateKeyFile /etc/ssl/cloudflare/origin_key.pem
# 推奨の TLS 設定
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:!aNULL:!MD5
このあと、以下のコマンドで完了
sudo a2enmod ssl
sudo a2ensite default-ssl
sudo systemctl reload apache2

※最後に、lan内でrapsiのhttpsにアクセスするとその都度警告がでますが、requestlyという拡張機能をchromeに入れると文字置換https://ホスト名>http://192.168~のような感じにできて解決できるようです。

2026年1月24日土曜日

raspi復旧マニュアル

今回、raspi2のSSL更新を簡潔にするために、OSのクリーンインストールをしたため、その後のハードよりの設定でだいぶ苦労しました。OSが違うと、いろいろ大変なようです。念のため、備忘録つくりました。他にも、いろいろひっかるところはありましたが、とりあえず、GPIO周りがとくに大変だったので、関連操作まとめました。
 
1 Python スクリプト (ssr_control.py)
保存場所: /home/pi/ssr_control.py
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# SSR制御スクリプト
# 指定曜日・時間のみSSRをONにし、それ以外はOFF
# 対象GPIO: 17 (BCM)
import RPi.GPIO as GPIO
import datetime
import time
# GPIO 設定
GPIO.setmode(GPIO.BCM)
GPIO.setup(17, GPIO.OUT)

try:
    while True:
        now = datetime.datetime.now()
        weekday = now.weekday()  # 月曜=0, 日曜=6

        # 水曜(2)と土曜(5)の6時〜7時にON、それ以外はOFF
        if (weekday == 2 or weekday == 5) and 6 <= now.hour < 7:
            GPIO.output(17, GPIO.HIGH)  # SSR ON
        else:
            GPIO.output(17, GPIO.LOW)   # SSR OFF

        time.sleep(30)  # 30秒ごとにチェック

finally:
    GPIO.cleanup()
ポイント:
時間は 6 <= now.hour < 7 で 1時間だけ ON。
曜日は weekday() の値を確認(0=月曜, 6=日曜)。
30秒ごとにチェックするループ。

2 systemd サービス設定 (ssr_control.service)
保存場所: /etc/systemd/system/ssr_control.service
[Unit]
Description=SSR Control
After=network.target

[Service]
Type=simple
User=pi
WorkingDirectory=/home/pi
ExecStart=/home/pi/bottle-env/bin/python /home/pi/ssr_control.py
Restart=on-failure

[Install]
WantedBy=multi-user.target
ポイント:
User=pi にして仮想環境(bottle-env)の Python を使用。
WorkingDirectory はスクリプトのあるディレクトリ。
失敗時に自動再起動。

3  systemd の操作コマンド
# サービスを再読み込み(設定変更後は必須)
sudo systemctl daemon-reload
# サービスを有効化(起動時に自動開始)
sudo systemctl enable ssr_control.service
# サービス起動
sudo systemctl start ssr_control.service
# 状態確認
sudo systemctl status ssr_control.service
# サービス停止
sudo systemctl stop ssr_control.service
# ログ確認
journalctl -u ssr_control.service -b
※ バックアップ・復旧のコツ
/home/pi/ssr_control.py と /etc/systemd/system/ssr_control.service を両方コピーして保存。
Python 仮想環境 (bottle-env) も丸ごとバックアップしておくと、ライブラリの問題で復旧に悩まなくて済む。
OSアップデート後は、GPIOライブラリや Python バージョンを確認してから systemd サービスを再有効化。

2026年1月18日日曜日

FreeNove Esp32 Wroverで間欠WebCam動作テスト

  Freenoveのesp32 wroverについては、ストリーミングだと負荷がかかりすぎるし、付属のサンプルコードはカメラとGPIOを同時に細かい制御ができないコードのようなので、間欠で静止画をWebで表示しつつ、GPIOの操作するようなコードを試してみた。FNK0060というパッケージに合わせてライブラリなどそろえる必要あるようだった。

index.htmlは、IDEがver2だとアップロードできないので、Ver1を使う必要があった。

2026年1月14日水曜日

外気温 温度計の液晶修理

 接触不良を接点復活材で直した液晶温度計も、今度は中心部が黒っぽくなり見づらくなってきた。たまたま、Youtubeで修理方法出ていたので試してみた。反射フィルムと偏光フィルムをはがして、ガラス板(中に液晶があると思われる)だけにしてから、アルミテープと購入した偏光フィルム(amazonn等でも入手可)を入れなおしたらうまくいった。偏光フィルムは角度を調整して、一番見やすい角度にしてから、枠に合わせて切り取る必要があります。ちょっとしたことだけれど、毎日見るものでもあるので、少しでも見やすくすることは大事かもしれない。