NAT 放在 VPN 服务器还是路由器？两种做法都可行
客户端上的默认路由并不构成出口。比较在 VPN 服务器上做转换与把地址池带到路由器两种方案，并选定一个归属。
在笔记本上把连接标记为默认路由，是所有人都记得的一步，也正是对网关毫无影响的一步。客户端现在把互联网请求送进隧道；它们能否离开这栋楼，取决于转发、一个转换点，以及一条能回到客户端私有地址的回程路径。两种安排都能提供这三样，但它们把工作放在不同位置，而且在没有人负责回程方向时，两者都会以同样无声的方式失败。在两者之间做选择，问题是应该由谁看到客户端地址池。
误解：客户端路由就构成了出口
强制隧道是客户端侧的策略：它决定流量走 VPN 适配器而不是物理适配器。微软的 VPN 路由文档 描述了这种分流与强制行为，而那是关于客户端路由表的陈述，不是关于服务器转发规则的陈述。从客户端看，隧道就是互联网所在之处；从网关看，一个数据包来自 一个上游谁也没听说过的地址。任何一侧单独看都没有配置错误，这正是笔记本前的人会把故障看成服务器坏了的原因。
这种不匹配正是本文其余部分要解决的全部问题。必须有东西让客户端的私有地址变得可回程，而选择在于放在哪里。
先画出回程路径
在动任何设置之前，用真实地址把路径写下来，并在上面标出两个候选转换点。本实验使用 10.70.0.0/24 的 VPN 地址池，一个客户端位于 10.70.0.37，服务器 LAN 地址为 172.16.40.10，路由器位于 172.16.40.1，公网出口为 203.0.113.40。
client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
(translate here?) (or here?)已经在浏览互联网的服务器，只能证明它自己的路径。代表客户端转发的数据包是另一个决定，由同一台机器上的转发策略作出，而它通常正是缺失的那一环。在图上标出三个决策点，能让讨论每次只聚焦其中一个。
方案 A：在 VPN 服务器上转换
在这里，服务器在把数据包交给路由器之前，先把客户端的源地址转换成自己的 LAN 地址，路由器则在出站时套用它平常的转换。回程时，路由器的映射还原服务器地址，服务器的映射还原客户端地址。两段有状态转换串联是正常且可行的，前提是两者都被记录下来；路由器永远不需要通往地址池的路由，这正是这种安排的吸引力。
Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix用这些读取来判断服务器已经有什么，而不是假定 NAT 已经就位。从博客抄来的 Linux masquerade 规则不是 Windows 配置，而为 VPN 侦听器放开主机防火墙，与允许把客户端请求继续转发并不是同一条策略。先从服务器自己的管理界面确认它的转发角色，再单独看转换，因为这两者常常由部署的不同部分分别启用。
方案 B：把地址池带到路由器
在第二种安排里，服务器转发客户端的真实源地址，由路由器来完成转换。这让客户端地址池在边缘仍然可见；如果流量策略、日志或检查都落在路由器上，这会有帮助。这也意味着路由器需要一条指向 172.16.40.10 的 10.70.0.0/24 回程路由，还需要一条真正包含该前缀的互联网策略；为 LAN 子网写下的规则，不会悄悄延伸到地址池。
当边缘设备就是预期的策略归属，并且能在自己的路由与转换表中接受另一个前缀时，选这一种。当地址池应当在上游保持不可见，而路由器不由同一团队管理时，选服务器侧转换。客户端上没有任何复选框会暗示其中任何一种，两者在总体上也没有哪个更安全；它们只是把可见性与维护放在不同位置。
把 DNS、IPv6 与验收讲清楚
地址转换并不能修复名称解析。客户端可能使用随 VPN 配置文件下发的解析器、用于特定命名空间的私有解析器，或经过批准的公共解析器，而在该策略下不可达的解析器，会在路由打通之后继续失败。请分别测试名称与地址，好让两种故障永远不会被合并成一份报告。
IPv6 在设计里需要单独一段。可用的 IPv4 转换并不能说明 IPv6 客户端是否有路由、是否有合法的公网源地址，或在隧道断开时是否被策略阻断。把这一点略去不写，意味着半数客户端在悄悄绕过网关，而另一半正常工作。
验收时，请跟踪一条被允许的客户端请求及其应答穿过两个边界，并记下那一刻每个边界应当看到的地址。正是这份记录，让下一次地址池变更变成五分钟的修改，而不是一场关于谁拥有那条缺失回程路由的争论。请把记录放在客户端配置文件旁边，而不是放进工单里，因为下一位工程师最先找到的会是配置文件。