三层门闩与一场清白：Tailscale 下 SSH 不通的层层排查、Shield 与 Stealth 的双重门神，与火绒的洗冤录

同一台机器的 22、3389、9119 三个端口，在 tailnet 上表现完全一致——超时。而对照组 Mac 的 22 秒通。一场教科书式的三层排查，从 19:40 挖到 20:34。

一、第一层门闩：Shield mode

tailscale debug prefs 里 "ShieldsUp": true——这个开关会丢弃所有从 tailnet 进入的连接，三个端口表现一致（超时而非拒绝）正是它的签名。关掉并验证：tailscale set --shields-up=false。但云端 agent 复测 22 仍是 8.2 秒空响应而非 0.4 秒的拒绝——门闩后面还有门闩。

二、第二层门闩：网卡类别的静默反转

重启 Tailscale 服务后，Tailscale 网卡的网络类别从 Private 沦为 Public（还卡在「正在识别」，Set-NetConnectionProfile 改不动）。而 Tailscale 自带的 Tailscale-In 放行规则只作用 Domain,Private——网卡一变 Public，规则整体失效，Windows 防火墙按 Public 默认策略静默丢包。修法是一条不依赖类别识别的持久规则：Tailscale-Inbound-CGNAT，Profile Any、只匹配 100.64.0.0/10 与 fd7a 的 IPv6 段、只放行 TCP 22 和 9119。

三、第三层门闩：Stealth 的沉默与火绒的洗冤

最戏剧性的一段是冤案与昭雪。WFP 丢包审计的事件 5152 显示 22 端口的入站被名为 Stealth 的过滤器丢弃——火绒的 hrwfpdrv 内核驱动正在运行、其 config 里 forceattack.BlockFAProt=1（暴破攻击防护）也对得上，嫌疑一度钉死。但在火绒界面里翻遍设置与安全日志：临时黑名单是空的、日志里没有拦截记录。真正的解释朴实得多——Windows 对没有监听者的端口在 Public 网卡上走隐身模式静默丢 SYN（不回 RST），而 22 上根本没有 sshd（OpenSSH.Server=NotPresent）。对照实验一锤定音：PowerShell 在 18082 起监听，Mac 立刻秒通；22 没监听，就超时。火绒清白。

四、终局：装上服务，门自然开

结论回到原点：装上 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 banner；端到端密钥认证自测通过（临时密钥即加即删）。路线 B（tailscale serve 反代 9119，不动 Desktop 后端不踩 exit 78）卡在 tailnet 的 Serve 授权待管理员点头。最终暴露面收窄到 22/9119 只对 tailnet 开放——以太网是 Public 默认阻止，局域网和公网都进不来。这一案的普适教训有三：超时≠被防火墙针对，可能只是没人听门；放行规则要看网卡的类别假设；洗冤和定罪需要同一种证据——对照实验。