V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Livid
V2EX  ›  Nebula

Slack 开源了他们的 overlay network 工具 Nebula

  •  5
     
  •   Livid · 2019-11-20 16:25:19 +08:00 · 33571 次点击
    这是一个创建于 1591 天前的主题,其中的信息可能已经有所发展或是发生改变。
    https://github.com/slackhq/nebula

    简单来说,就是可以用很简单的方式让全球各地的机器用安全的方式在同一个内网里。
    92 条回复    2021-02-08 10:09:01 +08:00
    tangbao
        1
    tangbao  
       2019-11-20 16:28:45 +08:00
    哇塞,这也太棒了!已经 Star !不知道和 VPN 相比优缺点在哪里。
    lpd0155
        2
    lpd0155  
       2019-11-20 16:30:46 +08:00 via Android
    我有一个想法
    tangbao
        3
    tangbao  
       2019-11-20 16:31:15 +08:00   ❤️ 3
    @lpd0155 #2 不要有太大胆的想法,有一些想法是违法的。
    Maboroshii
        4
    Maboroshii  
       2019-11-20 16:57:17 +08:00
    有公开的 lighthouse 吗,连上去会发生什么
    morphyhu
        5
    morphyhu  
       2019-11-20 17:06:04 +08:00
    流量会经过中间服务器中转吗?还是点对点传输?
    Livid
        6
    Livid  
    MOD
    OP
       2019-11-20 17:15:42 +08:00
    @morphyhu 目前初步测试的一些结果:

    通讯的两端需要至少有一端的 4242 在公网上暴露。如果两端都在内网里,看起来是会有问题。
    morphyhu
        7
    morphyhu  
       2019-11-20 17:23:16 +08:00
    @Livid 这样看来不符合社会主义国情啊。这让在社会主义内网的机器情何以堪
    Livid
        8
    Livid  
    MOD
    OP
       2019-11-20 17:24:14 +08:00
    @morphyhu 路由器上 port forward 4242 可以解决。
    billzhuang
        9
    billzhuang  
       2019-11-20 17:39:12 +08:00
    这个像 zeortier 么?
    vuser
        10
    vuser  
       2019-11-20 18:11:19 +08:00
    有 lighthouse 也行吧
    testcaoy7
        11
    testcaoy7  
       2019-11-20 18:16:24 +08:00
    这是个好东西啊
    testcaoy7
        12
    testcaoy7  
       2019-11-20 18:25:16 +08:00
    设计思路跟 Tinc 类似
    testcaoy7
        13
    testcaoy7  
       2019-11-20 19:11:12 +08:00
    @morphyhu 应该是 P2P 的,刚刚搭建了,用了两台本地网络的虚拟机和一台公网的 VPS,两台虚拟机 Ping 的时候,刚开始几秒延迟较高,然后就只有 0.5 至 0.7ms 的延迟了,说明一开始通过 Lighthouse 握手,握手完成后就 P2P 了
    frozenshadow
        14
    frozenshadow  
       2019-11-20 20:15:57 +08:00 via Android
    @testcaoy7 他们博客说有参考 Tinc
    learningman
        15
    learningman  
       2019-11-20 20:23:16 +08:00 via Android
    @Livid 社会主义内网路由器也在内网的。。。
    darrh00
        16
    darrh00  
       2019-11-20 21:30:58 +08:00
    看起来不错,但是好像缺个移动的客户端。不知道有了没有?
    tempdban
        17
    tempdban  
       2019-11-20 21:34:41 +08:00 via Android
    n2n VPN 就落伍了?
    wslzy007
        18
    wslzy007  
       2019-11-20 21:36:24 +08:00
    和 vpn 类似,tun/tap
    aheadlead
        19
    aheadlead  
       2019-11-20 21:51:26 +08:00   ❤️ 1
    @Livid 站长一般从哪获取这样的资讯? thx
    uhian
        20
    uhian  
       2019-11-20 21:55:21 +08:00   ❤️ 1
    @darrh00 (Also: keep this quiet, but we have an early prototype running on iOS).
    看来 iOS 会先出客户端
    missdeer
        21
    missdeer  
       2019-11-20 22:56:42 +08:00
    果然也是用 go 写的
    话说我前两天刚刚看了些 tun/tap 的文档和代码,准备自己写个 p2p vpn 程序的。。
    alphatoad
        22
    alphatoad  
       2019-11-21 06:51:42 +08:00 via iPhone
    @lpd0155 我有一个不成熟的建议
    binux
        23
    binux  
       2019-11-21 07:37:30 +08:00 via Android
    用过 tinc 和 zerotier 之后还是更喜欢 zerotier,使用一点中心化让配置更简单了。
    missdeer
        24
    missdeer  
       2019-11-21 10:41:08 +08:00
    试了一下,nebula 性能损耗有点大,直接 ping 稳定在 82-83ms,走 nebula 飙到 140-150ms,还丢包严重,难道没加个好点的 FEC 或 ARQ 算法么
    Atukey
        25
    Atukey  
       2019-11-21 10:46:07 +08:00
    我有一个大胆的想法,我想把 bdas894,u ¥ f3@j,,/
    missdeer
        26
    missdeer  
       2019-11-21 10:47:54 +08:00
    @missdeer 搞错了,应该是我的路由的问题
    dbskcnc
        27
    dbskcnc  
       2019-11-21 10:49:08 +08:00
    @missdeer 试下 tinc 对比下
    missdeer
        28
    missdeer  
       2019-11-21 11:33:59 +08:00
    @dbskcnc
    tinc 基本走 tcp,虽然宣称有时候会走 udp,但没见到过,也没见过它 2 个内网机器 p2p 穿透直连,配置也更麻烦一点,用过段时间放弃了。
    前段时间用了一阵子某群里一大佬自己写的商业版程序的 beta 版,跟 nebula 的做法比较类似,走 udp,但不开源,也不能绑定到本地的某一个网卡用,性能好得多。
    目前看来 nebula 比前两者都要好一些。
    zerotier 也用过一小阵子,web 配置界面是方便很多,但几乎所有流量都中转的样子,太慢了,受不了。
    Livid
        29
    Livid  
    MOD
    OP
       2019-11-21 11:38:25 +08:00 via iPhone
    @missdeer 嗯。不会增加延迟的。只是如果两端都在内网里,也没有 port forward 的话,貌似目前不一定能连上。
    dbskcnc
        30
    dbskcnc  
       2019-11-21 11:41:11 +08:00
    @missdeer 你这个结果一定是错的,tinc 是会 p2p 的,特别试了下

    ping 10.20.30.80
    PING 10.20.30.80 (10.20.30.80) 56(84) bytes of data.
    64 bytes from 10.20.30.80: icmp_seq=1 ttl=128 time=34.9 ms
    64 bytes from 10.20.30.80: icmp_seq=2 ttl=128 time=33.0 ms
    64 bytes from 10.20.30.80: icmp_seq=3 ttl=128 time=3.28 ms
    64 bytes from 10.20.30.80: icmp_seq=4 ttl=128 time=2.49 ms
    64 bytes from 10.20.30.80: icmp_seq=5 ttl=128 time=3.47 ms
    missdeer
        31
    missdeer  
       2019-11-21 11:47:41 +08:00
    @dbskcnc 那就不知道了,也许是我配置有问题,总之我是一直见它走中转的样子
    j
        32
    j  
       2019-11-21 12:15:41 +08:00
    @Atukey 我被你 @了。
    lqf96
        33
    lqf96  
       2019-11-21 12:17:37 +08:00
    我觉得以国内的网络条件,有的时候还是需要控制流量的发送方式,比如服务器中转,又比如流量分流、nat 穿透之类的...也许真的可以考虑一下搞一个虚拟的 l2 ( ethernet/mpls over tunnel )控制流量发送策略,然后让现在这些 overlay 的 l3 跑在虚拟的 l2 上,这样就可以做非常灵活的部署...
    Atukey
        34
    Atukey  
       2019-11-21 14:32:23 +08:00
    @j 哎呀
    subpo
        35
    subpo  
       2019-11-21 14:42:07 +08:00
    哇...哦!
    Jiajin
        36
    Jiajin  
       2019-11-21 14:43:14 +08:00
    和 openvpn 有啥区别?
    Mysqto
        37
    Mysqto  
       2019-11-21 14:49:02 +08:00
    这是传说中的 SD-WAN ?
    qistchan
        38
    qistchan  
       2019-11-21 14:50:39 +08:00
    目前用的 tinc,感觉和这差不多
    jabari
        39
    jabari  
       2019-11-21 16:06:22 +08:00
    @Livid #6 (Optional, but you really should..) At least one discovery node with a routable IP address, which we call a lighthouse.

    至少需要一个节点的 ip 暴露在公网上
    zhucegeqiu
        40
    zhucegeqiu  
       2019-11-22 09:31:22 +08:00
    和 wireguaard, openvpn 相比有什么特色?
    xsen
        41
    xsen  
       2019-11-22 09:40:35 +08:00
    感觉有点意思,就是不知道性能怎么样。看了下介绍,似乎 slack 内部的服务器已经基于 Nebula 使用超过 2 年
    morphyhu
        42
    morphyhu  
       2019-11-22 09:48:27 +08:00
    @testcaoy7 有没有做个 iperf3 测试。感觉 ping 测不出问题。
    xsen
        43
    xsen  
       2019-11-22 09:54:35 +08:00
    fireapp
        44
    fireapp  
       2019-11-22 11:41:47 +08:00 via iPhone
    我用三台机器测试了一下,一个 lighthouse,两个普通节点,lighthouse 跟两个普通节点可以相互通信, 但是两个普通节点无法通信,不知道为啥,用的 example 给的那个配置文件
    @testcaoy7
    c
        45
    c  
       2019-11-22 11:53:43 +08:00
    @fireapp 默认防火墙只能 ping

    节点间只能访问子网[192.168.100.1/24],没办法访问其他网段,没找到设置路由的地方。这个咋解决啊?
    fireapp
        46
    fireapp  
       2019-11-22 12:00:27 +08:00 via iPhone
    @c 我现在普通节点间都 ping 不通,估计是哪里出了问题
    fireapp
        47
    fireapp  
       2019-11-22 14:21:07 +08:00 via iPhone
    新建了一个 tg 群组,感兴趣的小伙伴们可以进来一起交流下
    t.me/nebula_net
    mrlmh00
        48
    mrlmh00  
       2019-11-22 15:31:07 +08:00
    @fireapp 你建错了。。。你这是发通知的。。别人不能说话的
    fireapp
        49
    fireapp  
       2019-11-22 17:11:48 +08:00 via iPhone
    我的 nebula 搭好了,损失的性能很小,可以忽略

    @mrlmh00 不好意思弄错了,删了重来,地址不变
    xunandotme
        50
    xunandotme  
       2019-11-22 17:30:02 +08:00
    回去试试 openwrt,然后在下发一层
    weyou
        51
    weyou  
       2019-11-22 18:13:53 +08:00 via Android
    @missdeer 还有个错误哦。其实 tinc 默认数据流( data protocol )就是走 udp 的,只有 tinc 节点之间的 meta protocol 是走 tcp 的。而且可以配置文件中指定 data protocol 也走 tcp,不过这种方式不推荐。
    fortitudeZDY
        52
    fortitudeZDY  
       2019-11-22 23:38:36 +08:00
    @c 我也想通过 nebula 接口进行路由,配置了下,发现 ping 别的网段的包没有发出去,感觉还是有点问题。firewall 全部开放了也不行。
    c
        53
    c  
       2019-11-23 10:26:55 +08:00 via Android
    @fortitudeZDY 不知道如何配置,抓包显示请求到 lighthouse 查询后就没有了
    billzhuang
        54
    billzhuang  
       2019-11-23 14:55:01 +08:00
    @missdeer zerotier 加个自己的 moon 了么?
    fortitudeZDY
        55
    fortitudeZDY  
       2019-11-23 17:46:47 +08:00 via Android
    @c 估计他们还没有路由功能
    aawei
        56
    aawei  
       2019-11-24 20:43:23 +08:00
    @c
    @fireapp 大佬们求解,你们连接上去,普通节点能访问 Lighthouse 的端口吗?我试了,只能 ping 通,但是端口互相访问对方都不行。。
    fireapp
        57
    fireapp  
       2019-11-24 20:47:07 +08:00 via iPhone   ❤️ 2
    @aawei 任何节点间都可以相互访问,你 把 icmp 改成 any 测试就行,其实是防火墙规则
    aawei
        58
    aawei  
       2019-11-24 23:04:30 +08:00
    @fireapp 已解决,感谢!看了好几遍配置文档,都没注意到
    abbottcn
        59
    abbottcn  
       2019-11-25 16:09:40 +08:00 via iPhone
    如果节点采用手机上的热点接入网络,则节点之间访问失效,但是节点均可以访问 lighthouse,lighthouse 也可以访问节点。使用普通的 WiFi 接入,节点之间的访问立即恢复。 测试环境,lighthouse 腾讯云主机。节点 1,有线网络,ubuntu,节点 2, Mac,无线网络接入,可接入到 WiFi,或者手机热点,可选电信或者移动线路。
    terry6394
        60
    terry6394  
       2019-12-14 15:52:33 +08:00
    @fireapp 我遇到之前一样的问题,普通节点之间 ping 不通。请问你当时是如何解决的?
    wzw
        61
    wzw  
       2019-12-18 07:30:52 +08:00 via iPhone
    @terry6394 @aawei 我也遇到同样问题,你们如何解决
    wzw
        62
    wzw  
       2019-12-25 17:21:44 +08:00
    proto: icmp,icmp 要改成 any

    @terry6394 @aawei

    https://www.v2ex.com/t/628564#reply17
    nuk
        63
    nuk  
       2020-03-06 01:40:26 +08:00
    @weyou
    实际上 tcp 比 udp 要稳定很多,udp 丢包非常严重,另外自动 p2p 容易造成路由抖动,因为权重是根据 tinc 的启动时间算的(问号脸???)
    weyou
        64
    weyou  
       2020-03-06 12:09:12 +08:00 via Android
    @nuk udp 稳不稳定得看你的 isp 有没有对 udp 进行 qos。我测试过 tcp 模式,正常的话跟 udp 差不多,但有时候延迟会突然增大十几倍,一定要重启 tinc 才能恢复。估计是 tinc 的 bug。
    nuk
        65
    nuk  
       2020-03-07 01:57:24 +08:00
    @weyou 有时 tcp 会人为加 100ms 延迟,不过最近基本不出现了,不过我觉得你问题这个可能是因为 tcp 连接重建后路由变化,而且默认超过三个连接后,tinc 自动断开多余的连接,有的时候就会把最优的断掉。我有六个节点全部用 tcp,除了去年出口国际偶尔被加 100ms 延迟外基本没有其他问题。不过不知道现在咋样,最开始我也是用 udp,但是后来抖动太大,换 tcp 就好了,可能确实要看 isp 吧。
    weyou
        66
    weyou  
       2020-03-07 09:53:47 +08:00 via Android
    @nuk 用的 1.1 还是 1.0 ?我的 1.0.35 ,tcp 延迟增加这个问题是必现的,特别是传输过大文件之后,连 ssh 里敲字符都能感受到明显的延迟。udp 因为有 qos,传输大文件比较慢,但是延迟方面没问题。
    nuk
        67
    nuk  
       2020-03-08 00:23:41 +08:00
    @weyou 用的 1.1pre17。1.1 用了两年了,从 pre15 开始,没遇到什么问题,除了去年六月份和十月份被加 100ms 延时。
    weyou
        68
    weyou  
       2020-03-08 10:45:28 +08:00 via Android
    @nuk 什么是人为加 100ms ?估计和我出现的问题一样的,就是延迟突然变大而且不重启 tinc 无法恢复
    nuk
        69
    nuk  
       2020-03-09 00:11:15 +08:00
    @weyou 我应该和你不一样,我把 tinc 断掉之后 ping 延迟也会增加 100ms,和 tinc 无关,应该是所有的包都被加了延时,而且抖动很稳定,不过过大概几个小时就会恢复正常,我估计是做了流量监测,和用什么协议都没关系。
    nuk
        70
    nuk  
       2020-03-09 00:12:36 +08:00
    @weyou 肯定和功夫网有关系,都是开会的时候就不稳
    wzw
        71
    wzw  
       2020-04-01 22:37:12 +08:00
    @weyou #68 @nuk #69 tinc 是不是可以只走 tcp 流量, 我可以用公网服务器中转
    nuk
        72
    nuk  
       2020-04-03 02:50:55 +08:00
    @wzw 可以的哦,只要加 tcponly=yes 就行了,其他节点会根据对端来自动选择 tcp 或者 udp 。
    yorkyoung
        73
    yorkyoung  
       2020-04-11 00:12:33 +08:00
    @nuk 是不是 TCP 一定 lighthouse 中转,P2P 一定不是 TCP 呢?
    soulzz
        74
    soulzz  
       2020-04-11 05:54:58 +08:00
    配置起来真的方便 10 分钟搞定
    一点问题都没有
    billzhuang
        75
    billzhuang  
       2020-04-11 13:24:08 +08:00
    虽然有 lighting,但我看了下连接,基本都是直连。我倒是希望能走 lighting 。
    460881773
        76
    460881773  
       2020-04-11 15:37:16 +08:00
    厉害了
    baobao1270
        77
    baobao1270  
       2020-04-11 17:28:29 +08:00
    Windows 上似乎存在驱动问题?
    soulzz
        78
    soulzz  
       2020-04-21 18:20:37 +08:00
    @baobao1270
    https://michlstechblog.info/blog/openvpn-connect-to-multiple-vpns-on-windows/
    已经有装过 openvpn 的可能会碰到多个 vpn 占用一个 tap 的问题
    这篇文章解决了我的问题
    guigeng
        79
    guigeng  
       2020-11-03 13:55:02 +08:00
    nebula 稳定性比 zt 好一点,传输基本能吃满带宽
    la0wei
        80
    la0wei  
       2020-11-26 10:33:59 +08:00
    @fireapp 和你的情况一样,节点都可以和 lighthouse 通信,但是节点间不通,根据日志,节点发送 udp 包的时候,从局域网 ip 到公网 ip 一通尝试,但是不成功,打洞还是有问题。
    dbpe
        81
    dbpe  
       2020-11-30 20:47:41 +08:00
    同...两个 client 在不同内网...无法访问.
    Livid
        82
    Livid  
    MOD
    OP
       2020-12-01 04:05:43 +08:00   ❤️ 1
    @dbpe
    @la0wei

    最近发现一个个人使用可能效果更好的方案:

    https://www.tailscale.com/
    dbpe
        83
    dbpe  
       2020-12-02 08:35:36 +08:00
    @Livid 貌似不是开源的..而且不能自建节点?
    Livid
        84
    Livid  
    MOD
    OP
       2020-12-02 09:30:46 +08:00
    @dbpe 基于 WireGuard 。

    Memcached 的作者也在这家公司工作。
    wogong
        85
    wogong  
       2020-12-03 20:15:21 +08:00
    @Livid #79 如果哪天 tinc 的后端能采用 wireguard 就好了。

    长期使用 tinc,和 tailscale 相比可能的缺点
    1. 配置麻烦,毕竟 tailscale 太简单了
    2. 后端不是采用 wireguard 性能可能会差点(我没具体测试过,光看 ping 的话几乎没有区别)

    优点
    1. 开源
    2. 相对于 tailscale 更安全,暴露面更少
    noqwerty
        86
    noqwerty  
       2020-12-09 08:33:44 +08:00
    @dbpe #83 tailscale 的服务器似乎只负责密钥和规则的分发,实际流量是采用 wireguard 的所有节点之间全部互联的 mesh 模式的,参考 https://tailscale.com/blog/how-tailscale-works/
    billzhuang
        87
    billzhuang  
       2020-12-10 22:31:20 +08:00
    nebula 问题,对 NAT 穿透好像差了点,有的时候连不上,开始切换到 tailscale
    dbpe
        88
    dbpe  
       2020-12-11 14:15:05 +08:00
    @billzhuang 对 nat 类型有要求...所以当你是 NAT3 在路由后面不能只能访问的时候..打洞就失败了..然后又不能走灯塔过...GG,不过我看有人提出这个问题了...不知道会不会去解决
    billzhuang
        89
    billzhuang  
       2020-12-11 14:48:50 +08:00 via iPhone
    @dbpe 官方说会考虑解决。

    一个问题,那个 tailscale 怎么在国内访问快点,我这边延时有点高。
    NealLason
        90
    NealLason  
       2020-12-18 17:34:14 +08:00
    一直是 tinc 老用户,前几天试过 nebula,比较呆,两个 Node p2p 打洞不成功的话就直接连不上了
    dbpe
        91
    dbpe  
       2020-12-26 14:43:30 +08:00
    @NealLason 大佬...我想问个 tinc 的问题..就是我一个节点 A(公网服务器),一个节点 B(内网,路由设置好 dmz 了)

    a/b 可以相互通讯....然后我节点 C(公司内网),然后这两个..我死活连不上 a/b.一般要从哪里开始排查?
    NealLason
        92
    NealLason  
       2021-02-08 10:09:01 +08:00
    @dbpe tinc 默认端口是 655,c 节点连不上 a 的话,是不是 655 端口被公司防火墙给禁掉了??
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2864 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 11:39 · PVG 19:39 · LAX 04:39 · JFK 07:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.