如果你用过 wireguard 和 OpenVPN 之类的虚拟网卡 VPN ，并且在这些 VPN 连接完成后看过路由表，就会发现他们的做法跟你的一样，专门针对远程服务器 IP 单独设一条路由，走原先的路径。断开连接后，再恢复回去。
每切换一次远程节点，都要更新一次路由表。

所以，既然选择了虚拟网卡的方式，那么更新路由表并没什么不妥。

要不试试双显示器

1L 的办法很稳、可靠，我也是那样的布局方式

4K + DPI 200%，效果：
https://telegra.ph/Windows-10%E4%BB%BB%E5%8A%A1%E6%A0%8FQuick-Launch-06-17

小图标模式会继续使用 1080p 版本的大小，大图标模式可解，无文字+大图标可以完美对齐。

用高校的镜像站，速度快很多。
特别是清华大学，几乎是最快的

那就用以前梯子那套玩法，kcptun --mod fast3 --tcp ，即暴力发包 + TCP 欺骗

这排版看得有点绕……

重新整理了下：

1 、PC1-2.5G 交换机-爱快-光猫 890M
2 、PC1-2.5G 交换机-openwrt 网关-爱快-光猫 890M
3 、PC1-2.5G 交换机-openwrt iperf3 测试 上下行单线程都跑满 2.37G
4 、PC1-光猫直拨 890M
5 、PC1-K2P-光猫 890M
6 、PC1-2.5G 交换机-PC2 iperf3 940M
7 、替换成千兆交换机结果差不多
8 、PC2 重复上面测试结果与 PC1 差不多
9 、一加 9PRO-XDR5480-2.5G 交换机-爱快-光猫，940+m
10 、一加 9PRO-XDR5480-2.5G 交换机-openwrt 网关-爱快-光猫，940+m
11 、一加 9PRO-XDR5480-2.5G 交换机-openwrt iperf3 1.6G
12 、一加 9PRO-XDR5480-2.5G 交换机-PC1 1.6G


看起来是以太帧大小的原因。PC1 和 PC2 试下开启巨型帧(Jumbo Frame)，速度应该可以再多几十 M 。
从测速结果来看，中间的路由器和光猫应该已经默认开启了巨型帧，但 PC 没启用。
标准帧 1.5KB ，巨型帧 9KB ，标准帧的“损耗”相对会多一点。

具体的效率可以看这里： https://shorturl.at/kyCP3
里面说标准帧效率 94.93%，巨型帧效率 99.14%
所以从表面上来看，似乎是以太帧大小的原因

造成无法访问的原因是双重 NAT ，换句话说，是因为双重内网。

所以解决办法也很简单，在 pfsense 那里打开端口映射，把 NAS 映射到某个端口上，然后 VPN 回家时访问 NAS 就使用映射的端口。按照你的情况，那就是连回家后访问 192.168.1.x:port 。x 是 pfsense 在 RouterOS 侧获得的 IP 地址，port 是映射后的端口。

还有另一个解决办法，那就是扔掉 RouterOS 这个节点。pfsense 本身就可以拨号，也能开启 wireguard ，让 pfsense 全盘接管就行了。

@sunnysab 服务器端默认支持 http/3 的有 LiteSpeed （ 2021 年开始支持）和最新版 IIS （自 Windows Server 2022 起），Cloudflare 也提供了 http3 支持，再加上 Google 自己就在用，覆盖范围不小。
小提示：不少虚拟主机商（托管网站的那种，不是指 VPS ）默认 Web 服务程序用的是 LiteSpeed 而不是 nginx 。

现在的 Firefox 是支持 HTTP3 的，已经默认开启，至少 Windows 版本是这样。

我见过还有这样的：Dev / UAT / Pre-Prod / Prod

@cnbatch Vultr 自己说是 outbound ports 屏蔽，但实测下来表现为双向，估计他们的做法是，这几个端口的出站包全都一律丢掉，于是无论主动发起还是被动连接，这条连接都无法建立起来。

@documentzhangx66 那大概率是 SMB 相关端口（比如 445 ）被中间某个运营商屏蔽了

我在 Azure 美区开了台 Win10 机器测试了下，发现是可以直连的，我家里的 Windows 7 机器试了下可以连过去（家里用电信宽带）
https://telegra.ph/%E5%85%AC%E7%BD%91Windows-10%E5%BC%80%E5%90%AFSMB-06-08

除了各种文件操作反应相对比较慢，但确实能连得上，包括远端创建了文件夹也能反映出来
也许香港节点的表现会更好，毕竟近得多了。但鉴于费用原因我没进一步试验……

在这个过程中我顺便试了下用 Vultr 创建虚拟机连过去试验，发现连接不上，事后一查 Vultr 文档，发现果然屏蔽了 SMB 的端口
https://www.vultr.com/docs/what-ports-are-blocked/
而且是双向屏蔽

我家报装的电信网络是单方面屏蔽 SMB 端口，路由器上开 iperf3 监听 445 端口，外面怎么连都连不上，换成监听 442 一点问题都没有，很顺畅。连接别人的 SMB 端口一切正常，只要对方运营商没屏蔽的话。

小补充：
SMB 通道两侧的机器里的“出站规则”中，跟入站规则同名的设置项也可以设成“任意 IP 地址”，应该可以更好地提高连通率（针对一边公网 IP 另一边私网 IP 且中间没有端口屏蔽）

@documentzhangx66 其实公网 IP 也能连，只不过需要在“高级安全 Windows Defender 防火墙”里面放行（文件和打印机共享）。

入站规则的“文件和打印机共享(SMB-In)”（“配置文件”为“专用，公用”的那一行），打开后点击“作用域”，就可以看到“远程 IP 地址”限制为“本地子网”和三大内网 IP 段，这时候只需要选成“任何 IP 地址”就可以通行了。

如果有必要，还可以把“文件和打印机共享(NB-Name)”、“文件和打印机共享(NB-Session)”都同样设置一下。


然后还有一个情况会导致以上设置无效，部分运营商会屏蔽 445 端口（这下就不止屏蔽 80 和 443 端口）：
https://www.zhihu.com/question/41426264/answer/2389779158
这种情况下，无论怎么设置都无法通过公网去访问

@heiher udp2raw 也许可以？

首先搞清楚光猫获取的 IPv6 前缀是多少（以 IPv4 的思维去理解，就是“子网掩码”）。如果这个数值是 64 甚至更高（ 65~128 ），那其他设备分配不了 IPv6 的话，并不奇怪。

还有，对于以上这两种情况，就算把那些账号踢出去，黑客们、或者雇佣这群黑客的团体，还可以发布阴谋论说，“他们踢了这些人出去但却没有删除消息，显然是因为无法否认，并且管理层存在严重的内斗”，接着大说特说，那影响和危害只能更加严重。不要指望普通大众能懂 Github 的规则，他们甚至都未必听说过 Github 这个网站。z

@sorakylin 真的跟组织无关？那就大意了。

如果黑客发布的不是黄图，而是散布有关公司的谎言，例如什么“CEO 宣布辞职”、“我们的产品在发布二进制包时其实故意留了后门”、“某某经理其实是某某国家派来的间谍，我有证据如下”……之类的，那杀伤力可大可小，对于上市公司而言很可能一下子就股价下跌，连续发酵好几天。

至于 Owner 账号被盗，就算权限方面实现了你所说的做法，杀伤力并不会有所减少，甚至更惨。比如被盗的 Owner 把黑客的各个小号弄进组织，踢走真正的员工，然后在这些小号里大批量发布假消息。公司的人重新夺回 Owner 账号后，却无法删除那些假消息，只能干瞪眼着急。

考虑下这个场景：
组织某个成员的 Github 账户被黑客盗取了密码，这个黑客浏览一番后发现组织的各个仓库都没什么感兴趣的内容，于是就开了个恶意玩笑，新建仓库，把一些黄图黄片放在仓库内，还设成了公开可见。弄好后，还准备在其他论坛、新闻网站广而告之，使这件事变成公共丑闻。
而就在黑客创建仓库时，其中某个组织管理者刚好发现了异常情况。为了紧急灭火应该怎么做？一般人想到的都会是立即删了这个新仓库。
如果组织管理者无法删除仓库，又不能强行转移 owner ，只能踢出去……好吧，这件事铁定变成公共丑闻。