pfSense OpenVPN：到达另一台路由器后面的网络

你的笔记本通过 VPN 到达 pfSense 的局域网，却仍然无法访问更靠里两跳的服务，差别就在于每个所有者各有一条路由决策。一个数据包要完成往返，三台设备必须达成一致：客户端、防火墙，以及真正拥有目标网络的那台路由器。漏掉其中任何一个，症状看起来都一样。

在改动任何规则之前，先让一个数据包走完这三个决策，因为每个所有者的控制方式和故障模式都不同。

一个数据包，三个路由决策

客户端决定目标是否属于隧道，而它只能依据自己知道的信息来判断：被推送的路由、本地路由，或者一条已经覆盖一切的默认路由。pfSense 决定数据包下一站发往哪里，对于另一台路由器后面的网络，这意味着经由正确接口上可达的网关走一条静态路由。下游路由器决定自己是否知道返回 VPN 地址池的路径，如果不知道，回应就会被丢弃或发往毫无用处的地方。每个决策都独立于另外两个。

其中任何一个失败，用户的报告都相同。这就是为什么排查顺序比工具更重要。

给客户端一个前缀，而不是猜测

在 IPv4 隧道网络大于 /30 的 pfSense SSL/TLS 服务器上，IPv4 Local network(s) 字段会在客户端连接时向其分发路由。请在那里添加下游前缀，而不是指望客户端自己编一个。然后在连接后读取客户端的真实路由表，因为带 route-nopull 的配置文件或路由过滤器可能忽略服务器发送的内容。服务器可能完全正确，而客户端什么也没装。

其他服务器模式和拓扑有不同的限制，按客户端或按连接的策略也可能改变某个客户端实际收到什么。要在重要的那个客户端上验证，而不是在你碰巧先测试的那个上。

把 pfSense 指向内部路由器

pfSense 中的静态路由需要一个已定义且可达的网关，而为该网关选择的接口必须真正能到达它，正如 Netgate 的静态路由指南 所述。在一个示例布局中，传输链路在防火墙上为 192.168.77.1，在内部路由器上为 192.168.77.2，服务网络位于其后的 172.16.30.0/25。随后路由指定的是前缀和下一跳，而不是服务地址。把远端网络中的地址当作网关，是构造一条看起来正确却哪儿也不转发的路由的常见做法。

给接口起个名字并不能描述它后面的网络。静态路由才是那份描述。

远端必须知道地址池

下游路由器需要一条返回地址池的路由，本例中是经 192.168.77.1 到达 10.55.0.0/24，除非默认路由或动态协议已经提供了。服务主机自己的网关必须指向那台路由器，当该路由器是它的默认网关时通常成立，而手动配置主机时则不成立。防火墙上的策略路由也可能对特定流量覆盖路由表，所以在断定路由有误之前，先检查是否有规则选择了另一个网关。

这种设计不需要地址转换，让客户端的源地址保持可见，下游网络就能应用自己的策略。

验收时，让一个新请求依次经过隧道入口、防火墙的内部出口，以及来自目标端的回应。如果反而有意使用地址转换，请记录下游网络看到的源地址，以及回应预期如何返回。

把三方的方案与获批的应用一起保存，这样下一位管理员可以重建路径，而不是重新摸索一遍。