2026-06-23  VNC接続不能の原因調査・復旧（pf無効化／screensharingd枯渇）

【背景・目的】
norizuki.com（159.28.108.2 / 自宅Mac mini 2012 / Catalina）へ VNC（画面共有）
接続できないとの報告。原因調査と復旧を実施。

【調査・切り分け】
- DNS: norizuki.com → 159.28.108.2（同一LAN, ping 0.7ms）。ホストは生存。
- ポート: SSH(22) OPEN だが VNC(5900) は作業Mac(159.28.108.1)から CLOSED/FILTERED。
- SSH（Mac Mini ProxyJump）でサーバー内調査:
  - screensharingd は起動中・5900 LISTEN（サービス自体は正常）。
  - 5900 に外部スキャナIP（43.228.157.x/213.177.179.x/36.255.97.x 等）からの
    CLOSE_WAIT が 33 件滞留。
  - pfctl -si → 「Status: Disabled」。pf 5900ルール無し、whitelist/blacklist
    テーブル未適用、blacklist 0件。＝pfが完全に無効だった。

【根本原因】
2026-05-02 のサーバー再構築後、pf を起動時に自動有効化する仕組みが欠落し、
pf が Disabled のまま放置されていた（/etc/pf.conf は Apple 標準のままで
norizuki/blacklist アンカーを読み込まず）。
そのため 5900(VNC) がインターネット全体に露出 → 外部VNCスキャンbotの接続が
CLOSE_WAIT として滞留 → macOS標準 screensharingd の少ないセッション枠が枯渇 →
whitelist対象の作業Macからの正規VNC接続も受付不能に。
（2026-05-18 の MySQL 3306 接続枯渇障害と同型。今回はpf自体がOFFという、
より根本的な状態だった）

【実施内容】
① 即時復旧: screensharingd 再起動で滞留ソケットをクリア
   sudo launchctl kickstart -k system/com.apple.screensharing
   → 33 CLOSE_WAIT 解消、新pid起動、5900 OPEN・RFBバナー応答を確認。VNC回復。

② pf 再有効化（恒久対策）
   - /etc/pf.anchors/blacklist が完全な自己完結ルールセットであることを確認:
       pass quick from <whitelist>                       … 信頼IPを最優先で常時許可
       block in quick proto tcp from <blacklist>          … 攻撃IPは全ポート遮断
       block in quick proto tcp to any port {22,110,143,445,3306,5900}
       pass  in quick proto tcp to any port {25,80,443,465,587,993,995}
   - whitelist.txt は健全（159.28.108.1作業Mac, 10.0.1.0/24, 127.0.0.0/8,
     221.170.61.15自宅Mac）→ 有効化してもこれらのSSH/VNCは維持される。
   - ロックアウト（自宅機への物理訪問が必要）回避のため、180秒後に pfctl -d する
     自動ロールバックを armed してから有効化:
       sudo pfctl -nf /etc/pf.anchors/blacklist   （PARSE_OK 確認）
       sudo pfctl -E  -f /etc/pf.anchors/blacklist （pf enabled）
   - 別セッションで SSH(22)/VNC(5900) 疎通・新規ログイン成功を実証 →
     ロールバックを解除（pkill, 未発火を確認）。whitelist 4件/blacklist 4326件
     ロード済み、Status: Enabled。

③ 再発防止（起動時自動有効化の恒久化）
   - 根本原因（pf自動起動の欠落）を塞ぐため LaunchDaemon を新規作成:
       /Library/LaunchDaemons/com.norizuki.pf.plist
         Label=com.norizuki.pf / RunAtLoad=true
         ProgramArguments: /sbin/pfctl -E -f /etc/pf.anchors/blacklist
         StandardErrorPath: /var/log/norizuki-pf.log
   - plutil -lint OK、chown root:wheel / chmod 644、launchctl load -w で適用。
     RunAtLoad により即時 pfctl も実行され、pf Enabled を再確認。

【結果・確認】
- VNC 接続可能（5900 OPEN / RFB 003.889）。
- pf Status: Enabled、whitelist/blacklist 適用済み。
- 既存の auth-blacklist デーモン（com.norizuki.auth-blacklist, 認証失敗2回で
  blacklist追加）は稼働中だった。pfがOFFのため遮断が効いていなかっただけで、
  pf有効化により保護チェーン全体が機能する状態に復旧。
- 次回再起動後は com.norizuki.pf により pf が自動有効化される。

【備考・残課題】
- 認証鍵 norizuki_rsa は未配置のままパスワード認証で作業（CLAUDE.md記載どおり）。
- 起動後に pf が確実に有効化されるかは、次回の実再起動時に
  「sudo pfctl -si | head -1」で Status: Enabled を要確認。