@matate 38# 初衷是这样的，分处两端的设备在 L2 直接通信，且不通过 l2tp 、gre 等方法。但事实上，zerotier 做不到。我观察，ARP 可以在主 LAN 和子 NODE 之间广播，但无法广播到子 NODE 桥接的 LAN 的其他设备，就是 A 询问 B 的 ARP ，C 、D 都能获得（ C 、D 是两个节点 zerotier ，且允许桥接）而 B 是收不到数据包的。我猜应该是 zerotier 打开 L2 Bridging 之后，只能接收 ARP 并且给各个 NODE 发送，而不能转发 ARP 广播——这就需要看源码了。这是观察到的 ARP 信息，没有 ARP ，二层通信应该就完全没有了，AB 不通的原因在此。

@sapphire 39# 我觉得你的测试环境可能不清晰，也许通过其他路由策略完成了链路通道。某个角落文章说过桥接的时候要禁止 DHCP 包的广播，否则会让 zerotier 产生更加奇怪的情况。主从的问题，我也非常纳闷，两个同等的 LAN ，ZT 是怎么知道谁主谁从的，第一个接入还是什么，如果结合本贴前半截说的 ARP 问题，可能会有一个解释：不分主从，只能数据包无法通达。

@matate 36# 最初的原动力就是 zerotier 说可以 L2 Bridge ，那问题就来了，能不能桥接两个 LAN （甚至多个），实践结果就是不能，只能在一个 LAN 中完成桥接，不能桥接到第二个 LAN 中——附言一的那张图。如果非要做，可能就是需要 L2TP 或者 wireguard 的 GRE 隧道等技术完成。

windows 的多用户也叫多用户？？
OP 这需求，开虚拟桌面吧（不是 windows10 以后的那个多桌面啊）

驳斥 OP 最后一句话，很多 U 盘到后期，都得斜着掰一下，系统才能识别。

但从稳固上来说，越大越稳固，越小越不稳固——带挂钩的 DP 公头是我使用中最难受的，但是你无法否认它的坚固。而小型接口中，type-c 是一个非常赶鸭子上架的接口：机械性能差——触点小舌安排在的母座端，如果小舌损坏，甚至可能报废整个主机；电气性能差——线头多（ 20/21 个引脚）其为了兼顾一样定义浪费太大，而 PD3.1 又加了 48V/5A/240W 的标准，那小触点……相比之下 L 先就好一点，特别是 VisIonPRO 上出现了 Lightning Pro/Max 什么的，触点够但又不繁，小舌在公头上，真的坏了换线而不是换母座（主机）。

@bjfane 29#

你这个 lan to lan ，其实还是 peer to peer ，因为通过 NAT ，每个 peer 隐藏了身后的 LAN 。其实我的原始效果是想要两个 LAN 在二层形成一个 LAN ，即统一的地址和掩码，以及广播地址，这样深处两网的两台机器的通讯，是通过基本的网络交换完成的——在广播地址上呼喊 ARP ，然后数据包直接到达连接端口，这是硬件交换机的模型。但是 zerotier 在这里是一个软件产品，桥接了两个网，某种意义上并不存在“交换机端口”，所以我觉得不能把远端的 LAN 桥接入本地的 LAN ，原因也只在于此。

然后通过 wireguard 实现二层桥接，补充里说了，有人通过 wg 的 p2p 构建链路之后，创建 gre 隧道二层桥接网络。

再然后，如果不是一个 LAN 地址，不使用 NAT ，直接三层路由转发，那就是 4#和 27#说的事情了。现在我对于远端的 LAN 就是这么做的。

但凡发射个 wifi 信号，这信号不就能被查到么。千方百计走有线。

楼上这个小黄鱼上 120 。

@Immunize 26# 我知道了，你这个没有用 luci_app_zerotier 的相关东西，那个里边有一个 NAT 选项，选定后自带脚本会加上一条 MASQUERADE 记录，也就是一条 NAT 规则，于是都按照 NAT 往外走了。而且官网文档上也有三条 iptables 的规则其中最后一条就这个 MASQUERADE 。

首先，搞定 iptv 的组播接收问题（穿透路由、IGMP Snooping 什么的）
其次，弄个 udprxy 完活，从 UDP 组播包转成 TCP 包
再次，其实我家的机顶盒是通过无线接入网关的，网关做了静态路由到光猫 IPTV VLAN 的上游。

所以，不存在什么中继 iptv 的问题。只要能做到二层桥接各个网络就行了。

一加 11 好像侧重游戏，一加 12 应该是支棱起来了。

@Immunize 14# 额。。。你说的那个，我理解就是 NAT 而不是路由，路由转发后的 IP 包是源地址 IP ，NAT 之后 IP 包的源地址是网关的地址——也就是 172.16.x.x 给 172.17.y.y 发数据包，17.y.y 的设备看到的是 10.244.17.1 发给他的 IP 包——而如果转发的话，IP 包源地址是 172.16.x.x 。

@sadan9 20#
@matate 22#
还是没明白想要什么，实现 3# 图上结构比较没有难度。而且右侧的 node ，可以通过 NAT 再挂一个子网。但是无法实现的是，右侧也实现一个左侧的 LAN ，即通过 ZT 桥接两个 LAN 。

追加了补充。

难道。。。作为程序猿，不知道 0.47 的 DMD 只是 1080p ？至于版权问题，太好办了，外接一个外贸盒子搞定了。投影么，个人觉得就是同等价位的不如电视，同等效果的比电视贵或者都很贵。

投影的成本大头是投影板子和光学系统，相比电视则简单到一个驱动和屏幕。而在软件系统方面的投入，一般都会选择一个大屏视频软件做合作方，系统不会那么好用。而外贸盒子，则性能够强，系统够开放，折腾去吧。

我的情况是家里和办公室两个地方，家里的 NAS 不想扩盘了，办公室那边有一批退役下来的机械硬盘。所以 zerotier 组网，因为家里是 qnap ，于是办公室工作站搞了 qutscloud 系统，并且组了网，延迟 4ms ，网速大概能够顶到家宽给到的 100Mbps 上限。目前的可选的有 vjbod 挂载（ iscsi ）、远程磁盘（ iscsi ）、webdav/S3 hybridmount ，或者 hbs3 备份（各种应用对网速的要求一次下降）。

@yaott2020 15# 16#

那个文档已经实现了 3#图片的左侧结构，轻松实现，本来这也不是问题。问题是无法在右侧实现同样的左侧结构：在右侧设立了一个网络之后，二层不通，只能使用 NAT 。

而所谓的路由转发原则成立，但实践上（应该是因为使用了 192 、172 、10 段）目的地址看到的都是被网关设备修改了源地址的 IP 包，我认为这就是 NAT 。

@PbCopy111 10# 这个方法只能桥接出一个网络，参见 3#的那张图


@flynaj 11# @humbass 12# 这种实现起来没有难度，以 11#的图举例子，所有 16.0/21 的设备都以 100.16 呈现给对方所有网络，在发送 IP 包的时候，会涉及到 IP 改写这个三层协议的内容。而期望的目标是二层桥接，即 A 设备找另外一个网络的 B 设备，通过 ARP 获得到 MAC 之后，直接“交换机”进行数据包交换从 A 到 B 。而三层 IP 改写也好 NAT 也罢，都需要经过中间网关 C 和 D 进行 IP 改写再送出。还是按照 11# 的图，原则上可以说这个 ZT 网络只有四台设备，然后这四台后边带着四个 LAN 。

@Immunize 4#
@yaott2020 5#
就是想做到完全桥接，而不是 NAT


官方也给了这么一个图片，原则上，如果左边能够实现子网的目标，右边也可以出现同样的网络结构，甚至再出现第三个第四个，变相成了某种网桥设备，将若干个物理子网在配置上达成一致形成一个网络。至于 @ranaanna 2# 提到的 WAN 出口问题，窃以为两个路由设备的默认路由都会指向 WAN 口，而只处理虚拟达成的大内网规则，并不会出现多出口的情况。第二个链接也确实提到了 zt 的 P2P 初心，可是既然能够实现了左侧的桥接，在右边再实现一个桥接，理论上我觉得还是能力所及的。

@humbass 3# 速度问题咱暂且不讨论，毕竟实现子网并不是以速度为目标而是一方面减少 NAT （可以左右两个 NAT 完成 ZT 的 P2P 初心）另一方面在子网的设备配置上减少穿墙打洞减少麻烦。至于配置，具体怎么搞呢？我只设置了 ZT 虚网内的路由策略，关闭了 ZT 的 DHCP ，子设备一律指定 IP ，涉及两个 OP 的成员都设置了允许桥接，甚至阻断 DHCP 流量，还需要搞什么呢？

开了两个 hyperV 和一堆配套的做了试验，目前尚未达成。