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

[Livid]

https://github.com/slackhq/nebula

简单来说，就是可以用很简单的方式让全球各地的机器用安全的方式在同一个内网里。

[wzw]

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

[wzw]

proto: icmp，icmp 要改成 any

@terry6394 @aawei

https://www.v2ex.com/t/628564#reply17

[nuk]

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

[weyou]

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

[nuk]

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

[weyou]

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

[nuk]

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

[weyou]

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

[nuk]

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

[nuk]

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

[wzw]

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

[nuk]

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

[yorkyoung]

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

[soulzz]

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

[billzhuang]

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

[460881773]

厉害了

[baobao1270]

Windows 上似乎存在驱动问题？

[soulzz]

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

[guigeng]

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

[la0wei]

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