@Alchemistxxd 我测了信号，是反转 PWM ，这种情况接上猫扇能工作，一般温度不高时，iLO 里输出是 10%左右，对于猫扇是 90%，可以正常工作。你看到过 iLO 输出 100%吗？随着 iLO 输出加大，猫扇应该是降速的。

@guanchayuan 2014 年之前，退休双轨制，公务员是单独体制，按照退休时工资，以工作满 20 年、30 年和 35 年为例，其养老金替代率高达 80%、85%、90%。而且公务员普遍退休前提级，实际退休工资可能高于退休前工资。14 年到 24 年是过渡期，分成 3 类，老人、中人和新人，基本上也没降。24 年正式并轨，但是留了企业/职业年金的口子，因为是财政支付，机关普遍按照高规格发放年金，也造成目前看：所有人都是平等的，但有些人明显更平等！

养老保险是劫富济贫的制度，所以也要看收入线落在那边，另外，从政府、企业和个人的角度看，会有不同的感受。

@nonewind Gen8 和 Gen10 ，及 Plus 应该是通用的，自己可以看一下线的颜色，相同就行。我看平流层买的信号反转线 Gen8 和 Gen10 是一款。HPE 其他型号 6 针接口有个别线序不同，功能应该没区别。

@Qetesh 我上全闪了，受不了硬盘爆豆子声。

@isukkaw 抱歉，原来 Sukka 本尊

@isukkaw Sukka 之前写过几篇来解释 DNS 相关问题，这也是我为何要把文章链接发出来，原文开头就 DNS 说明如下：

如果没有相关的知识储备，你在阅读本文时可能会难以理解分流规则和配置。你可以阅读我之前写过的 数篇关于 DNS 的文章，本文不会再做详细赘述。

Sukka (@isukkaw) 最近写了一篇 blog 更全面的论述了这个问题，用的 Surge ，Clash 很类似的。
https://blog.skk.moe/post/i-have-my-unique-surge-setup/

传统无线路由隔离 WAN 和 LAN 那种有个邪性解法：用网线把 WAN 和 LAN 连接，然后把光猫连到另一个 LAN 口，就是浪费 2 个 LAN 口。

你要仔细描述你的主路由的功能和角色。如果是隔离 WAN 和 LAN 的，就略微麻烦。如果是 RouterOS 这种就简单了，可以直接把光猫的 LAN 关闭 DHCP 后，和家庭 LAN 连在一起。

“A 侧网络是 192.168.10.0/23”，此处笔误是 192.168.10.0/24 。

实际上，我不觉得你的真实需求必须要二层互通，一般远程办公这种情况绝大多数应用三层互通就足够，有个别需要广播或者多播的，可以通过各种三层技术引入，比如 DHCP Relay 以及 ARP Proxy 和 IGMP Proxy 。

@cpstar #55 楼的截屏中 tcpdump 是另一次 dump 的结果，和 10.123 这次不一样，request from 的 mac 是不一样的，那次被屏幕滚动冲掉了。

@cpstar A 侧能通自然 B 侧也通，二层不考虑交换机的作用，本身就是广播的。从原理出发，不会质疑这个，只要解决自己哪里没做对就行。

A 侧网络是 192.168.10.0/23 ，B 侧是 192.168.1.0/24 ，这是 B 侧桥接 VLAN 下的另一台机器 ui （非 Zerotier 所在 ecs ）的 DHCP 的结果：

root@ui:~# dhclient -v eth4
root@ui:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 0a:4c:51:c4:9c:c8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.1.8/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
76: eth4@if77: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether da:0c:23:82:ad:de brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.10.123/24 brd 192.168.10.255 scope global dynamic eth4
valid_lft 691181sec preferred_lft 691181sec

root@ecs:~# tcpdump -i br0 -nn -l port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:41:57.970084 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:f7:33:3b:e8:29, length 300
11:41:57.983324 IP 192.168.10.8.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 315
11:41:57.984336 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 4a:f7:33:3b:e8:29, length 300
11:41:57.986453 IP 192.168.10.1.67 > 192.168.10.123.68: BOOTP/DHCP, Reply, length 315
11:41:57.991644 IP 192.168.10.8.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 315
11:41:57.998054 IP 192.168.10.1.67 > 192.168.10.123.68: BOOTP/DHCP, Reply, length 315

user@misc:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether xx:14:a7:xx:a7:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.10.53/24 brd 192.168.10.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
link/ether xx:30:xx:xx:32:f0 brd ff:ff:ff:ff:ff:ff
4: zth6123456: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
link/ether de:4d:9d:9f:10:7c brd ff:ff:ff:ff:ff:ff
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether be:c0:ff:fd:6d:72 brd ff:ff:ff:ff:ff:ff
user@misc:~$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.bec0fffd6d72 no eth1
zth6123456
user@misc:~$ sudo tcpdump -i br0 -nn -l arp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:18:41.845729 ARP, Request who-has 192.168.1.1 (b6:ff:16:xx:xx:80) tell 192.168.1.149, length 46
09:18:41.853347 ARP, Reply 192.168.1.1 is-at b6:ff:16:xx:xx:80, length 28
09:18:46.633253 ARP, Request who-has 192.168.1.118 tell 0.0.0.0, length 46
09:18:48.646430 ARP, Request who-has 192.168.1.1 tell 192.168.1.118, length 46
09:18:48.700308 ARP, Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.11, length 46
^C
5 packets captured

@cpstar Zerotier 创建的虚拟口就是 tap ，48#我写错了，tap 本身就是一个链路层的口，当你把它 bridge 到物理端口时，自然实现了二层互通，但是互通后你需要自己解决二层划分和使用的问题，比如 bridge 一个和 Home 原生网络隔离的 VLAN 。Zerotier 当然是基于三层，但是它自身是 VL1 ，那原理上就可以当 VL1 用，要按你的说法，运营商也没法跨区域做光交换专线了，而且有很多虚拟专线，都是 Ethernet over IP 。

我当然是实践后才这么说。没有收不到 DHCP 和 ARP 这些问题，文章说的 DROP 掉 UDP67/68 只是简单的让两个网络各自使用自己的 DHCP ，实际上如果你有用一个的需求，无需过滤这些包。另外可以把文章链接放出来，一起看看。

最后要说的是：只是你失败了！并不是原理不通。讨论修正理解不对的地方，找出自己配置不当，实现就完了。

上面的 tun 接口应该是 tap 接口，Zerotier 是把自己当成有透明三层防火墙的交换机，每个客户侧（非移动端）放置一个 tap 端口。

楼上很多回答对网络原理理解不足，勿在浮沙筑高台。比如说 Zerotier 是三层，Zerotier 是 VL1 好吗，Zerotier 结合自己的网络后，相当于有通明防火墙的网线。

Zerotier 的一对节点通了之后，这两个 tun 接口就相当于一根网线连接起来，有点像运营商给你做了一对专线（，相当于给你扯一根网线，不需要配置 IP ，二层互通就没有任何问题，是否配 IP 都是自己的选择，有点像交换机的端口，可以作为二层口，也可以作为三层口。但是接下来有问题：

1.为何要做二层桥接而不是三层路由？
Zerotier 官方文档说了自己是 V1 ，也是为了让链路层广播和多播通过，比如要用 AirPlay 之类，或者其他以来广播的协议，否则可以用三层，而且一般大多数人也是用三层的。如果要当连接链路层也要考虑广播流量通过互联网传输的负担。

2.二层联通后增么处理各自的原生网络？
如果要把 Office 和 Home 两个链路层通过一根线直通了，那 Home 原来的一些基于广播的协议自然要小心考虑，比如 DHCP ，二层联通后，只能在 Home 原生和 Office 原生二选一，要选择两个都用，只能走一些透明网关类的处理，或者用三层网络。如果选择了使用 Office 原生，由 OfficeDHCP 自然也不是问题。Zerotier 自身也在二层做了一个透明防火墙，可以用规则过滤。

明白以上的原理后，配置二层互通自然不是问题。

我的测试环境
c1(dhcp)-sw1-(eth1)s1(eth0)-r1(office)~~~~(home)r2-(eth0)s2(eth1)-sw2-c2
c2 作为 dhcp 客户端，从 c1 拿到 IP ，并且 c2 和 c1 互通

@cpstar Zetotier 等同网线，本身是 VL1 ，二层互通没有任何问题。DHCP 能过可通就说明不是通过其他三层通道。我做的最简环境，为了避免干扰 eth1 都放在 VLAN 里。OP 不熟悉，它也是用的 linux 设施，不通只能是配置原因，不是网络架构原理不支持。

@cpstar 晚上注册了 Zerotier ，做了测试。用两台 ubuntu ，eth0 是主网络，eth1 连接主网络或第二网络/VLAN 。br0 桥接 eth1 和 zth ，然后双向可通，Home 的内网机器从 Office 拿到 DHCP 。

Zerotier 不分主从，不可能单侧可通，另一侧不通。