这种情况适宜从整体项目 build 的角度考量，有工程上的设计和考量。如果语言本身没有反射机制，一般用脚本或其他自定义工具，在 Pre-build 阶段生成函数的桩，同时对参数和调用场景做必要的安全检查。这样对于函数实现代码，只要做好必要的标注，就和 C#没什么区别了。

@Alchemistxxd 我的场景都是低性能应用，还没遇到过机器到满载的场景。根据风量数据，我觉得压不住。

V1 和 V2 是一样的，也是这几个选项。原来你是用最小输出来控制输出占空比。

我测的是 Gen10 V1 ，看网络 Gen8 是一样的，V2 有可能换成正常信号的风扇。我用的 NF-A8 PWM ，查了风扇规格，流速是原装扇的 1/3 ，风压只有 1/10 。目前信号的 10 ～ 20%映射到猫扇的 50 ～ 100%，噪音还好，另外一路用来压一下 iLO 芯片。

看你描述 V2 的 iLO 里，可以控制风扇输出了吗？ V1 只能设置最小输出，以及四个策略。

@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 端口。