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

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

  •  2
     
  •   Livid · 137 天前 · 12826 次点击
    这是一个创建于 137 天前的主题,其中的信息可能已经有所发展或是发生改变。
    https://github.com/slackhq/nebula

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

    通讯的两端需要至少有一端的 4242 在公网上暴露。如果两端都在内网里,看起来是会有问题。
    morphyhu
        7
    morphyhu   137 天前
    @Livid 这样看来不符合社会主义国情啊。这让在社会主义内网的机器情何以堪
    Livid
        8
    Livid   V2EX Moderator   137 天前
    @morphyhu 路由器上 port forward 4242 可以解决。
    billzhuang
        9
    billzhuang   137 天前
    这个像 zeortier 么?
    vuser
        10
    vuser   137 天前
    有 lighthouse 也行吧
    testcaoy7
        11
    testcaoy7   137 天前
    这是个好东西啊
    testcaoy7
        12
    testcaoy7   137 天前
    设计思路跟 Tinc 类似
    testcaoy7
        13
    testcaoy7   137 天前
    @morphyhu 应该是 P2P 的,刚刚搭建了,用了两台本地网络的虚拟机和一台公网的 VPS,两台虚拟机 Ping 的时候,刚开始几秒延迟较高,然后就只有 0.5 至 0.7ms 的延迟了,说明一开始通过 Lighthouse 握手,握手完成后就 P2P 了
    frozenshadow
        14
    frozenshadow   137 天前 via Android
    @testcaoy7 他们博客说有参考 Tinc
    learningman
        15
    learningman   137 天前 via Android
    @Livid 社会主义内网路由器也在内网的。。。
    darrh00
        16
    darrh00   137 天前
    看起来不错,但是好像缺个移动的客户端。不知道有了没有?
    tempdban
        17
    tempdban   137 天前 via Android
    n2n VPN 就落伍了?
    wslzy007
        18
    wslzy007   137 天前
    和 vpn 类似,tun/tap
    aheadlead
        19
    aheadlead   137 天前
    @Livid 站长一般从哪获取这样的资讯? thx
    uhian
        20
    uhian   137 天前   ❤️ 1
    @darrh00 (Also: keep this quiet, but we have an early prototype running on iOS).
    看来 iOS 会先出客户端
    missdeer
        21
    missdeer   137 天前
    果然也是用 go 写的
    话说我前两天刚刚看了些 tun/tap 的文档和代码,准备自己写个 p2p vpn 程序的。。
    alphatoad
        22
    alphatoad   137 天前 via iPhone
    @lpd0155 我有一个不成熟的建议
    binux
        23
    binux   137 天前 via Android
    用过 tinc 和 zerotier 之后还是更喜欢 zerotier,使用一点中心化让配置更简单了。
    missdeer
        24
    missdeer   137 天前
    试了一下,nebula 性能损耗有点大,直接 ping 稳定在 82-83ms,走 nebula 飙到 140-150ms,还丢包严重,难道没加个好点的 FEC 或 ARQ 算法么
    Atukey
        25
    Atukey   137 天前
    我有一个大胆的想法,我想把 bdas894,u ¥ [email protected],,/
    missdeer
        26
    missdeer   137 天前
    @missdeer 搞错了,应该是我的路由的问题
    dbskcnc
        27
    dbskcnc   137 天前
    @missdeer 试下 tinc 对比下
    missdeer
        28
    missdeer   137 天前
    @dbskcnc
    tinc 基本走 tcp,虽然宣称有时候会走 udp,但没见到过,也没见过它 2 个内网机器 p2p 穿透直连,配置也更麻烦一点,用过段时间放弃了。
    前段时间用了一阵子某群里一大佬自己写的商业版程序的 beta 版,跟 nebula 的做法比较类似,走 udp,但不开源,也不能绑定到本地的某一个网卡用,性能好得多。
    目前看来 nebula 比前两者都要好一些。
    zerotier 也用过一小阵子,web 配置界面是方便很多,但几乎所有流量都中转的样子,太慢了,受不了。
    Livid
        29
    Livid   V2EX Moderator   137 天前 via iPhone
    @missdeer 嗯。不会增加延迟的。只是如果两端都在内网里,也没有 port forward 的话,貌似目前不一定能连上。
    dbskcnc
        30
    dbskcnc   137 天前
    @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   137 天前
    @dbskcnc 那就不知道了,也许是我配置有问题,总之我是一直见它走中转的样子
    j
        32
    j   136 天前
    @Atukey 我被你 @了。
    lqf96
        33
    lqf96   136 天前
    我觉得以国内的网络条件,有的时候还是需要控制流量的发送方式,比如服务器中转,又比如流量分流、nat 穿透之类的...也许真的可以考虑一下搞一个虚拟的 l2 ( ethernet/mpls over tunnel )控制流量发送策略,然后让现在这些 overlay 的 l3 跑在虚拟的 l2 上,这样就可以做非常灵活的部署...
    Atukey
        34
    Atukey   136 天前
    @j 哎呀
    subpo
        35
    subpo   136 天前
    哇...哦!
    Jiajin
        36
    Jiajin   136 天前
    和 openvpn 有啥区别?
    Mysqto
        37
    Mysqto   136 天前
    这是传说中的 SD-WAN ?
    qistchan
        38
    qistchan   136 天前
    目前用的 tinc,感觉和这差不多
    jabari
        39
    jabari   136 天前
    @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   136 天前
    和 wireguaard, openvpn 相比有什么特色?
    xsen
        41
    xsen   136 天前
    感觉有点意思,就是不知道性能怎么样。看了下介绍,似乎 slack 内部的服务器已经基于 Nebula 使用超过 2 年
    morphyhu
        42
    morphyhu   136 天前
    @testcaoy7 有没有做个 iperf3 测试。感觉 ping 测不出问题。
    xsen
        43
    xsen   136 天前
    详细情况可参考这里,
    https://slack.engineering/introducing-nebula-the-open-source-global-overlay-network-from-slack-884110a5579
    fireapp
        44
    fireapp   136 天前 via iPhone
    我用三台机器测试了一下,一个 lighthouse,两个普通节点,lighthouse 跟两个普通节点可以相互通信, 但是两个普通节点无法通信,不知道为啥,用的 example 给的那个配置文件
    @testcaoy7
    c
        45
    c   136 天前
    @fireapp 默认防火墙只能 ping

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

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

    @terry6394 @aawei

    https://www.v2ex.com/t/628564#reply17
    nuk
        63
    nuk   31 天前
    @weyou
    实际上 tcp 比 udp 要稳定很多,udp 丢包非常严重,另外自动 p2p 容易造成路由抖动,因为权重是根据 tinc 的启动时间算的(问号脸???)
    weyou
        64
    weyou   30 天前 via Android
    @nuk udp 稳不稳定得看你的 isp 有没有对 udp 进行 qos。我测试过 tcp 模式,正常的话跟 udp 差不多,但有时候延迟会突然增大十几倍,一定要重启 tinc 才能恢复。估计是 tinc 的 bug。
    nuk
        65
    nuk   30 天前
    @weyou 有时 tcp 会人为加 100ms 延迟,不过最近基本不出现了,不过我觉得你问题这个可能是因为 tcp 连接重建后路由变化,而且默认超过三个连接后,tinc 自动断开多余的连接,有的时候就会把最优的断掉。我有六个节点全部用 tcp,除了去年出口国际偶尔被加 100ms 延迟外基本没有其他问题。不过不知道现在咋样,最开始我也是用 udp,但是后来抖动太大,换 tcp 就好了,可能确实要看 isp 吧。
    weyou
        66
    weyou   30 天前 via Android
    @nuk 用的 1.1 还是 1.0 ?我的 1.0.35 ,tcp 延迟增加这个问题是必现的,特别是传输过大文件之后,连 ssh 里敲字符都能感受到明显的延迟。udp 因为有 qos,传输大文件比较慢,但是延迟方面没问题。
    nuk
        67
    nuk   29 天前
    @weyou 用的 1.1pre17。1.1 用了两年了,从 pre15 开始,没遇到什么问题,除了去年六月份和十月份被加 100ms 延时。
    weyou
        68
    weyou   29 天前 via Android
    @nuk 什么是人为加 100ms ?估计和我出现的问题一样的,就是延迟突然变大而且不重启 tinc 无法恢复
    nuk
        69
    nuk   28 天前
    @weyou 我应该和你不一样,我把 tinc 断掉之后 ping 延迟也会增加 100ms,和 tinc 无关,应该是所有的包都被加了延时,而且抖动很稳定,不过过大概几个小时就会恢复正常,我估计是做了流量监测,和用什么协议都没关系。
    nuk
        70
    nuk   28 天前
    @weyou 肯定和功夫网有关系,都是开会的时候就不稳
    wzw
        71
    wzw   4 天前
    @weyou #68 @nuk #69 tinc 是不是可以只走 tcp 流量, 我可以用公网服务器中转
    nuk
        72
    nuk   3 天前
    @wzw 可以的哦,只要加 tcponly=yes 就行了,其他节点会根据对端来自动选择 tcp 或者 udp 。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2741 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 03:59 · PVG 11:59 · LAX 20:59 · JFK 23:59
    ♥ Do have faith in what you're doing.