This topic created in 2541 days ago, the information mentioned may be changed or developed.
 |
tangbaoNov 20, 2019
1
哇塞，这也太棒了！已经 Star ！不知道和 VPN 相比优缺点在哪里。
|
 |
lpd0155Nov 20, 2019 via Android
2
我有一个想法
|
3 |
MaboroshiiNov 20, 2019
4
有公开的 lighthouse 吗，连上去会发生什么
|
 |
morphyhuNov 20, 2019
5
流量会经过中间服务器中转吗？还是点对点传输？
|
 |
billzhuangNov 20, 2019
9
这个像 zeortier 么？
|
 |
vuserNov 20, 2019
10
有 lighthouse 也行吧
|
 |
testcaoy7Nov 20, 2019
11
这是个好东西啊
|
|
testcaoy7Nov 20, 2019
12
设计思路跟 Tinc 类似
|
|
testcaoy7Nov 20, 2019
13
@morphyhu 应该是 P2P 的，刚刚搭建了，用了两台本地网络的虚拟机和一台公网的 VPS，两台虚拟机 Ping 的时候，刚开始几秒延迟较高，然后就只有 0.5 至 0.7ms 的延迟了，说明一开始通过 Lighthouse 握手，握手完成后就 P2P 了
|
 |
frozenshadowNov 20, 2019 via Android
14
@testcaoy7 他们博客说有参考 Tinc
|
 |
learningmanNov 20, 2019 via Android
15
@Livid 社会主义内网路由器也在内网的。。。
|
 |
darrh00Nov 20, 2019
16
看起来不错，但是好像缺个移动的客户端。不知道有了没有？
|
 |
tempdbanNov 20, 2019 via Android
17
n2n VPN 就落伍了？
|
 |
wslzy007Nov 20, 2019
18
和 vpn 类似，tun/tap
|
 |
20
@darrh00 (Also: keep this quiet, but we have an early prototype running on iOS).
看来 iOS 会先出客户端 |
 |
missdeerNov 20, 2019
21
果然也是用 go 写的
话说我前两天刚刚看了些 tun/tap 的文档和代码，准备自己写个 p2p vpn 程序的。。 |
 |
binuxNov 21, 2019 via Android
23
用过 tinc 和 zerotier 之后还是更喜欢 zerotier，使用一点中心化让配置更简单了。
|
|
missdeerNov 21, 2019
24
试了一下，nebula 性能损耗有点大，直接 ping 稳定在 82-83ms，走 nebula 飙到 140-150ms，还丢包严重，难道没加个好点的 FEC 或 ARQ 算法么
|
 |
AtukeyNov 21, 2019
25
我有一个大胆的想法，我想把 bdas894，u ￥ f3@j，，/
|
|
missdeerNov 21, 2019
28
@dbskcnc
tinc 基本走 tcp，虽然宣称有时候会走 udp，但没见到过，也没见过它 2 个内网机器 p2p 穿透直连，配置也更麻烦一点，用过段时间放弃了。 前段时间用了一阵子某群里一大佬自己写的商业版程序的 beta 版，跟 nebula 的做法比较类似，走 udp，但不开源，也不能绑定到本地的某一个网卡用，性能好得多。 目前看来 nebula 比前两者都要好一些。 zerotier 也用过一小阵子，web 配置界面是方便很多，但几乎所有流量都中转的样子，太慢了，受不了。 |
 |
29
@missdeer 嗯。不会增加延迟的。只是如果两端都在内网里，也没有 port forward 的话，貌似目前不一定能连上。
|
 |
dbskcncNov 21, 2019
30
@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 |
 |
lqf96Nov 21, 2019
33
我觉得以国内的网络条件，有的时候还是需要控制流量的发送方式，比如服务器中转，又比如流量分流、nat 穿透之类的...也许真的可以考虑一下搞一个虚拟的 l2 （ ethernet/mpls over tunnel ）控制流量发送策略，然后让现在这些 overlay 的 l3 跑在虚拟的 l2 上，这样就可以做非常灵活的部署...
|
 |
subpoNov 21, 2019
35
哇...哦！
|
 |
JiajinNov 21, 2019
36
和 openvpn 有啥区别？
|
 |
MysqtoNov 21, 2019
37
这是传说中的 SD-WAN ？
|
 |
qistchanNov 21, 2019
38
目前用的 tinc，感觉和这差不多
|
 |
jabariNov 21, 2019
39
@Livid #6 (Optional, but you really should..) At least one discovery node with a routable IP address, which we call a lighthouse.
至少需要一个节点的 ip 暴露在公网上 |
 |
Vanquish5419Nov 22, 2019
40
和 wireguaard, openvpn 相比有什么特色？
|
 |
xsenNov 22, 2019
41
感觉有点意思，就是不知道性能怎么样。看了下介绍，似乎 slack 内部的服务器已经基于 Nebula 使用超过 2 年
|
|
xsenNov 22, 2019
43
|
 |
fireappNov 22, 2019 via iPhone
44
我用三台机器测试了一下，一个 lighthouse，两个普通节点，lighthouse 跟两个普通节点可以相互通信， 但是两个普通节点无法通信，不知道为啥，用的 example 给的那个配置文件
@testcaoy7 |
|
fireappNov 22, 2019 via iPhone
47
新建了一个 tg 群组，感兴趣的小伙伴们可以进来一起交流下
t.me/nebula_net |
 |
xnplusNov 22, 2019
50
回去试试 openwrt，然后在下发一层
|
 |
weyouNov 22, 2019 via Android
51
@missdeer 还有个错误哦。其实 tinc 默认数据流（ data protocol ）就是走 udp 的，只有 tinc 节点之间的 meta protocol 是走 tcp 的。而且可以配置文件中指定 data protocol 也走 tcp，不过这种方式不推荐。
|
 |
cNov 23, 2019 via Android
53
@fortitudeZDY 不知道如何配置，抓包显示请求到 lighthouse 查询后就没有了
|
|
billzhuangNov 23, 2019
54
@missdeer zerotier 加个自己的 moon 了么？
|
 |
abbottcnNov 25, 2019 via iPhone
59
如果节点采用手机上的热点接入网络，则节点之间访问失效，但是节点均可以访问 lighthouse，lighthouse 也可以访问节点。使用普通的 WiFi 接入，节点之间的访问立即恢复。 测试环境，lighthouse 腾讯云主机。节点 1，有线网络，ubuntu，节点 2, Mac，无线网络接入，可接入到 WiFi，或者手机热点，可选电信或者移动线路。
|
 |
wzwDec 25, 2019
62
|
 |
nukMar 6, 2020
63
@weyou
实际上 tcp 比 udp 要稳定很多，udp 丢包非常严重，另外自动 p2p 容易造成路由抖动，因为权重是根据 tinc 的启动时间算的（问号脸？？？） |
|
weyouMar 6, 2020 via Android
64
@nuk udp 稳不稳定得看你的 isp 有没有对 udp 进行 qos。我测试过 tcp 模式，正常的话跟 udp 差不多，但有时候延迟会突然增大十几倍，一定要重启 tinc 才能恢复。估计是 tinc 的 bug。
|
|
nukMar 7, 2020
65
@weyou 有时 tcp 会人为加 100ms 延迟，不过最近基本不出现了，不过我觉得你问题这个可能是因为 tcp 连接重建后路由变化，而且默认超过三个连接后，tinc 自动断开多余的连接，有的时候就会把最优的断掉。我有六个节点全部用 tcp，除了去年出口国际偶尔被加 100ms 延迟外基本没有其他问题。不过不知道现在咋样，最开始我也是用 udp，但是后来抖动太大，换 tcp 就好了，可能确实要看 isp 吧。
|
|
weyouMar 7, 2020 via Android
66
@nuk 用的 1.1 还是 1.0 ？我的 1.0.35 ，tcp 延迟增加这个问题是必现的，特别是传输过大文件之后，连 ssh 里敲字符都能感受到明显的延迟。udp 因为有 qos，传输大文件比较慢，但是延迟方面没问题。
|
|
nukMar 9, 2020
69
@weyou 我应该和你不一样，我把 tinc 断掉之后 ping 延迟也会增加 100ms，和 tinc 无关，应该是所有的包都被加了延时，而且抖动很稳定，不过过大概几个小时就会恢复正常，我估计是做了流量监测，和用什么协议都没关系。
|
 |
soulzzApr 11, 2020
74
配置起来真的方便 10 分钟搞定
一点问题都没有 |
|
billzhuangApr 11, 2020
75
虽然有 lighting，但我看了下连接，基本都是直连。我倒是希望能走 lighting 。
|
 |
460881773Apr 11, 2020
76
厉害了
|
 |
baobao1270Apr 11, 2020
77
Windows 上似乎存在驱动问题？
|
|
soulzzApr 21, 2020
78
@baobao1270
https://michlstechblog.info/blog/openvpn-connect-to-multiple-vpns-on-windows/ 已经有装过 openvpn 的可能会碰到多个 vpn 占用一个 tap 的问题 这篇文章解决了我的问题 |
 |
guigengNov 3, 2020
79
nebula 稳定性比 zt 好一点，传输基本能吃满带宽
|
 |
la0weiNov 26, 2020
80
@fireapp 和你的情况一样，节点都可以和 lighthouse 通信，但是节点间不通，根据日志，节点发送 udp 包的时候，从局域网 ip 到公网 ip 一通尝试，但是不成功，打洞还是有问题。
|
 |
dbpeNov 30, 2020
81
同...两个 client 在不同内网...无法访问.
|
|
82
|
 |
wogongDec 3, 2020
85
@Livid #79 如果哪天 tinc 的后端能采用 wireguard 就好了。
长期使用 tinc，和 tailscale 相比可能的缺点 1. 配置麻烦，毕竟 tailscale 太简单了 2. 后端不是采用 wireguard 性能可能会差点（我没具体测试过，光看 ping 的话几乎没有区别） 优点 1. 开源 2. 相对于 tailscale 更安全，暴露面更少 |
 |
noqwertyDec 9, 2020
86
@dbpe #83 tailscale 的服务器似乎只负责密钥和规则的分发，实际流量是采用 wireguard 的所有节点之间全部互联的 mesh 模式的，参考 https://tailscale.com/blog/how-tailscale-works/
|
|
billzhuangDec 10, 2020
87
nebula 问题，对 NAT 穿透好像差了点，有的时候连不上，开始切换到 tailscale
|
|
dbpeDec 11, 2020
88
@billzhuang 对 nat 类型有要求...所以当你是 NAT3 在路由后面不能只能访问的时候..打洞就失败了..然后又不能走灯塔过...GG,不过我看有人提出这个问题了...不知道会不会去解决
|
|
billzhuangDec 11, 2020 via iPhone
89
|
 |
NealLasonDec 18, 2020
90
一直是 tinc 老用户，前几天试过 nebula，比较呆，两个 Node p2p 打洞不成功的话就直接连不上了
|
|
dbpeDec 26, 2020
91
@NealLason 大佬...我想问个 tinc 的问题..就是我一个节点 A(公网服务器),一个节点 B(内网,路由设置好 dmz 了)
a/b 可以相互通讯....然后我节点 C(公司内网),然后这两个..我死活连不上 a/b.一般要从哪里开始排查? |
Select Language