1

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

2

我有一个想法

4

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

5

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

6

7

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

8

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

9

这个像 zeortier 么？

10

有 lighthouse 也行吧

12

设计思路跟 Tinc 类似

13

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

16

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

17

n2n VPN 就落伍了？

18

和 vpn 类似，tun/tap

20

1

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

21

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

23

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

24

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

25

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

28

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

29

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

30

32

33

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

34

@j 哎呀

35

哇...哦！

36

和 openvpn 有啥区别？

37

这是传说中的 SD-WAN ？

38

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

39

40

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

41

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

44

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

45

46

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

49

50

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

51

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

52

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

53

56

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

57

2

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

58

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

59

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

60

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

63

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

64

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

65

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

66

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

67

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

68

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

69

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

70

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

71

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

72

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

73

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

74

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

75

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

77

Windows 上似乎存在驱动问题？

79

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

80

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

81

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

83

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

84

85

87

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

88

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

89

90

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

91

92

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