楼主的问题可以参考 https://github.com/linux-surface/linux-surface 里面有 surface 各硬件的内核驱动支持，SGO2 算是比较完善的，选一个方便切换内核的发行版就可以了。考虑到硬件平台比较久远了，桌面平台使用 xfce 这种轻量型体验会比较好，硬核一点可以 i3/sway 来自定义。

因为你这个做法很不常见，我猜测可能是 XY 问题导致的偏差，所以特地去看了你的使用场景。

这里我引用一下"为什么要搞 IP 保护"的描述："暴露的端口会被探测"，看到这里我就理解你的需求了。

本质上你是在保护自己的 IP 资产，而不是客户，客户只是租用而已。因为你以虚拟机的形式为客户交付服务，并不能控制客户在虚拟机上的行为，比如客户可以在在这个公网 IP 上开放公开的 http/socks 服务等等。

怎么向客户描述这个问题不重要，但是你的思路被带偏了，甚至说你的整体产品架构思路都被带偏了。当然这只是我个人的想法，可能理解有偏差。

如果我来设计的话，向客户交付的部分其实是 B ，而 A 是由自己完全控制的，A 是 B 的路由器。技术层面，B 本身就是云服务，利用 VPC 保证 B 的所有出站流量都一定由 A 路由就可以了。

这样做的附加好处是，所有 A 节点都可以用低成本标准化的网络设备完成，无需托管真实主机，至于 B 完全可以利用云服务来提供定制。

直接说结论：

如果 A 的防火墙是类似于 `iptables -t nat -A PREROUTING -s 2.2.2.2 -j ACCEPT` 的形式，那就无法通过 NAT 的形式做端口映射。

做全端口映射的原理就是楼上说的 DMZ ，转换成 iptables 规则就是 B 作为 A 的网关，对出流量做 SNAT ，对入流量做 DNAT 。

但是 A 的防火墙规则限制了来源只能是 B ，那 B 要对入流量同时做 SNAT ，修改其来源 IP 为 B 2.2.2.2 ，这就导致 A 认为请求来源都是 B ，回复的 DstIP 都是 B 2.2.2.2 ，因而无法正常返回数据。

解决的办法是：

1. B 以反向代理（ reverse proxy ）的形式工作，这样 A 可以保留防火墙规则。但反向代理对于协议有限制，tcp/http 类可以，udp 很难。

2. A/B 各自增加一个网络接口，两个接口之间建立某种点对点链路，然后走 NAT 映射

直接说结论：如果 A 的防火墙

OP 发了不少帖子了，一直想证明前端利用 wasm 做混淆很难破解。这个结论本身没问题，你要逆向 wasm 的内部逻辑就要走汇编调试那一套。只靠单纯的前端技术应付不了，但是在做逆向的人眼里，没什么区别。

这里大部分回复的都是在说，wasm/js 的交互机制决定了，多数时间把 wasm 当黑盒，用 RPC 方式调用就好了。没有必要去理会内部实现。

这里讨论的隐藏前提是用混淆手段防机器人的，基于加密参数限制非 web 客户端对于后端 api 的调用。

然后 OP 提出，这个加密逻辑全生命流程只能执行一次。说实话我想象不到这样的代码的应用场景，特别是防机器人的方面。（比较接近的是类似微信读书，原始 html 用 canvas 重渲染然后删掉原始数据）

对于 RPC 调用的应对，OP 认为可以在 wasm 内部做针对外部环境的检测。这一点我从根本上就不认同。

因为从根本上，客户端就不是可信的运行环境。别说浏览器了，手机 app 为什么都要做 root 越狱检测，都是一样的道理。这是个技术之外的哲学问题，你能判断自己是不是生活在虚拟世界里吗？

至于实践方面，我是比较赞同 @tool2d 的，基于虚拟机的混淆，模糊掉控制流和调用逻辑，给逆向的人造成的烦躁感远比 wasm 大多了。

而且虚拟机类型的混淆是可以高度自动化的，你可以每天都变换生成参数和算法。然而逆向虚拟机类混淆是没有什么自动化手段的。

做得挺好的啊。

请问 http3/quic 抓包路线图计划吗？这个功能虽然和 http 1/2 列在一起，但完全没法复用已有的功能框架，而且实现这个功能需要程序外做很多工作。

因为我自己前两个月就在写 quic mitm 的 poc ，还是非常麻烦的，而且现在 quic 各个实现之间 interop 还不是很理想。如果 op 这边能做个商业成品就最好了。

@hsuehliuyang 这和有没有自信没关系啊。

前段混淆无非就是防君子、小人和机器人。第一个网站的业务，显然不是防君子防机器人，防小人也用不着，因为没有一点东西是自己的。

但是你看它用伪造的 png 头假装图片跑视频流，然后用某站的缓存漏洞托管自己的播放列表文件，这种手段水平，想加个 js 混淆太容易了。

它真想藏的大概不是 url 而是流量。

@hsuehliuyang 这和有没有自信没关系啊。

前段混淆无非就是防君子、小人和机器人。第一个网站的业务，显然不是防君子防机器人

RPC 对于没有混淆的代码来说很好用。


@hsuehliuyang 过 debugger 方法太多了，浏览器内的话方法重载、条件断点、源文件 overrride 都行。浏览器之外的话，重编译一个修改了 js 引擎 debugger 方法的版本。