SSH 跳板机还是直连 VPN：该适用哪条策略

VPN 用户能否不经跳板机直达服务器，本质上是披着网络外衣的策略问题。如果跳板机承担的是一项必需的控制，那么接入 VPN 就必须经过它，而不是绕过它。如果跳板机只是把过去不可达的网段桥接起来，那么一条受限的直连路径可能是诚实的替代方案。请按顺序完成下面的核查，在第一个不通过的检查处停下，因为那个答案将决定其余的一切。

核查跳板机实际控制了什么

从当下的证据入手，而不是设计文档里的示意图。查看目标的 SSH 配置与包过滤：如果入站 22 端口只接受跳板机地址，那么跳板机就是被强制执行的控制。如果同一端口接受整个 VPN 地址池的连接，那么跳板机只是便利，真正的强制在别处。工单历史通常能确认两者中哪一个先出现。

用一句话说明跳板机提供的控制是什么：目标限制、第二道认证、会话记录，还是事件期间的运营可见性。这句话正是替代策略必须保留下来的东西。

核查目标能否区分两条路径

源地址规则只有在两条路径以不同源地址抵达时才有效。若 VPN 网关对通往服务器子网的流量做了地址伪装，这种差异就被抹平，此后所有到 22 端口的连接看起来都来自网关。这项核查在目标本机进行，只需片刻：列出已建立的 SSH 会话，逐个读取对端地址。

当两条路径塌缩成同一个地址时，区分必须放到更早的一层，即由 VPN 允许下发的目标网段和网关自身的过滤规则来完成。此时在目标上加一条规则，只会制造边界的错觉，并不会改变真正抵达的流量。

核查每份日志究竟记录了什么

三种日志描述三种不同的事件，谁也替代不了谁。VPN 的连接记录说明某个身份进入了网络范围。跳板机的转发记录说明有一条 TCP 通道从它出发去往某个目标与端口。目标的认证日志说明某个账号通过 SSH 登录了。把它们放在一起读，才能还原时间线；只读一种，只能得到猜测。

这些记录都不包含客户端与目标之间加密会话内部发生了什么。如果要求命令级审计，就需要专门部署一套录制机制，并配有自己的数据处理规则。指望从跳板机日志里得到这些，正是审计缺口一直隐藏到出事才被发现的原因。

核查策略真正在哪一层执行

像 ProxyJump 这样的客户端设置只是一个请求，不是限制。只要目标可达，OpenSSH 就会乐意建立直连，因此笔记本上的配置文件描述的是意图，真正决定结果的是防火墙。强制执行属于 VPN 网关的允许目标以及目标自身的访问规则，这两者用户都无法修改。同时还要审计替代路径：第二块网卡、公网监听、mesh 覆盖网络或更早的站点间隧道，每一种都可能让刚关掉的捷径重新打开。

仍要配置 ProxyJump，因为它让获批的路线成为最省事的那条，也避免日常工作不断制造例外。但在信任它之前，请确认客户端实际解析出的结果。

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

用一次有意的直连尝试来验证

从未被测试过的策略只是愿望。从接入 VPN 的客户端出发，先尝试那条现在应当被拒绝的路径，再尝试获批的路径，并保留两次结果。被拒绝的那次尝试，就是变更已生效的证据。

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

干净的结果是：到目标地址的直连被拒绝或超时，随后经跳板机登录成功，且目标侧留下一条认证记录，写明被允许的来源。除此之外的任何情况都说明边界仍然有漏洞，无论文档怎么写。记录日期、改动的规则和这两个结果，然后 为这条应急通道指定负责人和有效期 以免紧急访问悄悄变成日常路线。