各位大佬,
因为学校疑似屏蔽了 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 吗?
1
poisedflw 358 天前
在你 headscale 机器上再部一套 derp 就行了,如果两个节点间无法直连会走国外节点中转就非常慢。开启 ipv6 后直连的成功率高。
|
2
zenghx 358 天前
tailscale ping xxx 看看走的是哪个 derp 服务器,能不能直连上
|
3
Goalonez 358 天前
Tailscale netcheck 看一下 drep 的延迟,drep 也自建一个
|
5
xuemian OP @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) |
6
OOKAMI 358 天前
headscale 默认使用的还是官方的 derp 服务器清单,你要降低延迟需要部署自己的 derp 服务器,然后改 ACL 配置里的 derpmap ,将自己的 derp 替换上去。
|
7
gps949 358 天前
你这看起来明显没直连走的 DERP 。建议想办法调整走直连,不到万不得已别自建 DERP
|
9
qwvy2g 358 天前
derp 别人能白嫖。国内节点 vps 很贵,10m 电信也有 300 多一年,还有实名制问题。
|
10
apiman 358 天前
即使自建了 derp ,也不如节点之间直连的速度快,尤其是在节点都有公网 ipv6 的情况下,简直是秒连接。自建 derp ,如果节点不能直连,就通过 derp 中转,这样速度瓶颈转移到了 derp ,比如只有 3M 的良心云
|
11
coolcoffee 358 天前
我自己就是 headscale 和 tailscale 官方控制平面都在用。headscale 不是非必要,tailscale 的官方控制平面国内直连没有任何问题,你只需要国内自建 derper 节点即可。
像 headscale 我是给公司搭建的,因为涉及到设备数量限制和接入企业微信 SSO 登录。 两种无论是在任何地方,都能先通过国内的自建 derper 来快速低延迟中转,当一段存在 NAT 打洞成功就立刻切换成直连了。 |
12
coolcoffee 358 天前
@qwvy2g 不存在白嫖,官方给出的方案是添加--verify-clients 来限制只有自己的网络才能用。
|
13
OOKAMI 358 天前
想白嫖还是可以的,但是要一个个试过去,verify-clients 参数是后面增加的,很多网上的 derp 部署教程没写这个,如果是参考以前教程部署的,那还是能用到,就是得花时间自己试。
|
14
xuemian OP 目前采用凉心云做 DERP 中转 13ms 了
* IPv6: no * MappingVariesByDestIP: * HairPinning: false * PortMapping: UPnP * Nearest DERP: tencent-cloud-DERP * DERP latency: - tencent: 29.7ms (tencent-cloud-DERP) |
16
unfurl 358 天前
我就是用自建的 DERP ,稳得很
|
17
gps949 358 天前
@HandSonic
1 、再怎么说 DERP 也都是中转,总会增加延迟的,所以能想办法搞直连了肯定比走 DERP 强; 2 、自建 DERP 用作中转的话一般来说要么小水管(带宽小)、要么费用贵、要么延迟大(国外流量便宜带宽大的情况下); 至于有人说别人能白嫖,那倒不会,因为自建 DERP 可以做鉴别仅限自己的节点走它中转的。 |
18
rnv 358 天前
刚好这几天我也在折腾 tailscale ,谈一下自己的理解:
headscale 只是 tailscale 控制台的替代,使用 headscale 不能一定提升你设备间的可连接性和降低延迟。 当你的设备之间互 ping 延迟超高的时候,一般通过 tailscale status 查看都会发现设备间连接是通过 relay 实现的,也就是依赖于 tailscale 官方的 derp 服务器节点,这就说明你设备间打洞不成功。这种情况下就需要你自己部署 derp 节点了。 |
19
rnv 358 天前
@gps949 请问无法直连的设备要调整到可以直连一般从哪些方面入手?
我家里有公网 IP ,路由器 DMZ 给了一台主机 A ,局域网里还有其他主机 B ,C ,D 等。我用工具查看主机 A 的 Nat Type 是 FullCone ,其他主机 B 是 Symmetric 。在其他网络的另一台设备 Z ,Nat Type 是 Symmetric ,可以跟 A 直连,但跟 B 只能中转。 |
20
shaldon 358 天前
在控制台的 access controls 加上端口随机化试试
"randomizeClientPort": true, |
21
gps949 358 天前 1
@rnv
一般来说,搞出公网 IPv6 PD 分配下发是最简便的方式。 你说的这个现象正常,一般路由器(及被 DMZ 的主机)是全锥( FullCone 、NAT1 )的比较常见。连接两端只要有一端是全锥,基本上直连就稳了。 一般来说当两端情况是 NAT4+NAT4 时基本判死刑无法直连,有一端是 NAT4 而另一端是 NAT3 时也很危险。 就你的情形可以考虑看看是否开启 UPnP ,开启看看是否有帮助。更建议的是一个局域网中没必要都装 Tailscale 客户端,而是主要通过路由器(或被 DMZ 的主机)做整个局域网 NAT 的 subnet 子网转发,这样比较简便。 |
22
xuemian OP @coolcoffee #12 在 config.yaml 里加了行
verify_clients: true |
23
jonty 358 天前
前段时间 v 站的 9 块钱阿里云拿来做 derp 节点了。。现在 10ms 左右的延迟
|
24
Sekai 358 天前
没公网就得自建
|
25
Tink 358 天前 via iPhone
最好是能直连,否则不建议用
|
26
sunulin 357 天前 via iPhone
国内基本没公网 ip 所以还是要找国内服务器自建 DERP ,默认的的确很慢的
|
27
YGBlvcAK 357 天前 via Android
可以试试 frp 的 xtcp ,打洞能力超强
|
28
dltsgl 357 天前
同样的问题,自建 derp 连不上,放弃了
|
29
LoNeZ 357 天前
走 derp...可以不用 headscale...
|
30
fortitudeZDY 357 天前 via Android
厚脸皮推荐下俺的 tailscale 国内发行版,支持国内中转和微信认证,目前已经支持桌面和移动平台。xedge.cc
|
31
TESTFLIGHT2021 357 天前
@fortitudeZDY 哥 经营 VPN 要证的。。。不怕进去么
|
32
ZField 357 天前
@fortitudeZDY #30 vip 的带宽是共享的吗?网络问题只能走中转,我自建的 Derp 只有 5M 带宽,远程体验一般般……
看了一下文档,还挺想试试的…… |
33
gps949 357 天前 1
|
34
fortitudeZDY 357 天前 via Android
@TESTFLIGHT2021 合作方有国内证的,暂时没办理
|
35
fortitudeZDY 357 天前 via Android
@ZField 嗯,只能共享,不然成本抗不住
|
36
DT27 357 天前
@fortitudeZDY 这就打不开了= =、
|
37
james19820515 125 天前
有结论了吗?
|