V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
xuemian
V2EX  ›  宽带症候群

Tailscale+headscale 方案 延迟超高

  •  
  •   xuemian · 87 天前 · 2841 次点击
    这是一个创建于 87 天前的主题,其中的信息可能已经有所发展或是发生改变。

    各位大佬,
    因为学校疑似屏蔽了 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 吗?

    36 条回复    2023-11-30 21:51:03 +08:00
    poisedflw
        1
    poisedflw  
       87 天前
    在你 headscale 机器上再部一套 derp 就行了,如果两个节点间无法直连会走国外节点中转就非常慢。开启 ipv6 后直连的成功率高。
    zenghx
        2
    zenghx  
       87 天前
    tailscale ping xxx 看看走的是哪个 derp 服务器,能不能直连上
    Goalonez
        3
    Goalonez  
       87 天前
    Tailscale netcheck 看一下 drep 的延迟,drep 也自建一个
    xuemian
        4
    xuemian  
    OP
       87 天前
    @zenghx #2 pong from mbp (100.64.0.2) via DERP(hkg) in 423ms
    xuemian
        5
    xuemian  
    OP
       87 天前
    @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
        6
    OOKAMI  
       87 天前
    headscale 默认使用的还是官方的 derp 服务器清单,你要降低延迟需要部署自己的 derp 服务器,然后改 ACL 配置里的 derpmap ,将自己的 derp 替换上去。
    gps949
        7
    gps949  
       87 天前
    你这看起来明显没直连走的 DERP 。建议想办法调整走直连,不到万不得已别自建 DERP
    HandSonic
        8
    HandSonic  
       87 天前
    @gps949 为啥别自建 DERP ?
    qwvy2g
        9
    qwvy2g  
       87 天前
    derp 别人能白嫖。国内节点 vps 很贵,10m 电信也有 300 多一年,还有实名制问题。
    apiman
        10
    apiman  
       87 天前
    即使自建了 derp ,也不如节点之间直连的速度快,尤其是在节点都有公网 ipv6 的情况下,简直是秒连接。自建 derp ,如果节点不能直连,就通过 derp 中转,这样速度瓶颈转移到了 derp ,比如只有 3M 的良心云
    coolcoffee
        11
    coolcoffee  
       87 天前
    我自己就是 headscale 和 tailscale 官方控制平面都在用。headscale 不是非必要,tailscale 的官方控制平面国内直连没有任何问题,你只需要国内自建 derper 节点即可。

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

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

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

    至于有人说别人能白嫖,那倒不会,因为自建 DERP 可以做鉴别仅限自己的节点走它中转的。
    rnv
        18
    rnv  
       87 天前
    刚好这几天我也在折腾 tailscale ,谈一下自己的理解:

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

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

    我家里有公网 IP ,路由器 DMZ 给了一台主机 A ,局域网里还有其他主机 B ,C ,D 等。我用工具查看主机 A 的 Nat Type 是 FullCone ,其他主机 B 是 Symmetric 。在其他网络的另一台设备 Z ,Nat Type 是 Symmetric ,可以跟 A 直连,但跟 B 只能中转。
    shaldon
        20
    shaldon  
       87 天前
    在控制台的 access controls 加上端口随机化试试
    "randomizeClientPort": true,
    gps949
        21
    gps949  
       87 天前   ❤️ 1
    @rnv
    一般来说,搞出公网 IPv6 PD 分配下发是最简便的方式。

    你说的这个现象正常,一般路由器(及被 DMZ 的主机)是全锥( FullCone 、NAT1 )的比较常见。连接两端只要有一端是全锥,基本上直连就稳了。
    一般来说当两端情况是 NAT4+NAT4 时基本判死刑无法直连,有一端是 NAT4 而另一端是 NAT3 时也很危险。

    就你的情形可以考虑看看是否开启 UPnP ,开启看看是否有帮助。更建议的是一个局域网中没必要都装 Tailscale 客户端,而是主要通过路由器(或被 DMZ 的主机)做整个局域网 NAT 的 subnet 子网转发,这样比较简便。
    xuemian
        22
    xuemian  
    OP
       87 天前
    @coolcoffee #12 在 config.yaml 里加了行
    verify_clients: true
    jonty
        23
    jonty  
       87 天前
    前段时间 v 站的 9 块钱阿里云拿来做 derp 节点了。。现在 10ms 左右的延迟
    Sekai
        24
    Sekai  
       87 天前
    没公网就得自建
    Tink
        25
    Tink  
       86 天前 via iPhone
    最好是能直连,否则不建议用
    sunulin
        26
    sunulin  
       86 天前 via iPhone
    国内基本没公网 ip 所以还是要找国内服务器自建 DERP ,默认的的确很慢的
    YGBlvcAK
        27
    YGBlvcAK  
       86 天前 via Android
    可以试试 frp 的 xtcp ,打洞能力超强
    dltsgl
        28
    dltsgl  
       86 天前
    同样的问题,自建 derp 连不上,放弃了
    LoNeZ
        29
    LoNeZ  
       86 天前
    走 derp...可以不用 headscale...
    fortitudeZDY
        30
    fortitudeZDY  
       86 天前 via Android
    厚脸皮推荐下俺的 tailscale 国内发行版,支持国内中转和微信认证,目前已经支持桌面和移动平台。xedge.cc
    TESTFLIGHT2021
        31
    TESTFLIGHT2021  
       86 天前
    @fortitudeZDY 哥 经营 VPN 要证的。。。不怕进去么
    ZField
        32
    ZField  
       86 天前
    @fortitudeZDY #30 vip 的带宽是共享的吗?网络问题只能走中转,我自建的 Derp 只有 5M 带宽,远程体验一般般……
    看了一下文档,还挺想试试的……
    gps949
        33
    gps949  
       86 天前   ❤️ 1
    @fortitudeZDY

    那我也搭车宣传一下我的开源项目——蜃境
    https://v2ex.com/t/965435#reply13
    fortitudeZDY
        34
    fortitudeZDY  
       86 天前 via Android
    @TESTFLIGHT2021 合作方有国内证的,暂时没办理
    fortitudeZDY
        35
    fortitudeZDY  
       86 天前 via Android
    @ZField 嗯,只能共享,不然成本抗不住
    DT27
        36
    DT27  
       86 天前
    @fortitudeZDY 这就打不开了= =、
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2562 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 15:17 · PVG 23:17 · LAX 07:17 · JFK 10:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.