imKiva 最近的时间轴更新
imKiva

imKiva

V2EX 第 336871 号会员,加入于 2018-07-29 07:36:09 +08:00
今日活跃度排名 26200
imKiva 最近回复了
这个在哪里能办?我打 10000 和客户经理都说还没有这个套餐
277 天前
回复了 rabbbit 创建的主题 C++ C++ 如何在函数中获取作为参数的数组的长度?
template <typename T, size_t N>
size_t length(const T (&array) [N]) {
return N;
}
@hsj1992 我后来找了一些常用 stun server 的服务器地址,把他们都加入静态路由,具体是下面几个

# STUN server
# stunserver.stunprotocol.org
route 3.132.228.249/32 via "utun";
route 3.135.212.85/32 via "utun"; # STUN OtherAddress
# stun.hot-chilli.net
route 49.12.125.53/32 via "utun";
route 49.12.125.24/32 via "utun"; # STUN OtherAddress
# stun.syncthing.net
route 139.59.84.212/32 via "utun";
route 139.59.49.16/32 via "utun"; # STUN OtherAddress
route 198.211.120.59/32 via "utun";
route 188.166.128.84/32 via "utun"; # STUN OtherAddress
# stun.fitauto.ru
route 195.208.107.138/32 via "utun";
route 195.208.107.140/32 via "utun"; # STUN OtherAddress
# stun.l.google.com
route 108.177.125.127/32 via "utun";
@hsj1992
> 要使用 tg 还需要给它的 CIDR 网段写静态路由指向旁路网关一样,NAT 类型探测也会有设备直接指向 IP 而没经过 fakeip DNS 的场景?

是的。我上面的最近一条回复里也提到了:是静态路由配置不全的问题
@imKiva 不好意思,没看到最后一部分,手动忽略吧....
而且最好给出你的编译参数.....
出现这个错误多半和你用的 shell 有关。顺便建议把这一行和周围相关的代码贴出来,方便其他人分析问题:

/Users/itisummer/Downloads/OpenJDK12/build/.configure-support/generated-configure.sh: line 84
@hsj1992 tproxy 我就不清楚了,我自己没有使用 tproxy 的动机。你可以在客户端上开个 wireshark 抓包一下用 NatTypeTester 之类软件测试过程中的 stun 包。用经过 clash 和不经过 clash 的 stun server 的两种流量互相对比一下,看看哪里不一样。
@hsj1992

> 这个情况是设置因为静态路由导致的么?

99% 不是。我也使用静态路由的方式,客户端的网关均指向 ROS ,但在我的配置中得不到 FullCone NAT 的原因有两个:
1. 我的静态路由配置不完全:因为我的 DNS 对 stun server 始终返回真实 IP ,在上面的第 3 步的时候会变成直连从而测出未定义行为。
2. Clash Meta 的 tun 入站对 `conn.LocalAddr()` 的赋值存在 bug ,在我修复这个问题后,成功测出 FullCone Nat
@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 不知道里面的细节)。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1422 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 15ms · UTC 23:50 · PVG 07:50 · LAX 16:50 · JFK 19:50
Developed with CodeLauncher
♥ Do have faith in what you're doing.