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

哇塞，这也太棒了！已经 Star ！不知道和 VPN 相比优缺点在哪里。

我有一个想法

@lpd0155 #2 不要有太大胆的想法，有一些想法是违法的。

有公开的 lighthouse 吗，连上去会发生什么

流量会经过中间服务器中转吗？还是点对点传输？

@morphyhu 目前初步测试的一些结果：

通讯的两端需要至少有一端的 4242 在公网上暴露。如果两端都在内网里，看起来是会有问题。

@Livid 这样看来不符合社会主义国情啊。这让在社会主义内网的机器情何以堪

@morphyhu 路由器上 port forward 4242 可以解决。

这个像 zeortier 么？

有 lighthouse 也行吧

这是个好东西啊

设计思路跟 Tinc 类似

@morphyhu 应该是 P2P 的，刚刚搭建了，用了两台本地网络的虚拟机和一台公网的 VPS，两台虚拟机 Ping 的时候，刚开始几秒延迟较高，然后就只有 0.5 至 0.7ms 的延迟了，说明一开始通过 Lighthouse 握手，握手完成后就 P2P 了

@testcaoy7 他们博客说有参考 Tinc

@Livid 社会主义内网路由器也在内网的。。。

看起来不错，但是好像缺个移动的客户端。不知道有了没有？

n2n VPN 就落伍了？

和 vpn 类似，tun/tap

@Livid 站长一般从哪获取这样的资讯？ thx

@darrh00 (Also: keep this quiet, but we have an early prototype running on iOS).
看来 iOS 会先出客户端

果然也是用 go 写的
话说我前两天刚刚看了些 tun/tap 的文档和代码，准备自己写个 p2p vpn 程序的。。

@lpd0155 我有一个不成熟的建议

用过 tinc 和 zerotier 之后还是更喜欢 zerotier，使用一点中心化让配置更简单了。

试了一下，nebula 性能损耗有点大，直接 ping 稳定在 82-83ms，走 nebula 飙到 140-150ms，还丢包严重，难道没加个好点的 FEC 或 ARQ 算法么

我有一个大胆的想法，我想把 bdas894，u ￥ f3@j，，/

@missdeer 搞错了，应该是我的路由的问题

@missdeer 试下 tinc 对比下

@dbskcnc
tinc 基本走 tcp，虽然宣称有时候会走 udp，但没见到过，也没见过它 2 个内网机器 p2p 穿透直连，配置也更麻烦一点，用过段时间放弃了。
前段时间用了一阵子某群里一大佬自己写的商业版程序的 beta 版，跟 nebula 的做法比较类似，走 udp，但不开源，也不能绑定到本地的某一个网卡用，性能好得多。
目前看来 nebula 比前两者都要好一些。
zerotier 也用过一小阵子，web 配置界面是方便很多，但几乎所有流量都中转的样子，太慢了，受不了。

@missdeer 嗯。不会增加延迟的。只是如果两端都在内网里，也没有 port forward 的话，貌似目前不一定能连上。

@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

@dbskcnc 那就不知道了，也许是我配置有问题，总之我是一直见它走中转的样子

@Atukey 我被你 @了。

我觉得以国内的网络条件，有的时候还是需要控制流量的发送方式，比如服务器中转，又比如流量分流、nat 穿透之类的...也许真的可以考虑一下搞一个虚拟的 l2 （ ethernet/mpls over tunnel ）控制流量发送策略，然后让现在这些 overlay 的 l3 跑在虚拟的 l2 上，这样就可以做非常灵活的部署...

@j 哎呀

哇...哦！

和 openvpn 有啥区别？

这是传说中的 SD-WAN ？

目前用的 tinc，感觉和这差不多

@Livid #6 (Optional, but you really should..) At least one discovery node with a routable IP address, which we call a lighthouse.

至少需要一个节点的 ip 暴露在公网上

和 wireguaard, openvpn 相比有什么特色？

感觉有点意思，就是不知道性能怎么样。看了下介绍，似乎 slack 内部的服务器已经基于 Nebula 使用超过 2 年

@testcaoy7 有没有做个 iperf3 测试。感觉 ping 测不出问题。

详细情况可参考这里，
https://slack.engineering/introducing-nebula-the-open-source-global-overlay-network-from-slack-884110a5579

我用三台机器测试了一下，一个 lighthouse，两个普通节点，lighthouse 跟两个普通节点可以相互通信， 但是两个普通节点无法通信，不知道为啥，用的 example 给的那个配置文件
@testcaoy7

@fireapp 默认防火墙只能 ping

节点间只能访问子网[192.168.100.1/24]，没办法访问其他网段，没找到设置路由的地方。这个咋解决啊？

@c 我现在普通节点间都 ping 不通，估计是哪里出了问题

新建了一个 tg 群组，感兴趣的小伙伴们可以进来一起交流下
t.me/nebula_net

@fireapp 你建错了。。。你这是发通知的。。别人不能说话的

我的 nebula 搭好了，损失的性能很小，可以忽略

@mrlmh00 不好意思弄错了，删了重来，地址不变

回去试试 openwrt，然后在下发一层

@missdeer 还有个错误哦。其实 tinc 默认数据流（ data protocol ）就是走 udp 的，只有 tinc 节点之间的 meta protocol 是走 tcp 的。而且可以配置文件中指定 data protocol 也走 tcp，不过这种方式不推荐。

@c 我也想通过 nebula 接口进行路由，配置了下，发现 ping 别的网段的包没有发出去，感觉还是有点问题。firewall 全部开放了也不行。

@fortitudeZDY 不知道如何配置，抓包显示请求到 lighthouse 查询后就没有了

@missdeer zerotier 加个自己的 moon 了么？

@c 估计他们还没有路由功能

@c
@fireapp 大佬们求解，你们连接上去，普通节点能访问 Lighthouse 的端口吗？我试了，只能 ping 通，但是端口互相访问对方都不行。。

@aawei 任何节点间都可以相互访问，你 把 icmp 改成 any 测试就行，其实是防火墙规则

@fireapp 已解决，感谢！看了好几遍配置文档，都没注意到

如果节点采用手机上的热点接入网络，则节点之间访问失效，但是节点均可以访问 lighthouse，lighthouse 也可以访问节点。使用普通的 WiFi 接入，节点之间的访问立即恢复。 测试环境，lighthouse 腾讯云主机。节点 1，有线网络，ubuntu，节点 2, Mac，无线网络接入，可接入到 WiFi，或者手机热点，可选电信或者移动线路。

@fireapp 我遇到之前一样的问题，普通节点之间 ping 不通。请问你当时是如何解决的？

@terry6394 @aawei 我也遇到同样问题，你们如何解决

proto: icmp，icmp 要改成 any

@terry6394 @aawei

t/628564#reply17

@weyou
实际上 tcp 比 udp 要稳定很多，udp 丢包非常严重，另外自动 p2p 容易造成路由抖动，因为权重是根据 tinc 的启动时间算的（问号脸？？？）

@nuk udp 稳不稳定得看你的 isp 有没有对 udp 进行 qos。我测试过 tcp 模式，正常的话跟 udp 差不多，但有时候延迟会突然增大十几倍，一定要重启 tinc 才能恢复。估计是 tinc 的 bug。

@weyou 有时 tcp 会人为加 100ms 延迟，不过最近基本不出现了，不过我觉得你问题这个可能是因为 tcp 连接重建后路由变化，而且默认超过三个连接后，tinc 自动断开多余的连接，有的时候就会把最优的断掉。我有六个节点全部用 tcp，除了去年出口国际偶尔被加 100ms 延迟外基本没有其他问题。不过不知道现在咋样，最开始我也是用 udp，但是后来抖动太大，换 tcp 就好了，可能确实要看 isp 吧。

@nuk 用的 1.1 还是 1.0 ？我的 1.0.35 ，tcp 延迟增加这个问题是必现的，特别是传输过大文件之后，连 ssh 里敲字符都能感受到明显的延迟。udp 因为有 qos，传输大文件比较慢，但是延迟方面没问题。

@weyou 用的 1.1pre17。1.1 用了两年了，从 pre15 开始，没遇到什么问题，除了去年六月份和十月份被加 100ms 延时。

@nuk 什么是人为加 100ms ？估计和我出现的问题一样的，就是延迟突然变大而且不重启 tinc 无法恢复

@weyou 我应该和你不一样，我把 tinc 断掉之后 ping 延迟也会增加 100ms，和 tinc 无关，应该是所有的包都被加了延时，而且抖动很稳定，不过过大概几个小时就会恢复正常，我估计是做了流量监测，和用什么协议都没关系。

@weyou 肯定和功夫网有关系，都是开会的时候就不稳

@weyou #68 @nuk #69 tinc 是不是可以只走 tcp 流量, 我可以用公网服务器中转

@wzw 可以的哦，只要加 tcpOnly=yes 就行了，其他节点会根据对端来自动选择 tcp 或者 udp 。

@nuk 是不是 TCP 一定 lighthouse 中转，P2P 一定不是 TCP 呢？

配置起来真的方便 10 分钟搞定
一点问题都没有

虽然有 lighting，但我看了下连接，基本都是直连。我倒是希望能走 lighting 。

厉害了

Windows 上似乎存在驱动问题？

@baobao1270
https://michlstechblog.info/blog/openvpn-connect-to-multiple-vpns-on-windows/
已经有装过 openvpn 的可能会碰到多个 vpn 占用一个 tap 的问题
这篇文章解决了我的问题

nebula 稳定性比 zt 好一点，传输基本能吃满带宽

@fireapp 和你的情况一样，节点都可以和 lighthouse 通信，但是节点间不通，根据日志，节点发送 udp 包的时候，从局域网 ip 到公网 ip 一通尝试，但是不成功，打洞还是有问题。

同...两个 client 在不同内网...无法访问.

@dbpe
@la0wei

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

https://www.tailscale.com/

@Livid 貌似不是开源的..而且不能自建节点?

@dbpe 基于 WireGuard 。

Memcached 的作者也在这家公司工作。

@Livid #79 如果哪天 tinc 的后端能采用 wireguard 就好了。

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

优点
1. 开源
2. 相对于 tailscale 更安全，暴露面更少

@dbpe #83 tailscale 的服务器似乎只负责密钥和规则的分发，实际流量是采用 wireguard 的所有节点之间全部互联的 mesh 模式的，参考 https://tailscale.com/blog/how-tailscale-works/

nebula 问题，对 NAT 穿透好像差了点，有的时候连不上，开始切换到 tailscale

@billzhuang 对 nat 类型有要求...所以当你是 NAT3 在路由后面不能只能访问的时候..打洞就失败了..然后又不能走灯塔过...GG,不过我看有人提出这个问题了...不知道会不会去解决

@dbpe 官方说会考虑解决。

一个问题，那个 tailscale 怎么在国内访问快点，我这边延时有点高。

一直是 tinc 老用户，前几天试过 nebula，比较呆，两个 Node p2p 打洞不成功的话就直接连不上了

@NealLason 大佬...我想问个 tinc 的问题..就是我一个节点 A(公网服务器),一个节点 B(内网,路由设置好 dmz 了)

a/b 可以相互通讯....然后我节点 C(公司内网),然后这两个..我死活连不上 a/b.一般要从哪里开始排查?

@dbpe tinc 默认端口是 655，c 节点连不上 a 的话，是不是 655 端口被公司防火墙给禁掉了？？