两台设备、同一个 Wi-Fi、不同的 VPN 出口：什么在决定

同一台家用路由器上的两台笔记本可以经由不同的 VPN 出口访问互联网，而共享的 Wi-Fi 对此没有任何决定作用。决定结果的是隧道在哪里运行，以及哪条策略为每个请求选择路径。相反的说法同样常见，也同样错误：两台配置了不同配置文件的设备，并不会自动产生两个公网地址。这两种误解都源于把一个地址当成了三个。

三个地址，只有一个真正离开

笔记本有一个在本地网段中标识自己的家庭局域网地址，它还可能在 VPN 内部被分配一个隧道地址。这两者对远端服务都不可见。远端服务记录的，是一路经过各种转换之后，最终把数据包发出去的那台设备的公网出口地址。

RFC 3022 划出了解释此处多数困惑的那条界线。传统 NAT 把内部地址映射为公网地址，而端口转换让许多内部地址可以同时共用一个公网地址。只有一个公网地址、多台设备的家庭属于后一种情况，这几乎是各地默认的形态。

要数公网地址，而不是配置文件。两个客户端即使隧道地址不同，只要出口策略相同，产生的仍是一个被观测到的地址；反过来，单个客户端若出口走了不同路由，也可能产生另一个地址。这一次比较就是全部检验。其余一切，都是对远端一侧的假设。

什么才算两个真正不同的出口

当接入互联网之前的最后一台设备为该流量使用另一个公网地址时，出口才是不同的。这既可能因为 VPN 在另一处终结，也可能因为出口池分配了不同地址，还可能因为服务商让请求走了另一条出口。三者都是远端做出的策略决定，从家用路由器上都看不到。

两台各自运行客户端、使用同一配置文件的设备，通常会落在同一个池里，并在某次会话中经常拿到同一个出口。这不是故障，而是共享池的正常行为。要拿到不同的出口，通常意味着向服务商申请不同的分配，而不是把客户端配置两遍。

在以某个保证为前提前，请先读服务条款中关于并发连接的规定。第二次登录是允许连接，而不是承诺一个独占地址。条款若未明说，就去问服务商，不要自行假设。这个答案对设计的影响，超过任何一项客户端设置。

为什么不同的配置文件不等于不同的出口

配置文件描述的是如何抵达 VPN 以及如何认证，它几乎不涉及之后发生的事。出口由远端选择，路由、地址池和转换策略都在那一侧。把配置复制到第二台机器上，复制的是客户端配置，而不是服务端的决定。

反过来同样成立。当路由与转换策略如此搭建时，一台 VPN 服务器可以呈现不止一个公网出口；而彼此分开的服务器，也可能共同喂给同一个下游出口。所以配置里服务器名称的数量，说明不了地址的数量。这正是配置文件不是寻找这个答案的正确位置的原因。

唯一可靠的答案，来自通过你打算使用的那套安排所发出的请求。其余都是推断。

把分隔放在哪里

路由器上的隧道覆盖整个家庭，方便，并且让身后的每台设备恰好共用一个出口。每台设备各装客户端，可以做到按设备控制，但要求每台设备都完成配置并一直保持。具备策略能力的路由器位于中间，按设备选路，而它只有在重连与 DHCP 变化之间仍能可靠识别设备时才成立。

在路由器上再建一个私有 DHCP 租约，并不等于再造一个公网地址。它改变的是本地视角，出口并未被动到。分隔存在于出口策略里，无论这条策略放在路由器上，还是放在 VPN 服务端。

无论选哪种形态，都要把归属写清楚：谁负责配置设备，谁负责轮换它的凭据，以及谁在它不再走既定路径时发现问题。

检查你实际拿到的出口

要在真正重要的应用里做检查，并在两台设备上比较同一地址族。一边是 IPv4 结果、另一边是 IPv6 结果，对任何一边都说明不了什么。随后在重连之后再做一次，因为池的分配可能在不同会话之间变化。

要在隧道策略内部的终端里执行，而不是在一台绕开策略的设备上执行。用错主机，只会得到自信的错误答案。

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

如果两台设备打印出同一个 IPv4 地址，那么无论开了几条隧道，它们共用一个出口。接下来要决定隧道失效时会发生什么：回落到直连路径的客户端会把两台设备都带回家庭地址，分隔随之消失，而且不会报错。在把这套安排称作两个出口之前，先确认这种回落行为；同时记住，地址不同是网络结果，而不是两个匿名身份。