由于我个人并不靠制作开源软件来吃饭，所以都是怎样宽松怎样来，原则就是“不要来打扰我”：

其他人用不用我的代码，我无所谓。
其他人如何使用我的代码、拿去干嘛，我不想知道。

fork 了我的代码改东改西然后 push 回来却发现有一大堆冲突行需要梳理，烦！
进而发现对方把许可证改得更严格了，对我问东问西，烦！

我不愿意限制他人如何使用我的代码，正如同不愿意被别人限制一样。不过，如果有办法对付“我就是要限制你”，那么我还是很乐意使用这类办法的。

@xxfye 主要是第一个破坏规则规范的人是谁，以及另一边的受影响方是否感知到、能否自己缓解 /化解。

在梯子技术中，第一个破坏规则的人并不是用户，于是用户们也只好用非规范的手段去做原先能直接做的事情。然而至少用户是知道这种“破坏规则”是存在的，尽管第一个破坏者自己没说话，但起码用户侧能很明显地感受到，并且用户可以自己去缓解、化解。

而到了这种“NAT 真假公网”的情形，第一个破坏规则规范的人依然不是用户自己，受到负面影响的却依然是用户自身（比如前面有人提到的玄学式的时而能连时而断开），稳定性反倒不如 NAT1 ，但用户给却毫不知情，以为是自己的问题。直到大家都见到 OP 转发的那张图，才惊觉原来是运营商和厂商使用了非规范措施导致自己连接变玄学，而自己此前一直不知情。
而且这种“故障”并不是自然形成的（例如线路受电磁干扰、光纤弯折过高、连接头没插稳、双方设备负载过高等等），而是故意引入的非规范设备的“后遗症”。
在这种情况下，作为用户，出现愤怒、发出声讨是很正常的。更何况，用户这一侧毫无缓解 /化解 /反击的措施。

解决问题的办法有很多种，并不是每一样都该赞的，毕竟有一些单纯只是“应付式”，表面上看解决了，实际上只不过是“堵住用户的嘴”。
举个例子。江苏广电为了“解决”IP 地址的不足，居然把 102.x.x.x 当成内网地址来用： https://www.v2ex.com/t/859490
能用吗？当然能用，也能算是“解决办法”的一种，然而就如同前面的“NAT 真假公网”一样，会带来风险与麻烦。
当然了，由于江苏广电这种做法带来的麻烦更为明显，并且违反规范的方式肉眼可见，实打实地造成用户无法访问 102.*的所有资源，更容易引起用户的察觉。

关键句来了：“并且用户短期重新拨号无法更换新 IP”

看来想要判断自己的公网是不是真·公网 IP 很简单，短期内多次断线重连，看看 IP 地址会不会发生改变就行了。
每次重连都会换新 IP 那就是原始意义上的公网 IP ，如果 IP 还是没变化那就是共享式公网 IP 。

@wuosuper 这样做的话，在我刚才提的假设当中，很大几率会露陷而被用户发现了。

@xxfye 那就来个现实的假设。

假设某个假公网（假设是 123.45.67.89 ）后面有 3 个 3389 （都是 Windows 远程桌面），那么外界某台机器发起请求，连接到 123.45.67.89:3389 的时候，应该连后面的哪台机器？

甚至会不会有这种可能：

当客户发现并确认公网 IP 无法接受传入连接，或者发现 RDP 、SSH 连接到的并不是自己的机器，于是再打电话询问运营商客服时，运营商才真正将该客户分配到真·公网 IP 的池子中。

造成冲突的可能性，对某些应用来说还是比较高的，例如 RDP 的 3389 ，还有 SSH 的 22 。

开启 Windows 的远程桌面其实一点都不罕见，对于部分非小白用户来说，公网 IP 有一个很重要的用途就是 RDP 。
很久以前我试过用 tcping 简单扫描我用着的 IP 的 /24 网段，发现开启 3389 的机器还真不少，有时能找到十几个。
用远程桌面连过去，确实能够连得上，有一些甚至是 Windows Server 。

万一同一个假公网 IP 后方刚好有两人甚至更多人开启了 3389 ，那就一定会造成冲突，而且很容易就被发现。包括 3390 也有可能会冲突，有些人会用端口映射把 3390 映射到另一台 Windows 的 3389 。

SSH 同理，基于 BSD 的或者 Linux 的设备（主要是软路由，还有一部分高端路由器）自带 SSH 服务，部分使用者会把 SSH 暴露到公网。

从理论上来说，VNC 其实也会有同样的冲突，只不过使用 VNC 的机器应该没 RDP 和 SSH 那么多。


除非 NAT4444 的那套设备能够针对性处理，发现有人开启了 SSH 、RDP 、VNC 就单独让这个人使用单独分配的公网 IP 。只有这样才能避免冲突。

OP 补充说 VSC 也有这种问题，于是我也特意试了下，发现并不会这样。

在桌面 1 打开了 VSC ，切换到桌面 2 新开一个 VSC ，一切正常，桌面 2 打开的 VSC 会在桌面 2 出现，不会在桌面 1 开启。

我用着的 Win10 版本：19044.1889

@mikeluckybiy
没错，IP 段跟 NAT 类型并没有必然的联系

@mxuan
NAT 类型是 NAT 类型，IP 段是 IP 段，具体采用哪种 NAT 类型那是运营商的设置选择。
如果运营商愿意，CGNAT 当然可以 NAT1 。只不过这轮不到普通用户指定就是了。

@ysc3839 不能跨文件复制粘贴，这就是另一件事了。

OP 问的是“请问有方法强制在当前窗口下打开”（当前桌面），那就先给他打开的办法。

@mikeluckybiy CGNAT 有专用的网段：100.64.0.0/10
如果运营商分配普通内网的 IP （也就是 10.0.0.0/8 、172.16.0.0/12 、192.168.0.0/16 ），很有可能会跟客户现有的内网 IP 段相重合，这样就会造成客户出现“无法上网”的故障。

尽管重合的可能性非常低（大多数家庭路由器默认网段几乎都是 192.168.x.x ），但谁能说这种巧合不会发生呢，总会有人会在内网使用 10.0.0.0 和 172.16.0.0 网段，一旦运营商给的 IP 段刚好重合了，那就会造成麻烦。

由于三大内网网段的定义时间比起 CGNAT 早得多，因此完全可以认为客户内网并不会使用 100.64.0.0/10 。
CGNAT 定义在 RFC 6598 ，2012 年 4 月。在此之前 100.64.0.0/10 是公网地址，也就是说，使用 100.64.0.0/10 网段并不会影响到客户现有内网的正常使用。这也是选择原公网网段作为 CGNAT 地址段的原因。

这是 MS Office 的问题，不是 Windows 的问题。

MS Office 的各个组成部分（ Word Exel 等等）在第一个窗口已经存在的情况下，用户再用双击文件图标的方式打开 Office 文件（包括 Excel ），默认会在已有的第一个 instance 当中打开，而第一个 instance 在哪个窗口，新打开的文件就会在哪个窗口出现。

所以解决办法很简单，让 Excel 启动另一个新的 instance 就行了。

方法有两种。
第一种，双击 Excel 文件后，立即按住键盘的 ALT 。这时候 Excel 会跳出一个对话框问你需不需要打开一个新的 instance （实例），点“是”，就可以在当前桌面打开新的文件。

第二种，直接让 Excel 打开新实例窗口，然后再用“打开文件”(CTRL+O)功能选取文件。
打开 Excel 新实例窗口又有好几种做法，任选一种：
1 —— Win10 左下角搜索框找到 Excel ，按住 ALT ，再点击“打开”；
2 —— Win10 左下角搜索框（或者 Win+R ），输入 excel.exe /r ；
3 —— 创建新的桌面 Excel 快捷方式，在 excel.exe 后面加上 /r 参数

要不试试打开编译选项 -parameters

既然已经有路由器，也许可以考虑下使用“4G / 5G USB 卡托”，插入到现有路由器的 USB 接口当作 WAN 口来用。

只不过这需要路由器支持才行

这个需求，本质上不就相当于双网卡服务器 /工控机做 Linux 软路由嘛。

对于 Linux 软路由而言，一般是 eth0 ↔ NAT ↔ eth1 ，其实就跟 tun0 ↔ NAT ↔ tun1 没什么本质区别。

把双网卡软路由的 NAT 方式（资料一搜一大堆，抄下来改改就行）套用到这个 tun0 和 tun1 就可以了。

如果不想手写 iptables 这么麻烦，甚至还可以安装个 OpenWRT 用来运行 easyconnect ，然后用 OpenWRT 自带的图形界面去配置 NAT 方向，应该会直观很多

NAS 噪音两大来源：风扇风声、硬盘共振。

风扇风声容易解决，用 DIY 装机思维就行——换风扇。或者一开始就选择风声不明显的套件。

至于硬盘共振，海绵条、橡胶圈能用尽量用，可以减轻共振。但也就只能减轻。
共振是会向承托物传递的，尤其是柜、箱，放在这上面会使共振传播出去，以至于共振噪声更加明显。

解决共振的终极办法其实很简单，用弹簧减震垫就行，已经在玄学音响界用了很多年。单就阻止共振传播的效果而言，那真的是非常好。

chiphell 就有讨论贴：
www.chiphell.com/forum.php?mod=forumdisplay&fid=53
（然而现在居然要密码才能看，上周还能直接打开的，那就自己搜存档吧，帖子标题：分享一个 nas 消除共振嗡嗡声的方法（非魔术贴） ）

我是看到了这个讨论贴才去买了一套试试的。它帮我消除了房间内最大的共振源。

实测发现（系统版本 Windows 10 19044.1889 ），Win32 版本的“截图工具”不会有这种事（我个人常用这个版本，其次是直接按 Print Screen ），只有 UWP 版本的“截图与草图”（不习惯用这个版本，因为不够灵活）才会有这种情况。

并且我观察到，在截图的那一刻，屏幕顶部确实也出现了那几个像素的横条（不一定是蓝色，跟系统主题设置有关），显然就是截图控件本身。

UWP 版截图的过程：按下“新建”→屏幕变暗→顶部出现截图控件→用户按下截图按钮(全屏幕)→截图控件消失→屏幕变亮，以系统主题色给屏幕蒙上一层半透明图层→稍等片刻→图层消失，画面变回原状→顶部出现控件像素条→截图完成。

这样看来应该是 UWP 版本的隐藏控件的代码有 bug ，捕获画面的时候控件不小心跳出来了，导致最后也捕获了进去

看到“String”的时候我就有疑惑，我记得 C 语言并不自带“string”类型（无论大小写），“string”也不是关键字。
https://en.cppreference.com/w/c/keyword

于是就用这些代码出现过的一些关键词去找资料（ Main_parseArgs 和 Main_USAGE ），看到了类似的代码：
https://stash.phytec.com/projects/MIRROR/repos/ipc-ipcdev/browse/linux/src/tests/Msgq100.c

再继续找它们的头文件，终于找到了源头：
https://stash.phytec.com/projects/MIRROR/repos/ipc-ipcdev/browse/linux/include/ti/ipc/Std.h

没错，就是来自于#include <ti/ipc/Std.h>里面的 typedef