sshuttle 与完整 VPN 对比：它的方式究竟覆盖什么

sshuttle 只承载其转发方式支持的内容：先检查 TCP、DNS 与 UDP 的覆盖范围、所需的本地权限以及远端助手。

选择 sshuttle，往往是因为 SSH 本来就能用、密码学看起来也熟悉，而这个理由恰好跳过了唯一决定它是否适用的那个问题。哪些数据包会离开本机，对端由哪个账户承载它们，以及工具需要多少本地权限。这三个答案随转发方式而变，所以对某个应用可行的配置，换到下一个应用可能悄然失效。下面的分析从应用真正需要的协议开始。

从应用真正需要的协议开始

sshuttle 2.0 的协议支持取决于你选择的方式。Linux 的 NAT 与 nft 方式处理 TCP 和 DNS，TPROXY 则补上通用 UDP。每个平台和每种方式都有自己的边界，而 macOS 完全通过另一种机制来拦截。在做出任何选择之前，先记录已安装的版本、所选的方式以及应用需要的协议。

因此，一条能成功的 TCP 请求，对 UDP 应用或每一次 DNS 查询几乎没有证明力。sshuttle 还把 TCP 当作流来处理，而不是为整个 IP 数据包建立隧道，所以从传统 VPN 借来的吞吐结论在这里并不成立。请把你实际运行的机制与你实际拥有的负载作比较。

ApproachWhat it carriesWhat it needs locally
SSH local forwardOne explicitly named TCP destinationNothing beyond the SSH client
sshuttle, nft or nat methodTCP and DNS to the routed prefixesRoot or sudo for firewall rules
sshuttle, tproxy methodTCP, DNS and general UDPRoot or sudo, and kernel support
IP VPNRouted IP traffic in a tunnelA client with the required privileges

客户端在本地需要什么

文档中的客户端方案需要 root 或 sudo，因为它安装的是本地拦截规则，而不是创建隧道接口。仅仅这一条就改变了安全叙事：拥有该权限的进程可以改道整台机器的流量，而不只是一个应用。请把该权限当作设计的一部分，而不是安装细节。

确认工具安装了哪些规则，以及它退出时这些规则会消失。一次崩溃的会话若留下拦截规则，可能在运维者以为连接已经断开很久之后仍把流量送进黑洞，而症状看起来像网络故障，而不是残留规则。

sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route

第一条命令是典型调用的形态，带上你真正需要的前缀。第二条显示工具安装了什么，第三条确认没有出现隧道接口，这正是该设计预期得到的结果。

远端运行什么

远端是一个获授权的 SSH 账户，加上一个兼容的 Python 助手环境。在受限 shell 下登录成功，并不会自动获得运行该助手的权限；能运行该助手的账户，也不会自动抵达每一个目标服务。这两件事实都应写进访问申请，而不是故障排查记录里。

保护好主机身份校验与账户认证。为了让首次连接成功而接受未知主机密钥，等于取消了“对端就是你想要的那台机器”的检查，而这一点在这里比单一用途的转发更重要。

把远端账户限制在工作流确实需要的服务上，并与主机运维方商定这个范围。他们属于信任关系的一部分，客户端设置改变不了这一点。

信任边界在哪里

通过 SSH 转发私有 API 连接，并不等于授权每一次 API 操作。应用层 TLS 与应用登录依然生效，工具也无法让一个未认证的服务变安全。从远端主机再跳一步，也不自动等同于 SSH 通道所在的那个受保护网段，因为第二段连接遵循的是远端主机自己的策略。

把边界写成一句话：发往这些前缀的流量，经由那台主机上的这个账户出去。如果这句话需要一整段例外，说明设计做得比文档宣称的更多，值得在进入生产之前再看一眼。

按协议逐一验证，然后再选工具

用无害请求测试每一个所需协议，包括解析器路径以及应用所用的地址族。把断开也纳入测试，这样应用被允许的失败行为会变成已知结果，而不是事故中的意外。一段在运行期间正确转发的会话，说明不了它断开之后会发生什么。

对几个明确点名的服务，普通的本地转发更容易拥有、也更容易审计。对与其方式相称的应用流量，sshuttle 提供了合理的中间地带。当需求是广域 IP 连通性时，VPN 设计才是诚实的答案；选择取决于覆盖范围与运维责任，而不是加密算法的排名。

相关文章