@brucexu_eth: 直呼 Tailscale 牛逼！ 现在我所有的服务器和设备都连到了 Tailscale，并且开启了 Tailscale SSH。之后我基本没再折腾过 Private Key，也不用到处同步 SSH key，每次直接 ssh root@ta…

直呼 Tailscale 牛逼！ 现在我所有的服务器和设备都连到了 Tailscale，并且开启了 Tailscale SSH。之后我基本没再折腾过 Private Key，也不用到处同步 SSH key，每次直接 ssh root@tailscale-ip 就可以登录。 部署在某台服务器上的 Hermes，也可以通过 Tailscale 跨服务器做监控、服务部署和日常运维，非常方便。 但我最近意识到这里有一个风险：如果某个 Hermes 要给别人共用，或者部署在公网服务器上，未来真的被攻破了，在原来 allow-all 的网络策略下，攻击者就可能继续横向访问我其他的服务器，甚至是正在使用的个人电脑。 刚刚花了一点时间配置 Tailscale Access Control，就把这个问题解决了。 做法很直接：先用 tag 把设备分成 personal 和 public-server，然后分别配置网络 Grants 和 Tailscale SSH Policy。 我这次直接给 Hermes 创建了一个临时的 scoped OAuth client，让它读取并备份原来的 policy、生成新规则、调用 Tailscale API 验证，然后提交配置，最后再从两个方向做真实连接测试。如果手动配置也不麻烦，核心就是写清楚两个 tag 之间谁可以主动访问谁。 我目前的规则是： - personal 设备之间可以相互连接和 SSH - personal 可以连接 public server - public server 不能反向连接 personal - public server 之间也不能横向连接 过程中还踩了一个坑：Tailscale 的网络 Grants 和 Tailscale SSH 是两层权限。网络已经通了，不代表 SSH 一定能登录，两边都需要配置。 这样一来，我内网服务器上部署的 Hermes 仍然可以作为管理节点和跳板机，控制其他服务器；但部署在公网的 Hermes 即使出现问题，影响范围也会被限制在外面，不会通过 Tailnet 继续横向扩散。 太牛逼了。以前这种内网管理、身份认证和权限隔离，通常都是大公司才会认真搭建的基础设施。现在 Tailscale 直接把它下放到了个人，而且免费就能用。 没用的赶紧用起来！