驳斥 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 和一堆配套的做了试验，目前尚未达成。

风云的倒是够大够清晰，但是延迟了半个月多，向日葵基本上实时，但是太小了。

装 HEVC 插件的方法是安装 B 站的 UWP ； DV 的方法忘了，好像由 bundle 。不过 OP 已经解决了。

至于 OP 最后补充的字幕问题，这要看原始文件封装的水平，印象上只有 MP4 封装的 DV 能够比较正确的调取 DV 的解码，所以字幕封装就看制作组的水平了。

内录

难道。。。。
JD 就是买一个快递效率（ JD 就是一家快递公司），TB 就是买一个东西足够全么。。。一般常见的规格化的东西，去 JD 买隔日到，没有隔日谁还在 JD 上多花钱；而不是规格化常见的东西，JD 上也有很多第三方商家，用了非 JDL 也快不了，跟 TB 差不多，一般情况下还略贵； TB 就图一个要啥基本有啥，再没有就得去小黄鱼了，至于时效，开玩笑“既要又要”啊。
这个应该是基本认知？