ovgate/docs/FEASIBILITY.md

# 技术可行性分析

本文档是动手写代码之前的结论。所有判断都基于对 openvpn3 源码、VPNGate API 实测响应、
以及目标运行环境的实际验证，而不是推测。验证记录见文末「附录：验证方法」。

---

## 0. 结论速览

| 需求 | 判定 | 说明 |
|---|---|---|
| OpenVPN 3 Core 作为协议实现 | ✅ 可行 | 需以 `USE_TUN_BUILDER` 编译，走 TunBuilder 路径 |
| 无 root 用户态处理流量 | ✅ 可行 | socketpair + 用户态 TCP/IP 栈（lwIP） |
| VPNGate 节点列表抓取与解析 | ✅ 可行 | 实测 1.29 MB / 96 节点 / 最长行 13529 字符 |
| 多指标自动选节点 | ✅ 可行 | API 指标不可信，必须以本地实测为主 |
| 节点健康检查与自动重连 | ✅ 可行 | 分两层：隧道内重连 + 换节点 |
| SOCKS5 + 用户名密码认证 | ✅ 可行 | RFC 1928 / RFC 1929 |
| 1000 并发连接 | ⚠️ 有条件可行 | 本进程能扛住；**VPNGate 免费节点扛不住** |
| TCP CONNECT / 超时 / 半关闭 / 异常断开 | ✅ 可行 | — |
| DNS 不泄漏 | ✅ 可行 | 域名在隧道内解析 |
| SOCKS5 UDP ASSOCIATE | ✅ 支持（不支持 FRAG 分片） | 见 §5 |
| 换节点后**新**连接走新隧道 | ✅ 可行 | make-before-break |
| 换节点后**保持已建立的 TCP 连接** | ❌ **不可能** | 见 §1，这是本需求中唯一真正不可能的部分 |
| 换节点后保持 UDP association | ✅ 可行（意外收获） | 见 §5.3 |

---

## 1. 不可能的部分：已建立的 TCP 连接无法跨节点迁移

这是需求里唯一物理上做不到的事情，必须说清楚为什么，否则后面的设计无从谈起。

### 1.1 为什么不可能

一条 TCP 连接由四元组 `(src_ip, src_port, dst_ip, dst_port)` 唯一标识，**且这个四元组在
连接生命周期内不可变**。当我们从 VPN 节点 A 切换到节点 B：

1. 隧道内网 IP 变了。节点 A 通过 `push ifconfig` 给我们 `10.211.1.6`，节点 B 会给一个完全
   不同的地址。我们协议栈的 `src_ip` 随之改变。
2. 出口公网 IP 变了。对端服务器看到的来源地址从 A 的公网 IP 变成 B 的公网 IP。
3. 节点 A 上的 NAT 会话表项随隧道断开而销毁。即便我们伪造原 `src_ip`，B 也不会、也无法把
   包按 A 的映射发出去。

于是切换后我们发出的报文，在对端 TCP 看来来自一个陌生的四元组。对端的反应是
**丢弃（不匹配任何 TCB）或回 RST**，绝不会当作原连接的续传。这是 TCP 的设计本身，不是实现缺陷。

### 1.2 那些「能迁移」的协议为什么能

| 协议 | 迁移机制 | 为什么救不了我们 |
|---|---|---|
| MPTCP (RFC 8684) | 在新路径上加 subflow，用 token 关联到同一连接 | 需要**对端也支持**。公网上绝大多数服务器没开。且需要内核 MPTCP 栈 |
| QUIC (RFC 9000 §9) | 用 Connection ID 而非四元组标识连接，支持路径迁移 | QUIC 跑在 UDP 上。见 §5.3——这部分我们**确实能救** |
| SCTP multihoming | 连接绑定到地址集合 | 公网部署几乎为零 |

结论：对**普通 TCP**，无论在应用层做什么，都无法把一条已建立的连接搬到另一个出口 IP 上。
任何声称能做到的方案，要么是重新建连（破坏字节流语义），要么是没真正换出口。

### 1.3 我们实际能做到什么（工程解法）

需求里写了「如果做不到，那么断开所有旧连接」。直接全断是可以的，但太粗暴——正常网页浏览
场景下会造成明显可见的中断。本项目实现的是**优雅降级的三段式方案**：

**A. Make-before-break（先建后拆）**

新旧两条隧道**并存**一段时间。每条隧道是一个独立的 `Egress`（独立的 OpenVPN 会话 + 独立的
lwIP 协议栈实例）。

- 新的 SOCKS5 连接 → 绑定到新 Egress。
- 已存在的连接 → 继续留在旧 Egress 上，**完全不受影响**，直到自然结束。

旧 Egress 进入 `Draining` 状态：不再接受新连接，引用计数归零即销毁。

**B. 有界的排空窗口**

排空不能无限期，否则一条长连接（SSH、WebSocket）会让旧隧道永远留着。设 `drain_grace`
（默认 120s）。窗口内自然结束的连接是零感知的；窗口到期仍存活的连接被强制关闭——这就是需求
里说的「做不到就断开」，只是把「全部立刻断」缩小成了「少数超时的才断」。

同时并存的 draining Egress 数量有上限（默认 2），避免连续切换导致隧道堆积。

**C. 零进度连接可透明重试**

如果一条 SOCKS5 连接在切换发生时，`CONNECT` 还没完成、或者完成了但**双向都还没传输过任何
应用字节**，那么重建它对客户端是完全无感的——因为还没有任何字节流状态需要保留。这类连接
我们直接在新 Egress 上重连，客户端完全察觉不到。

实测中这能覆盖相当一部分场景（浏览器的预连接、连接池里的空闲连接）。

**代价（必须诚实说明）**：并存期间内存和 CPU 翻倍（两个 lwIP 实例、两个 OpenVPN 会话），
出口 IP 在窗口内不唯一（旧连接走旧 IP）。对于「出口 IP 必须唯一」的场景，配置
`switch.mode = hard` 退化为「立即全断」。

---

## 2. 无 root：为什么必须自带 TCP/IP 栈

### 2.1 环境事实

目标环境 `/dev/net/tun` **不存在**，进程 uid=1000。即便设备节点存在，`TUNSETIFF` 也需要
`CAP_NET_ADMIN`。所以：**拿不到 tun 设备，也无权改路由表**。

（备选路径 unprivileged userns + netns 见 §7，本项目不作为默认。）

### 2.2 openvpn3 能否把裸 IP 包交给我们

能，而且是官方支持的路径。关键证据在 `openvpn/tun/builder/client.hpp:59`：

```cpp
Base::stream = new openvpn_io::posix::stream_descriptor(io_context, socket);
```

`tun_builder_establish()` 返回的 `int` fd 被直接包进 **ASIO 的 POSIX stream_descriptor**，
之后按裸 IP 包做 `async_read_some` / `async_write`。这条路径上**没有任何 tun 专属的 ioctl**，
openvpn3 不关心 fd 究竟是不是 tun 设备——它只要一个能异步读写的 fd。

于是：

```
socketpair(AF_UNIX, SOCK_DGRAM, 0, sv)
  sv[0] ──► 交给 openvpn3（tun_builder_establish 返回它）
  sv[1] ──► 我们自己持有，接到 lwIP netif
```

选 `SOCK_DGRAM` 而非 `SOCK_STREAM` 是刻意的：**数据报边界天然等于 IP 包边界**，不需要任何
额外的长度前缀或分帧逻辑，也不会出现半个包的情况。

这条路径由 CMake 选项 `CLI_TUNBUILDER=ON`（即 `-DUSE_TUN_BUILDER`）启用，openvpn3 自带的
`test/ovpncli` 就是这么用的，在 Linux 上是被官方 CI 覆盖的。

**已对真实节点实测通过（非推断）**。用 `tools/tunnel_smoke.cpp` 对
`public-vpn-113@219.100.37.100:443/tcp` 跑了一次完整会话，uid=1000、无 root、无
`/dev/net/tun`：

```
tunnel up: ip=10.239.88.225/30 gw=10.239.88.226 mtu=1500
           dns=[10.239.254.254, 8.8.8.8] redirect_gw=true routes=0
tx: 手工构造的 IPv4+ICMP echo → 8.8.8.8
rx #1: IPv4 8.8.8.8 -> 10.239.88.225 ICMP len=44 (wire 44)
共 6 个 echo reply，tx=7 pkts/308 B (dropped 0)，退出码 0
```

三个结论就此从「设计假设」变成「已验证事实」：

1. openvpn3 接受 socketpair 的 fd，全程没有任何 tun 专属 ioctl；
2. **收到的是裸 IPv4，没有 4 字节 `tun_prefix` 框架头**——`len=44 (wire 44)`
   即 IP 首部里的 total length 与数据报长度逐字节相等，多一个前缀就会是 48/44；
3. 数据报边界确实等于 IP 包边界，读侧不需要任何分帧逻辑。

失败路径同样验证过：已死的节点走 RECONNECTING → RECONNECTING →
`down: CONNECTION_TIMEOUT`，状态机与 fd 回收都干净。

> **UDP 传输未能在本沙箱内实测。** 4 个 VPNGate UDP 节点全部 `CONNECTION_TIMEOUT`；
> 但同环境下向三台公网 NTP 服务器（UDP/123）发包也全部超时，而 DNS（UDP/53）正常。
> 判定为**沙箱只放行 UDP/53**，而不是 UDP 代码路径有问题——两者在本机无法区分。
> 影响有限：样本 96 个节点里仅 8 个提供 UDP，TCP/443 是绝大多数节点的唯一入口。

### 2.3 由此带来的简化

因为我们从不碰宿主机路由表：

- `tun_builder_add_route` / `tun_builder_reroute_gw` 全部**记录日志后返回 true**，不做实际动作。
  隧道内的「默认路由」由我们自己的 lwIP 实例定义——它只有一个 netif，天然全部流量走隧道。
- `socket_protect()` 直接返回 true。它的用途是防止 VPN 自己的传输 socket 被路由进隧道造成环路；
  我们没改宿主路由，不存在环路。
- 不产生 DNS 泄漏风险的系统级配置改动（`/etc/resolv.conf` 一律不碰）。

**副作用**：本进程是一个纯粹的 SOCKS5 网关，**不会**把宿主机其它程序的流量导入 VPN。这符合
需求（对外提供 SOCKS5 服务），但要明确它不是一个系统级 VPN 客户端。

### 2.4 为什么是 lwIP

需要一个用户态 TCP/IP 栈。候选：

| 方案 | 语言 | 判断 |
|---|---|---|
| **lwIP** | C | ✅ 选用。成熟、BSD 协议、可嵌入 C++、被 tun2socks/hev-socks5-tunnel 大规模验证 |
| gVisor netstack | Go | 性能更好，但引入 Go 运行时和跨语言边界，与 C++ 的 openvpn3 拼接成本高 |
| smoltcp | Rust | 同上，且 no_std 取向，功能面偏窄 |
| 自己写 | — | 不予考虑 |

lwIP 的已知短板（§4 展开）：它是嵌入式栈，默认配置扛不住 1000 连接，必须重新配参数。

关键点：**我们是连接的发起方**，不是 tun2socks 那种「拦截别人的连接」。所以不需要
`LWIP_HOOK_IP4_INPUT` 之类的劫持技巧，直接用 raw API 的 `tcp_new` / `tcp_connect` 即可，
复杂度显著低于典型 tun2socks 实现。

---

## 3. VPNGate 的真实情况

### 3.1 API 格式（实测）

`http://www.vpngate.net/api/iphone/` 返回：

```
*vpn_servers
#HostName,IP,Score,Ping,Speed,CountryLong,CountryShort,NumVpnSessions,Uptime,TotalUsers,TotalTraffic,LogType,Operator,Message,OpenVPN_ConfigData_Base64
public-vpn-113,219.100.37.100,3008408,10,287135107,Japan,JP,113,...,IyMjIyMj...
...
*
```

实测数据：响应 1.29 MB，99 行（1 行 magic + 1 行表头 + 96 行数据 + 1 行 `*` 结束符），
**最长行 13529 字符**。

「每行可能非常长」的根因：第 15 列是**整个 .ovpn 配置文件的 base64**，含内联 CA 证书、
客户端证书和私钥，单行轻松过 10 KB。

对解析器的硬性要求：

- 不得使用固定大小的行缓冲区。必须流式或动态增长。
- `Message` 和 `Operator` 列包含**自由文本**，实测有内容为
  `Daiyuu Nobori_ Japan. Academic Use Only.` 的行——注意其中的 `_` 是 VPNGate 对逗号的转义
  替换，但不能假定所有行都被正确转义，必须按 RFC 4180 处理引号，并对**列数不足的行直接跳过**
  而不是崩溃。
- 必须容忍 `Ping` / `Speed` 为空字符串。

### 3.2 节点配置的真实内容（实测解码第一个节点）

```
dev tun
proto tcp
remote 219.100.37.100 443
cipher AES-128-CBC
data-ciphers AES-128-CBC
auth SHA1
resolv-retry infinite
nobind
persist-key
persist-tun
client
verb 3
<ca>...</ca> <cert>...</cert> <key>...</key>
```

重要结论：

1. **不需要用户名密码**。配置内联了客户端证书和私钥，是纯证书认证。（部分老节点需要
   `vpn`/`vpn`，代码里保留了 fallback。）
2. **`proto tcp` + 443 端口**。这意味着 **TCP-over-TCP**——隧道内的 TCP 跑在隧道外的 TCP 上。
   两层拥塞控制叠加，丢包时会互相放大重传，即所谓 TCP meltdown。缓解手段：把 lwIP 的
   `TCP_MSS` 调低避免分片、开 SACK、限制内层窗口不要过分激进。**这是免费 VPNGate 的固有
   特性，不是我们能修复的**，只能缓解。同一节点若同时提供 UDP 入口应优先选 UDP。
3. **`AES-128-CBC` + `SHA1`**。都是弱算法。openvpn3 在较新版本里默认拒绝部分遗留算法，
   需要显式开 `enableLegacyAlgorithms` / `tlsCertProfileOverride=legacy`，否则握手直接失败。
   较新的 VPNGate 配置已经带了 `data-ciphers`，所以 NCP 协商能正常工作。
4. 节点跑的是 SoftEther 的 OpenVPN 兼容层，不是原版 openvpn 服务端。行为上有偏差，
   profile 需要做净化/重写（去掉 openvpn3 不认识的指令，补上必需的指令）。

### 3.3 API 指标可信度

`Score` / `Ping` / `Speed` 是 **VPNGate 中心服务器**到节点测出来的，不是**我们**到节点。
地理位置一变，排序完全失效。`Speed` 那个 287135107（≈287 Mbps）是节点自报的线路带宽，
不代表你能分到多少——`NumVpnSessions=113` 意味着 113 个人在抢。

因此选点策略必须以**本地实测**为主：我们自己对候选节点的 OpenVPN 端口做 TCP 握手计时，
API 指标只用于**初筛和排序前的先验权重**。详见 `ARCHITECTURE.md` §选点。

---

## 4. 1000 并发：能到什么程度

拆成三个独立的瓶颈来看。

### 4.1 本进程（可控）

- **不能一连接一线程**。1000 线程 × 8 MB 默认栈 = 8 GB 虚拟内存，上下文切换开销也不可接受。
  本项目用 ASIO 的 proactor 模型，`min(hardware_concurrency, N)` 个 io 线程跑事件循环，
  每条连接是一组 handler + 一个 strand，**零专属线程**。
- **fd 消耗**：每条 SOCKS5 连接占 1 个客户端 fd。出口侧走 lwIP，**不消耗 fd**（这是用户态栈
  的一个实在好处）。1000 连接 ≈ 1000 + 少量固定 fd，默认 `ulimit -n 1024` 不够，启动时程序
  会自己把 `RLIMIT_NOFILE` 提到 soft=hard 并在不足时告警。
- **内存**：每连接两个方向的中继缓冲（默认 32 KB 合计）+ lwIP 的 PCB 与重组队列。
  1000 连接 ≈ 32 MB 中继缓冲 + lwIP 开销，量级在 100–200 MB。可接受。

### 4.2 lwIP（需要重新配置，且是真实风险）

lwIP 的默认配置是给 MCU 用的，`MEMP_NUM_TCP_PCB` 默认 **5**。直接用必然崩。本项目的
`lwipopts.h` 做了如下调整：

- `MEM_LIBC_MALLOC=1` + `MEMP_MEM_MALLOC=1`：所有 memp 池改走 libc malloc，
  **彻底绕开静态池容量规划问题**。代价是失去池化的确定性和一点性能，换来的是不会因为某个
  池耗尽而莫名其妙丢包。对我们这种「不是硬实时、但要求鲁棒」的场景是正确的取舍。
- 既然内存不再有硬上界，**准入控制必须由我们自己做**：`socks5.max_sessions`（默认 1200）
  在 accept 层直接拒绝超限连接，这是防 OOM 的唯一闸门。
- `LWIP_WND_SCALE=1` + `TCP_RCV_SCALE=2`、`LWIP_TCP_SACK_OUT=1`：VPN 链路 BDP 大且有丢包，
  没有窗口缩放和 SACK 会严重拖垮吞吐。
- `TCP_MSS=1360`：保守值，避开隧道 MTU 导致的分片。

**诚实的风险提示**：lwIP 是单线程栈，所有连接的协议处理串行在一个线程上。1000 条**高吞吐**
连接会让这个线程成为瓶颈。1000 条**普通**连接（大部分时间空闲，如浏览器场景）没有问题。
如果需求真是 1000 条满速并发，lwIP 会先于 VPN 节点成为瓶颈，届时应考虑换 gVisor netstack
或多 Egress 分片。架构上 `Egress` 是接口，替换栈实现不影响上层。

### 4.3 VPNGate 节点（不可控，且是真正的天花板）

这是必须直说的部分：**一个免费的 VPNGate 节点几乎不可能支撑 1000 条并发连接**。

- 节点是志愿者用家用带宽跑的 SoftEther，实测样本里单节点已有 113 个并发会话在共享带宽。
- SoftEther 对单会话的连接数和 NAT 表项有限制。
- `proto tcp` 意味着我们所有流量还要挤在**一条**到节点的 TCP 连接里（openvpn3 单传输连接），
  这条连接的拥塞窗口是全局共享的。

所以「1000 并发」的合理解读是：**本网关的架构和实现能处理 1000 条并发连接而不劣化**，
至于端到端能跑多少，取决于当时选中的节点。程序会导出 `active_sessions`、
`connect_failure_rate`、`egress_rtt_ms` 等指标，节点扛不住时健康检查会触发换节点。

---

## 5. SOCKS5 相关的明确表态

### 5.1 UDP ASSOCIATE：**支持**

明确回答需求里的问题：**支持 SOCKS5 UDP ASSOCIATE**（RFC 1928 §7）。实现要点：

- `UDP ASSOCIATE` 请求到达后，在本地绑定一个 UDP socket 接收客户端数据报，
  同时在 Egress（lwIP）里开一个 UDP PCB 作为出口。
- 回复的 `BND.ADDR`/`BND.PORT` 使用可配置的 `socks5.advertise_addr`——不能想当然填
  `0.0.0.0`，客户端需要一个**它能到达**的地址。这在容器/NAT 部署里是个常见坑。
- association 的生命周期绑定到那条 TCP 控制连接。控制连接一断，UDP 立即回收（RFC 要求）。
- 空闲超时独立计时（默认 60s），防止客户端不关控制连接导致 PCB 泄漏。

**不支持的部分（明确声明）**：`FRAG != 0` 的分片数据报**直接丢弃**。RFC 1928 允许实现不支持
分片。理由：分片重组需要维护跨数据报状态且极易被用于放大攻击，而现实中几乎没有客户端使用
（curl、Chrome、SSH -D 都不用）。丢弃时会打 warn 日志并计数，不会静默。

### 5.2 DNS

域名解析**在隧道内完成**，不泄漏：

- `CONNECT` 请求的 `ATYP=DOMAINNAME` 不在本地 `getaddrinfo`，而是走 `Egress::async_resolve`，
  即通过 lwIP 的 UDP 向 VPN 服务器 push 下来的 DNS 服务器发查询。
- 自带解析器而非用 lwIP 内置 `dns_gethostbyname`：需要 TTL 感知的缓存、并发去重、
  UDP 截断后回落 TCP、以及跨 Egress 实现复用（DirectEgress 也要能用）。lwIP 内置 DNS 这些都没有。
- 若 VPN 未 push DNS，回落到配置的 `dns.fallback_servers`（默认 1.1.1.1 / 8.8.8.8），
  **仍然走隧道发出**，不走宿主机。
- 走 UDP ASSOCIATE 的 53 端口流量天然也在隧道内，无需特殊处理。

### 5.3 意外收获：UDP association 可以跨节点迁移

§1 说 TCP 不能迁移。但 **UDP 可以**，因为它无连接——没有需要保留的序列号状态。

节点切换时，对于每个存活的 UDP association，我们只需在新 Egress 上重新 bind 一个 UDP PCB，
**保持面向客户端的那个 socket 和端口不变**。客户端完全无感。

对于 QUIC 这类自带连接迁移（RFC 9000 §9，用 Connection ID 而非四元组标识连接）的协议，
它会自己完成路径验证并继续跑——也就是说，**通过我们的 SOCKS5 代理的 QUIC/HTTP3 连接
能够真正做到跨 VPN 节点切换而不中断**。这是 TCP 拿不到的待遇。

代价：出口 IP 变化会让部分服务端（把 UDP 会话绑定到源 IP 的）判定为新会话。这个由应用层
自己处理，代理层无能为力。

### 5.4 不实现的部分

- `BIND` 命令：明确回 `X'07' Command not supported`。它需要在出口侧监听端口等待入站连接，
  而 VPNGate 节点在 NAT 后面，根本收不到入站连接。实现了也不能用。
- GSSAPI 认证（RFC 1961）：不实现，回 `X'FF'`（无可接受方法）。
- SOCKS4/4a：不实现。

---

## 6. 其它已识别的工程风险

| 风险 | 影响 | 缓解 |
|---|---|---|
| openvpn3 `connect()` 是阻塞调用 | 每条隧道需独占一个线程 | 每个 Egress 一个 ovpn 线程；切换期间峰值 2 个。可接受 |
| 节点 profile 含 openvpn3 不识别的指令 | 直接 `option_error` 连不上 | `ProfileSanitizer` 白名单重写，见 `ovpn/profile_sanitizer` |
| 弱算法被新版 openvpn3 拒绝 | 握手失败 | 显式 `enableLegacyAlgorithms=true` + `tlsCertProfileOverride="legacy"` |
| VPNGate API 限流 / 被墙 / 返回 HTML | 拿不到节点列表 | 磁盘缓存 + 多镜像 + 指数退避；缓存可用时不阻塞启动 |
| 隧道内 MTU 与实际路径不符 | 大包黑洞 | `TCP_MSS` 保守取值 + 采纳 `tun_builder_set_mtu` |
| 切换风暴（反复横跳） | 连接持续被打断 | 迟滞判定 + 最小切换间隔 + 候选必须显著更优才切 |
| socketpair 数据报队列满 | 丢 IP 包 | 放大 `SO_SNDBUF`/`SO_RCVBUF`；丢包由 TCP 重传兜底（这是 IP 层，允许丢） |
| lwIP 单线程瓶颈 | 高吞吐时吞吐受限 | 见 §4.2；架构上可替换 |

---

## 7. 备选方案：unprivileged userns + netns（未采用）

有 root 或允许非特权 user namespace 时，还有一条路：

```
unshare -Ur -n  →  在新 netns 里拥有 CAP_NET_ADMIN  →  创建真 tun 设备  →  用内核 TCP/IP 栈
```

优点很实在：内核栈的性能、成熟度、可观测性（`ss`、`tcpdump`）都远超 lwIP，1000 并发毫无压力。

不采用的原因：

1. 目标环境 `/dev/net/tun` **不存在**，这条路直接堵死。
2. 需要 mount namespace 配合 bind-mount `/dev/net/tun`，部署复杂度陡增。
3. SOCKS5 监听端口在宿主 netns、出口 socket 在 VPN netns，需要跨 netns 传 fd（`SCM_RIGHTS`），
   引入一个 helper 进程。
4. 很多容器环境（无 `CAP_SYS_ADMIN`、seccomp 限制 `unshare`）里不可用。

架构上 `Egress` 是接口，将来要加 `NetnsEgress` 不影响任何上层代码。这条路**留了口子但不修**。

---

## 附录：验证方法

本文所有事实性断言的来源：

```bash
# 环境
uname -a; id; ls -l /dev/net/tun          # → 无 tun 设备，uid=1000

# VPNGate API 实测
curl -s -o /tmp/v.csv -w '%{size_download}' http://www.vpngate.net/api/iphone/
#   → 1293288 bytes
awk '{if(length($0)>m)m=length($0)}END{print m}' /tmp/v.csv
#   → 13529
# 解码第 1 个节点的 base64 配置 → 见 §3.2

# openvpn3 tun builder 路径
git clone --depth 1 https://github.com/OpenVPN/openvpn3
grep -n 'stream_descriptor' openvpn/tun/builder/client.hpp
#   → :59  Base::stream = new openvpn_io::posix::stream_descriptor(io_context, socket);
cmake -S . -B build -G Ninja -DCLI_TUNBUILDER=ON && cmake --build build --target ovpncli
#   → 编译成功，0 warning

# socketpair-as-tun：对真实节点的端到端验证（§2.2）
cmake -S . -B build -DOVG_WITH_TUNNEL=ON && cmake --build build --target ovg_tunnel_smoke
./build/src/ovg_tunnel_smoke --node public-vpn-113 --ping 8.8.8.8 --seconds 15
#   → tunnel up 10.239.88.225/30；6 个 ICMP echo reply；exit 0

# 沙箱 UDP 出网能力（解释为何 UDP 节点无法实测）
#   DNS  8.8.8.8:53   → 56 字节应答，正常
#   NTP  216.239.35.0 / 129.6.15.28 / 162.159.200.1 :123 → 三个全部超时
```

依赖版本：openvpn3 master（2026-07 快照）、lwIP 2.2.1、OpenSSL 3.5.6、lz4 1.10.0、
fmt 10.1.1、ASIO 1.30（standalone）、GCC 14.2 / C++20。