漫游中的 VPN 客户端能为办公室提供服务吗？

你的办公笔记本可以从家里拨入，并仍然提供办公室需要的服务，但这只有在三个独立决定同时成立时才行。隧道是传输，内部地址是目的地，而策略决定谁可以敲门。把其中任何一个当成完整答案，就会产生熟悉的抱怨：主机能回应 ping，但应用始终连不上。角色并不相同，差别恰恰在于设计工作所在之处。

拨入方向并不说明服务方向

当客户端启动隧道时，它打开了一条路径，一旦存在，两个方向都能使用。新的连接能否从中心进入并到达该客户端，这是网关策略的问题，而不是拨入者的属性。例如在有路由的 OpenVPN 中心上，服务器需要一条通往客户端内部地址的路由，以及允许对等关系的转发。

设想一个轮询漫游笔记本上代理的库存系统，或者一位需要从家里工作站访问测试 API 的开发者。两者都希望由办公室一侧发起对话，这与通常的客户端到服务器模式相反。

托管式远程访问产品在这一点上各不相同，这种差异并不是缺陷。有些托管式 VPN 故意阻止向已连接客户端发起的非请求连接，因为它们的模型是客户端到资源，而不是资源到客户端。在向同事承诺他的笔记本可以充当服务器之前，请阅读产品文档化的架构。

先确认回程路径，再开放端口

这条路径有三个部分：网关上指向客户端内部地址的路由、允许特定调用方的策略，以及目标上正在监听的服务器。每个部分失败的方式都不同，所以“VPN 已连接”几乎说明不了什么。

好消息是，内部路径不需要在客户端家用路由器上做端口转发。把服务发布在隧道地址而不是家庭 WAN 地址，意义正在于此，因为后者的暴露面和 NAT 规则会完全不同。家用路由器也可能拒绝对来自办公室的连接做 hairpin，因此 WAN 路径会因与 VPN 无关的原因失败。把流量保持在隧道内部，可以同时避开这两个问题。

也要检查目标一侧。只绑定到 127.0.0.1 的服务无法接受从隧道接口到达的连接，无论网关路由多么正确。只允许本地子网访问该端口的主机防火墙规则同样会丢弃办公室流量，而该规则独立于其上的 VPN 策略。

名称和地址是设计决策

隧道内的地址不会自动成为名称。由你控制的私有 DNS 记录，比指望某种发现协议穿越隧道要清楚得多，因为链路本地组播名称解析停留在本地网段，不会变成跨子网 DNS。

地址稳定性同样重要。如果 VPN 客户端从租期很短的地址池中获取地址，笔记本的内部地址会在不同会话之间变化，建立在其上的每个书签、防火墙范围和监控检查都会悄悄失效。请使用地址保留，或文档化的动态更新路径。

与 VPN 身份的所有者商定名称，让记录、地址分配和访问策略一起变更，而不是分成三张工单。

测试服务，而不是成员资格

在目标上确认谁在监听、监听哪个地址，然后确认网关对回程路径的看法：

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

现在从办公室一侧用真实请求而不是回显来测试。对服务执行 curl 成功，可以一次性证明路由、策略和监听者；而 ping 成功只能证明 ICMP 被放行。如果请求失败，请沿着这三个部分往回查，而不是扩大防火墙并寄希望于运气。

可用性属于同一场讨论。笔记本会休眠、在网络之间漫游，并在一天结束时断开连接。必须随时响应的服务属于常开主机；而尽力而为的服务可以留在客户端上，并把这个限制写清楚。

有意识地发布资源，给出名称、允许调用方清单和所有者，远程设备就会成为受支持的服务，而不是意外的服务器。