这是一个创建于 1855 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
tangbao 2019-11-20 16:28:45 +08:00
哇塞，这也太棒了！已经 Star ！不知道和 VPN 相比优缺点在哪里。
|
 |
2
lpd0155 2019-11-20 16:30:46 +08:00 via Android
我有一个想法
|
 |
4
Maboroshii 2019-11-20 16:57:17 +08:00
有公开的 lighthouse 吗，连上去会发生什么
|
 |
5
morphyhu 2019-11-20 17:06:04 +08:00
流量会经过中间服务器中转吗？还是点对点传输？
|
 |
6
Livid MOD OP |
 |
9
billzhuang 2019-11-20 17:39:12 +08:00
这个像 zeortier 么？
|
 |
10
vuser 2019-11-20 18:11:19 +08:00
有 lighthouse 也行吧
|
 |
11
testcaoy7 2019-11-20 18:16:24 +08:00
这是个好东西啊
|
|
12
testcaoy7 2019-11-20 18:25:16 +08:00
设计思路跟 Tinc 类似
|
|
13
testcaoy7 2019-11-20 19:11:12 +08:00
@morphyhu 应该是 P2P 的，刚刚搭建了，用了两台本地网络的虚拟机和一台公网的 VPS，两台虚拟机 Ping 的时候，刚开始几秒延迟较高，然后就只有 0.5 至 0.7ms 的延迟了，说明一开始通过 Lighthouse 握手，握手完成后就 P2P 了
|
 |
14
frozenshadow 2019-11-20 20:15:57 +08:00 via Android
@testcaoy7 他们博客说有参考 Tinc
|
 |
15
learningman 2019-11-20 20:23:16 +08:00 via Android
@Livid 社会主义内网路由器也在内网的。。。
|
 |
16
darrh00 2019-11-20 21:30:58 +08:00
看起来不错，但是好像缺个移动的客户端。不知道有了没有？
|
 |
17
tempdban 2019-11-20 21:34:41 +08:00 via Android
n2n VPN 就落伍了？
|
 |
18
wslzy007 2019-11-20 21:36:24 +08:00
和 vpn 类似，tun/tap
|
 |
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 会先出客户端 |
 |
21
missdeer 2019-11-20 22:56:42 +08:00
果然也是用 go 写的
话说我前两天刚刚看了些 tun/tap 的文档和代码，准备自己写个 p2p vpn 程序的。。 |
 |
23
binux 2019-11-21 07:37:30 +08:00 via Android
用过 tinc 和 zerotier 之后还是更喜欢 zerotier，使用一点中心化让配置更简单了。
|
|
24
missdeer 2019-11-21 10:41:08 +08:00
试了一下，nebula 性能损耗有点大，直接 ping 稳定在 82-83ms，走 nebula 飙到 140-150ms，还丢包严重，难道没加个好点的 FEC 或 ARQ 算法么
|
 |
25
Atukey 2019-11-21 10:46:07 +08:00
我有一个大胆的想法，我想把 bdas894，u ￥ f3@j，，/
|
|
28
missdeer 2019-11-21 11:33:59 +08:00
@dbskcnc
tinc 基本走 tcp，虽然宣称有时候会走 udp，但没见到过，也没见过它 2 个内网机器 p2p 穿透直连，配置也更麻烦一点，用过段时间放弃了。 前段时间用了一阵子某群里一大佬自己写的商业版程序的 beta 版，跟 nebula 的做法比较类似，走 udp，但不开源，也不能绑定到本地的某一个网卡用，性能好得多。 目前看来 nebula 比前两者都要好一些。 zerotier 也用过一小阵子，web 配置界面是方便很多，但几乎所有流量都中转的样子，太慢了，受不了。 |
|
29
Livid MOD OP @missdeer 嗯。不会增加延迟的。只是如果两端都在内网里，也没有 port forward 的话，貌似目前不一定能连上。
|
 |
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 |
 |
33
lqf96 2019-11-21 12:17:37 +08:00
我觉得以国内的网络条件，有的时候还是需要控制流量的发送方式，比如服务器中转，又比如流量分流、nat 穿透之类的...也许真的可以考虑一下搞一个虚拟的 l2 （ ethernet/mpls over tunnel ）控制流量发送策略，然后让现在这些 overlay 的 l3 跑在虚拟的 l2 上，这样就可以做非常灵活的部署...
|
 |
35
subpo 2019-11-21 14:42:07 +08:00
哇...哦！
|
 |
36
Jiajin 2019-11-21 14:43:14 +08:00
和 openvpn 有啥区别？
|
 |
37
Mysqto 2019-11-21 14:49:02 +08:00
这是传说中的 SD-WAN ？
|
 |
38
qistchan 2019-11-21 14:50:39 +08:00
目前用的 tinc，感觉和这差不多
|
 |
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 暴露在公网上 |
 |
40
zhucegeqiu 2019-11-22 09:31:22 +08:00
和 wireguaard, openvpn 相比有什么特色？
|
 |
41
xsen 2019-11-22 09:40:35 +08:00
感觉有点意思，就是不知道性能怎么样。看了下介绍，似乎 slack 内部的服务器已经基于 Nebula 使用超过 2 年
|
|
43
xsen 2019-11-22 09:54:35 +08:00
|
 |
44
fireapp 2019-11-22 11:41:47 +08:00 via iPhone
我用三台机器测试了一下，一个 lighthouse，两个普通节点，lighthouse 跟两个普通节点可以相互通信， 但是两个普通节点无法通信，不知道为啥，用的 example 给的那个配置文件
@testcaoy7 |
 |
45
c 2019-11-22 11:53:43 +08:00
|
|
47
fireapp 2019-11-22 14:21:07 +08:00 via iPhone
新建了一个 tg 群组，感兴趣的小伙伴们可以进来一起交流下
t.me/nebula_net |
|
49
fireapp 2019-11-22 17:11:48 +08:00 via iPhone
|
 |
50
xunandotme 2019-11-22 17:30:02 +08:00
回去试试 openwrt，然后在下发一层
|
 |
51
weyou 2019-11-22 18:13:53 +08:00 via Android
@missdeer 还有个错误哦。其实 tinc 默认数据流（ data protocol ）就是走 udp 的，只有 tinc 节点之间的 meta protocol 是走 tcp 的。而且可以配置文件中指定 data protocol 也走 tcp，不过这种方式不推荐。
|
 |
52
fortitudeZDY 2019-11-22 23:38:36 +08:00
@c 我也想通过 nebula 接口进行路由，配置了下，发现 ping 别的网段的包没有发出去，感觉还是有点问题。firewall 全部开放了也不行。
|
|
53
c 2019-11-23 10:26:55 +08:00 via Android
@fortitudeZDY 不知道如何配置，抓包显示请求到 lighthouse 查询后就没有了
|
|
54
billzhuang 2019-11-23 14:55:01 +08:00
@missdeer zerotier 加个自己的 moon 了么？
|
|
55
fortitudeZDY 2019-11-23 17:46:47 +08:00 via Android
@c 估计他们还没有路由功能
|
 |
56
aawei 2019-11-24 20:43:23 +08:00
|
|
57
fireapp 2019-11-24 20:47:07 +08:00 via iPhone 2
@aawei 任何节点间都可以相互访问，你 把 icmp 改成 any 测试就行，其实是防火墙规则
|
 |
59
abbottcn 2019-11-25 16:09:40 +08:00 via iPhone
如果节点采用手机上的热点接入网络，则节点之间访问失效，但是节点均可以访问 lighthouse，lighthouse 也可以访问节点。使用普通的 WiFi 接入，节点之间的访问立即恢复。 测试环境，lighthouse 腾讯云主机。节点 1，有线网络，ubuntu，节点 2, Mac，无线网络接入，可接入到 WiFi，或者手机热点，可选电信或者移动线路。
|
 |
62
wzw 2019-12-25 17:21:44 +08:00
|
 |
63
nuk 2020-03-06 01:40:26 +08:00
@weyou
实际上 tcp 比 udp 要稳定很多，udp 丢包非常严重，另外自动 p2p 容易造成路由抖动，因为权重是根据 tinc 的启动时间算的（问号脸？？？） |
|
64
weyou 2020-03-06 12:09:12 +08:00 via Android
@nuk udp 稳不稳定得看你的 isp 有没有对 udp 进行 qos。我测试过 tcp 模式，正常的话跟 udp 差不多，但有时候延迟会突然增大十几倍，一定要重启 tinc 才能恢复。估计是 tinc 的 bug。
|
|
65
nuk 2020-03-07 01:57:24 +08:00
@weyou 有时 tcp 会人为加 100ms 延迟，不过最近基本不出现了，不过我觉得你问题这个可能是因为 tcp 连接重建后路由变化，而且默认超过三个连接后，tinc 自动断开多余的连接，有的时候就会把最优的断掉。我有六个节点全部用 tcp，除了去年出口国际偶尔被加 100ms 延迟外基本没有其他问题。不过不知道现在咋样，最开始我也是用 udp，但是后来抖动太大，换 tcp 就好了，可能确实要看 isp 吧。
|
|
66
weyou 2020-03-07 09:53:47 +08:00 via Android
@nuk 用的 1.1 还是 1.0 ？我的 1.0.35 ，tcp 延迟增加这个问题是必现的，特别是传输过大文件之后，连 ssh 里敲字符都能感受到明显的延迟。udp 因为有 qos，传输大文件比较慢，但是延迟方面没问题。
|
|
67
nuk 2020-03-08 00:23:41 +08:00
@weyou 用的 1.1pre17。1.1 用了两年了，从 pre15 开始，没遇到什么问题，除了去年六月份和十月份被加 100ms 延时。
|
|
68
weyou 2020-03-08 10:45:28 +08:00 via Android
@nuk 什么是人为加 100ms ？估计和我出现的问题一样的，就是延迟突然变大而且不重启 tinc 无法恢复
|
|
69
nuk 2020-03-09 00:11:15 +08:00
@weyou 我应该和你不一样，我把 tinc 断掉之后 ping 延迟也会增加 100ms，和 tinc 无关，应该是所有的包都被加了延时，而且抖动很稳定，不过过大概几个小时就会恢复正常，我估计是做了流量监测，和用什么协议都没关系。
|
 |
74
soulzz 2020-04-11 05:54:58 +08:00
配置起来真的方便 10 分钟搞定
一点问题都没有 |
|
75
billzhuang 2020-04-11 13:24:08 +08:00
虽然有 lighting，但我看了下连接，基本都是直连。我倒是希望能走 lighting 。
|
 |
76
460881773 2020-04-11 15:37:16 +08:00
厉害了
|
 |
77
baobao1270 2020-04-11 17:28:29 +08:00
Windows 上似乎存在驱动问题？
|
|
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 的问题 这篇文章解决了我的问题 |
 |
79
guigeng 2020-11-03 13:55:02 +08:00
nebula 稳定性比 zt 好一点，传输基本能吃满带宽
|
 |
80
la0wei 2020-11-26 10:33:59 +08:00
@fireapp 和你的情况一样，节点都可以和 lighthouse 通信，但是节点间不通，根据日志，节点发送 udp 包的时候，从局域网 ip 到公网 ip 一通尝试，但是不成功，打洞还是有问题。
|
 |
81
dbpe 2020-11-30 20:47:41 +08:00
同...两个 client 在不同内网...无法访问.
|
|
82
Livid MOD OP 1
|
 |
85
wogong 2020-12-03 20:15:21 +08:00
@Livid #79 如果哪天 tinc 的后端能采用 wireguard 就好了。
长期使用 tinc，和 tailscale 相比可能的缺点 1. 配置麻烦，毕竟 tailscale 太简单了 2. 后端不是采用 wireguard 性能可能会差点（我没具体测试过，光看 ping 的话几乎没有区别） 优点 1. 开源 2. 相对于 tailscale 更安全，暴露面更少 |
 |
86
noqwerty 2020-12-09 08:33:44 +08:00
@dbpe #83 tailscale 的服务器似乎只负责密钥和规则的分发，实际流量是采用 wireguard 的所有节点之间全部互联的 mesh 模式的，参考 https://tailscale.com/blog/how-tailscale-works/
|
|
87
billzhuang 2020-12-10 22:31:20 +08:00
nebula 问题，对 NAT 穿透好像差了点，有的时候连不上，开始切换到 tailscale
|
|
88
dbpe 2020-12-11 14:15:05 +08:00
@billzhuang 对 nat 类型有要求...所以当你是 NAT3 在路由后面不能只能访问的时候..打洞就失败了..然后又不能走灯塔过...GG,不过我看有人提出这个问题了...不知道会不会去解决
|
|
89
billzhuang 2020-12-11 14:48:50 +08:00 via iPhone
|
 |
90
NealLason 2020-12-18 17:34:14 +08:00
一直是 tinc 老用户，前几天试过 nebula，比较呆，两个 Node p2p 打洞不成功的话就直接连不上了
|
|
91
dbpe 2020-12-26 14:43:30 +08:00
@NealLason 大佬...我想问个 tinc 的问题..就是我一个节点 A(公网服务器),一个节点 B(内网,路由设置好 dmz 了)
a/b 可以相互通讯....然后我节点 C(公司内网),然后这两个..我死活连不上 a/b.一般要从哪里开始排查? |
Select Language