Tailscale+headscale 方案 延迟超高

2023-11-29 15:41:38 +08:00
 xuemian

各位大佬，
因为学校疑似屏蔽了 zerotier 流量被迫转 tailscale
我 headscale 节点是凉心云 3M 小水管，
日常流量 0.003M-0.01M 所以不存在压力。
日常 ping headscale 节点大约 20ms 左右，
但是 ping 节点就要 400ms-600ms 非常夸张都能绕地球一圈了。
并且 TCP+UDP 端口全放通也是一样卡。
访问 openwrt 后方的 PVE 更是需要 2000ms - 4000ms

节点 1 是 openwrt 节点 2 是 MacBook 节点 3 是 vivopad

MacBook ping vivopad 的 tailscale 地址 10ms左右.
MacBook ping openwrt 及下面的节点都是以下结果

64 bytes from 10.10.10.100: icmp_seq=0 ttl=63 time=467.293 ms
64 bytes from 10.10.10.100: icmp_seq=1 ttl=63 time=470.979 ms
64 bytes from 10.10.10.100: icmp_seq=2 ttl=63 time=477.461 ms
64 bytes from 10.10.10.100: icmp_seq=3 ttl=63 time=478.616 ms
64 bytes from 10.10.10.100: icmp_seq=4 ttl=63 time=444.896 ms
64 bytes from 10.10.10.100: icmp_seq=5 ttl=63 time=422.704 ms

64 bytes from 100.64.0.1: icmp_seq=689 ttl=64 time=1102.714 ms
64 bytes from 100.64.0.1: icmp_seq=690 ttl=64 time=841.340 ms
64 bytes from 100.64.0.1: icmp_seq=691 ttl=64 time=426.124 ms
64 bytes from 100.64.0.1: icmp_seq=692 ttl=64 time=812.586 ms
64 bytes from 100.64.0.1: icmp_seq=693 ttl=64 time=428.187 ms
64 bytes from 100.64.0.1: icmp_seq=694 ttl=64 time=1748.903 ms
64 bytes from 100.64.0.1: icmp_seq=695 ttl=64 time=1960.977 ms
64 bytes from 100.64.0.1: icmp_seq=696 ttl=64 time=956.289 ms
64 bytes from 100.64.0.1: icmp_seq=697 ttl=64 time=1175.861 ms
64 bytes from 100.64.0.1: icmp_seq=698 ttl=64 time=1097.904 ms
64 bytes from 100.64.0.1: icmp_seq=699 ttl=64 time=3255.409 ms
64 bytes from 100.64.0.1: icmp_seq=700 ttl=64 time=2535.410 ms
64 bytes from 100.64.0.1: icmp_seq=701 ttl=64 time=1531.569 ms
64 bytes from 100.64.0.1: icmp_seq=702 ttl=64 time=660.256 ms
64 bytes from 100.64.0.1: icmp_seq=703 ttl=64 time=1001.957 ms
64 bytes from 100.64.0.1: icmp_seq=704 ttl=64 time=1198.254 ms

到底是啥原因呀？ 是必须自建 derp 吗？

5041 次点击
所在节点    宽带症候群
37 条回复
poisedflw
2023-11-29 15:52:24 +08:00
在你 headscale 机器上再部一套 derp 就行了，如果两个节点间无法直连会走国外节点中转就非常慢。开启 ipv6 后直连的成功率高。
zenghx
2023-11-29 15:57:48 +08:00
tailscale ping xxx 看看走的是哪个 derp 服务器，能不能直连上
Goalonez
2023-11-29 15:59:40 +08:00
Tailscale netcheck 看一下 drep 的延迟，drep 也自建一个
xuemian
2023-11-29 16:00:40 +08:00
@zenghx #2 pong from mbp (100.64.0.2) via DERP(hkg) in 423ms
xuemian
2023-11-29 16:01:24 +08:00
@Goalonez #3 Report:
* UDP: true
* IPv4: yes, 115.198.240.23:35527
* IPv6: no
* MappingVariesByDestIP: false
* HairPinning: false
* PortMapping: UPnP
* Nearest DERP: Tokyo
* DERP latency:
- tok: 116.1ms (Tokyo)
- sfo: 139.4ms (San Francisco)
- lax: 158.9ms (Los Angeles)
- sin: 163.9ms (Singapore)
- den: 173.1ms (Denver)
- sea: 176.9ms (Seattle)
- mia: 200.9ms (Miami)
- ord: 203.3ms (Chicago)
- nyc: 205.5ms (New York City)
- tor: 208.4ms (Toronto)
- dfw: 210.1ms (Dallas)
- hnl: 230.7ms (Honolulu)
- mad: 244ms (Madrid)
- par: 244.9ms (Paris)
- blr: 268ms (Bangalore)
- fra: 296ms (Frankfurt)
- waw: 298.6ms (Warsaw)
- ams: 299.3ms (Amsterdam)
- lhr: 308.3ms (London)
- syd: 322.1ms (Sydney)
- dbi: 357ms (Dubai)
- sao: 382.1ms (São Paulo)
- jnb: 405ms (Johannesburg)
- nai: 411.2ms (Nairobi)
- hkg: (Hong Kong)
OOKAMI
2023-11-29 16:02:52 +08:00
headscale 默认使用的还是官方的 derp 服务器清单，你要降低延迟需要部署自己的 derp 服务器，然后改 ACL 配置里的 derpmap ，将自己的 derp 替换上去。
gps949
2023-11-29 16:06:03 +08:00
你这看起来明显没直连走的 DERP 。建议想办法调整走直连，不到万不得已别自建 DERP
HandSonic
2023-11-29 16:08:36 +08:00
@gps949 为啥别自建 DERP ？
qwvy2g
2023-11-29 16:24:34 +08:00
derp 别人能白嫖。国内节点 vps 很贵，10m 电信也有 300 多一年，还有实名制问题。
apiman
2023-11-29 16:26:12 +08:00
即使自建了 derp ，也不如节点之间直连的速度快，尤其是在节点都有公网 ipv6 的情况下，简直是秒连接。自建 derp ，如果节点不能直连，就通过 derp 中转，这样速度瓶颈转移到了 derp ，比如只有 3M 的良心云
coolcoffee
2023-11-29 16:28:11 +08:00
我自己就是 headscale 和 tailscale 官方控制平面都在用。headscale 不是非必要，tailscale 的官方控制平面国内直连没有任何问题，你只需要国内自建 derper 节点即可。

像 headscale 我是给公司搭建的，因为涉及到设备数量限制和接入企业微信 SSO 登录。

两种无论是在任何地方，都能先通过国内的自建 derper 来快速低延迟中转，当一段存在 NAT 打洞成功就立刻切换成直连了。
coolcoffee
2023-11-29 16:32:12 +08:00
@qwvy2g 不存在白嫖，官方给出的方案是添加--verify-clients 来限制只有自己的网络才能用。
OOKAMI
2023-11-29 16:37:00 +08:00
想白嫖还是可以的，但是要一个个试过去，verify-clients 参数是后面增加的，很多网上的 derp 部署教程没写这个，如果是参考以前教程部署的，那还是能用到，就是得花时间自己试。
xuemian
2023-11-29 16:37:19 +08:00
目前采用凉心云做 DERP 中转 13ms 了

* IPv6: no
* MappingVariesByDestIP:
* HairPinning: false
* PortMapping: UPnP
* Nearest DERP: tencent-cloud-DERP
* DERP latency:
- tencent: 29.7ms (tencent-cloud-DERP)
zenghx
2023-11-29 16:41:15 +08:00
@xuemian ip 漏了
unfurl
2023-11-29 16:41:31 +08:00
我就是用自建的 DERP ，稳得很
gps949
2023-11-29 16:50:08 +08:00
@HandSonic
1 、再怎么说 DERP 也都是中转，总会增加延迟的，所以能想办法搞直连了肯定比走 DERP 强；
2 、自建 DERP 用作中转的话一般来说要么小水管（带宽小）、要么费用贵、要么延迟大（国外流量便宜带宽大的情况下）；

至于有人说别人能白嫖，那倒不会，因为自建 DERP 可以做鉴别仅限自己的节点走它中转的。
rnv
2023-11-29 17:27:09 +08:00
刚好这几天我也在折腾 tailscale ，谈一下自己的理解：

headscale 只是 tailscale 控制台的替代，使用 headscale 不能一定提升你设备间的可连接性和降低延迟。

当你的设备之间互 ping 延迟超高的时候，一般通过 tailscale status 查看都会发现设备间连接是通过 relay 实现的，也就是依赖于 tailscale 官方的 derp 服务器节点，这就说明你设备间打洞不成功。这种情况下就需要你自己部署 derp 节点了。
rnv
2023-11-29 17:31:15 +08:00
@gps949 请问无法直连的设备要调整到可以直连一般从哪些方面入手？

我家里有公网 IP ，路由器 DMZ 给了一台主机 A ，局域网里还有其他主机 B ，C ，D 等。我用工具查看主机 A 的 Nat Type 是 FullCone ，其他主机 B 是 Symmetric 。在其他网络的另一台设备 Z ，Nat Type 是 Symmetric ，可以跟 A 直连，但跟 B 只能中转。
shaldon
2023-11-29 17:34:01 +08:00
在控制台的 access controls 加上端口随机化试试
"randomizeClientPort": true,

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/996258

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX