@
hsj1992 这个问题我前两天刚好在调试,阅读了一下 NatTypeTester 的源码,正好可以解答。我不清楚 PaoPaoGateway 里用的 Clash 是 Premium 核心还是 Meta 核心。Premium 核心似乎是不支持 Endpoint-Independent NAT 的(存疑),但是 Meta 核心在 tun 小节的配置里有一条 `endpoint-independent-nat: true` 设置之后就可以做到 mapping/filtering 都变成 EndpointIndependent 。
在上面的设置的基础上,从你的描述中 “终端把 IPV4 网关地址 手动设置成旁路网关 IP 地址....” 这一段可以看出,你用的核心应该已经给你做好了 EndpointIndependentNat (应该?),所以上面的内容可以忽略(打的时候没看到这一句,但是懒得删了,希望对后人有帮助)。这可能和 STUN 协议的原理有关,STUN 检测 filtering 行为的原理可以简单描述为:
1. 你向 stun server (记为 A ) 说 “请返回我现在访问你用的 IP:Port”
2. stun server 返回以下内容:
1. 你当前访问 stun server 的 IP:Port ,记为 Self
2. 给你发这条回复的 stun server 的 IP:Port ,即上面的 A
3. 另一个 stun server 的 IP:Port ,记为 B
3. 你向同一个 stun server A 发起一个请求,说 “请 改变 IP 和端口 向我发起一条请求”
4. stun server B 会向你的 Self 发送一个 stun 包,如果你能接收到,那么说明 filtering 行为是 EndpointIndependent
从这个过程中可以看出,Clash 会在第 4 步的时候用一个“之前你没有主动发起连接”的 IP 向你回包。但是我在测试的时候发现:tun 使用的 stack 不同( gvisor 或者 system ),会有不同的回包 IP 行为,其中使用 system stack 存在 bug 。所以如果你的 PaoPaoGateway 里的 tun 用的是 system stack ,考虑切换到 gvisor 并配合 Meta 核心的 `endpoint-independent-nat: true` 再做尝试。
此外,还可以把 ROS 里的有一条 “drop invalids” 的规则里的 In. Interface. List 改成 !LAN ,我看前人的一些教程一上手就把这个规则改了,但我没测试过这个防火墙规则是否有影响,你也可以试一试。
这个问题其实非常复杂,我自己调试的时候费了不少功夫,最后还修改了 Clash Meta 核心的代码才实现了 filtering/mapping 都是 EndpointIndependent 。如果你按照上述的方法不能得到预期的结果,可以加个联系方式,我有空的时候可以帮你看看,文字我觉得很难说清楚这个过程(主要是我没有用过 PaoPaoGateway 不知道里面的细节)。