三つの錠前と一回の放免：Tailscale 下で SSH が届かない事件の階層調査、Shield と Stealth の二柱の門神、そして Huorong の白状書

同一機械の 22、3389、9119 の三ポートが、tailnet の上で完全に同じ振る舞いをした——超時。対照の Mac の 22 は一瞬で通る。教科書的な三層調査が、19:40 から 20:34 まで走った。

一、第一の錠前：Shield モード

tailscale debug prefs は "ShieldsUp": true を読んだ——このスイッチは tailnet から入ってくるすべての接続を棄てる。三ポートの挙動が完全に一致したこと（拒否ではなく超時）は、まさにその署名である。切って検証する。tailscale set --shields-up=false。だがクラウド側の再測では、22 は 0.4 秒の拒否ではなく 8.2 秒の空応答のまま——錠前の奥に、また錠前があった。

二、第二の錠前：NIC クラスの静かな反転

Tailscale サービスを再起動すると、Tailscale アダプタのネットワーククラスは Private から Public へ落ちた（「識別中」に据わり、Set-NetConnectionProfile でも動かない）。そして内蔵の Tailscale-In 許可規則は Domain,Private にしか作用しない——アダプタが Public に変わった瞬間、規則は丸ごと失効し、Windows ファイアウォールは Public の既定方針で静かにパケットを棄てる。治療は、クラス検出に依存しない恒久規則の一枚だった。Tailscale-Inbound-CGNAT。Profile Any、100.64.0.0/10 と fd7a の IPv6 範囲のみに一致、TCP 22 と 9119 のみを許可。

三、第三の錠前：Stealth の沈黙と、Huorong の白状書

もっとも劇的な一段は、冤罪とその雪辱である。WFP の棄包監査のイベント 5152 は、22 番への入站 TCP が Stealth と名乗るフィルタに棄てられたと示した——火絨（Huorong）の hrwfpdrv カーネルドライバは走っており、config の forceattack.BlockFAProt=1（暴破攻撃防護）も理論に合致し、容疑は釘付けに見えた。だが Huorong 自身の界面で設定と安全ログを掘り返すと、別の物語が出てきた。臨時のブラックリストは空、遮断の記録は皆無。真の説明は素朴である。Windows は、Public のアダプタ上で、待受のいないポートへの SYN を静かに棄てる（stealth モード。RST は返さない）、そして 22 にはそもそも sshd が一人もいなかった——OpenSSH.Server は NotPresent。対照実験がとどめを刺した。PowerShell で 18082 に待受を立てれば、Mac は即座に通る。22 に待受がなければ、超時になる。Huorong は白である。

四、終局：サービスを導入すれば、扉は開く

結論は原点に戻った。sshd を導入すれば、通る。Windows Update のオプション機能は十数分で頓挫し、winget が OpenSSH 10.0.0.0 を導入した。sshd は自動起動に設定され、0.0.0.0:22 で待受ける。公開鍵は C:\ProgramData\ssh\administrators_authorized_keys へ書かれた（管理者アカウントは ~/.ssh ではなくこのファイルを使う必要がある。ACL は SYSTEM と Administrators のみ）。Mac からの実接続は SSH-2.0 のバナーを読み、端から端までの鍵認証は自己試験を通過した（臨時鍵は加えてすぐ消した）。経路 B（tailscale serve が 9119 を反代し、Desktop のバックエンドに触れず exit 78 も踏まない）は、tailnet の Serve 授権待ちである。最終の露出は 22/9119 を tailnet だけに絞った——イーサネットは Public で既定拒否のまま、LAN も公網も入ってこない。この事件の普遍の教訓は三つ。超時は、防火壁があなたを狙っている証拠ではない——誰も扉の内にいないだけかもしれない。許可規則は、そのアダプタのクラスの仮定と照合せよ。放免と断罪は、同じ種類の証拠を要する——対照実験である。