一个轻量且快速的UDP到TCP混淆器。
自2023年起，Rust 仅对基于 MIPS 的平台提供 Tier 3 支持。Phantun 的 MIPS 版本因此使用 nightly Rust 工具链构建，并仅在尽力而为的基础上提供。
Phantun 是一个将 UDP 数据包混淆为 TCP 连接的项目。它旨在以最小的处理和封装开销实现最大性能。
它通常用于 UDP 被封锁或限速而 TCP 允许通过的环境中。
Phantun 简单地将 UDP 数据包流转换为混淆的 TCP 流数据包。Phantun 使用的 TCP 栈被设计为能通过大多数 L3/L4 有状态/无状态防火墙/NAT 设备。它无法通过 L7 代理。然而，这种方法的优点是，常见的 UDP over TCP 性能杀手（如重传和流量控制）不会发生。底层 UDP 的特性（如乱序交付）被完全保留，即使从防火墙/NAT 的角度来看，连接最终看起来像一个 TCP 连接。
Phantun 意为 Phantom TUN，它是一个 UDP 流量的混淆器，只做足够的工作使其以 TCP 数据包的形式通过状态防火墙/NAT。
Phantun 使用100%安全的 Rust 编写，经过大量优化，能在多核系统上良好扩展，并且在快速连接上能轻松占满所有可用 CPU 资源。请参阅性能部分查看基准测试结果。
在下面的示例中，假设 Phantun 服务端监听传入的 Phantun 客户端连接，端口为 4567（服务端的 --local 选项），并将 UDP 数据包转发到 UDP 服务器 127.0.0.1:1234（服务端的 --remote 选项）。
还假设 Phantun 客户端监听传入的 UDP 数据包，地址为 127.0.0.1:1234（客户端的 --local 选项），并连接到 Phantun 服务端 10.0.0.1:4567（客户端的 --remote 选项）。
Phantun 为客户端和服务端都创建 TUN 接口。对于 客户端，Phantun 默认分配 IP 地址 192.168.200.2 和 fcc8::2。对于 服务端，默认为 192.168.201.2 和 fcc9::2。因此，您的内核必须启用 IPv4/IPv6 转发，并在物理网卡地址和 Phantun 的 Tun 接口地址之间设置适当的 iptables/nftables NAT 规则。
您可以自定义 Phantun 创建的 Tun 接口名称和分配的地址。请使用 -h 选项运行可执行文件查看如何更改。
另一种帮助理解此网络拓扑的方法（请参阅上方的拓扑示意图）：
Phantun 客户端就像一台具有私有 IP 地址（192.168.200.2/fcc8::2）位于路由器后面的机器。为了使其能够访问 Internet，您需要在流量离开网卡之前对私有 IP 地址进行 SNAT。
Phantun 服务端就像一台具有私有 IP 地址（192.168.201.2/fcc9::2）位于路由器后面的服务器。为了从 Internet 访问它，您需要在路由器上对其监听端口进行 DNAT，并将目标 IP 地址更改为服务端监听传入连接的地址。
在这些情况下，运行 Phantun 的机器/iptables 充当“路由器”，允许 Phantun 使用其私有 IP 地址与外界通信。
从 Phantun v0.4.1 开始，TCP 和 UDP 两侧都完全支持 IPv6。要指定 IPv6 地址，请使用以下格式：[::1]:1234 结合命令行选项。还支持解析 AAAA 记录。请使用 -h 运行程序查看如何控制 IPv6 行为的详细选项。
编辑 /etc/sysctl.conf，添加 net.ipv4.ip_forward=1，然后运行 sudo sysctl -p /etc/sysctl.conf。
同时需要设置 net.ipv6.conf.all.forwarding=1。
客户端只需要在物理接口上启用 SNAT，将 Phantun 的地址转换为物理网络上可用的地址。这可以通过伪装（masquerade）简单实现。
注意：将 eth0 替换为实际的物理接口名称。
table inet nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
iifname tun0 oif eth0 masquerade
}
}
注意：上述规则使用 inet 作为表族类型，因此与 IPv4 和 IPv6 都兼容。
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
服务端需要对 TCP 监听端口进行 DNAT，指向 Phantun 的 TUN 接口地址。
注意：将 eth0 替换为实际的物理接口名称，4567 替换为 Phantun 服务端实际使用的 TCP 端口号。
table inet nat {
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
iif eth0 tcp dport 4567 dnat ip to 192.168.201.2
iif eth0 tcp dport 4567 dnat ip6 to fcc9::2
}
}
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4567 -j DNAT --to-destination 192.168.201.2
ip6tables -t nat -A PREROUTING -p tcp -i eth0 --dport 4567 -j DNAT --to-destination fcc9::2
不建议以 root 用户运行面向网络的应用程序。Phantun 可以通过 cap_net_admin 能力以非 root 用户完全运行。
sudo setcap cap_net_admin=+pe phantun_server
sudo setcap cap_net_admin=+pe phantun_client
注意： 使用 -h 选项运行 Phantun 可执行文件以查看完整的详细选项。
注意：4567 是 Phantun 监听的 TCP 端口，必须与上面指定的 DNAT 规则对应。127.0.0.1:1234 是新连接连接到的 UDP 服务器。
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote 127.0.0.1:1234
或使用主机名与 --remote：
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote example.com:1234
注意：服务端默认将 IPv4 和 IPv6 私有地址都分配给 Tun 接口。如果您不希望使用 IPv6，可以跳过创建上述 IPv6 DNAT 规则，Tun 接口上存在 IPv6 地址不应产生副作用。
注意：127.0.0.1:1234 是 Phantun 监听的 UDP 地址和端口。10.0.0.1:4567 是要连接的 Phantun 服务端。
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote 10.0.0.1:4567
或使用主机名与 --remote：
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote example.com:4567
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote [fdxx::1234]:4567
也支持具有 AAAA 记录的域名。
Phantun 旨在将隧道开销降至最低。与普通 UDP 数据包相比，开销如下（以 IPv4 为例）：
标准 UDP 数据包： 20 字节 IP 头 + 8 字节 UDP 头 = 28 字节
混淆后的数据包： 20 字节 IP 头 + 20 字节 TCP 头 = 40 字节
注意，Phantun 除了 IP 和 TCP 头之外没有添加任何额外头部，以便通过有状态数据包检测！
Phantun 的额外开销：12 字节。换句话说，使用 Phantun 时，UDP 数据包的有效负载减少了 12 字节。这是进行此类混淆时可能的最小开销。
对于使用 Phantun 隧道 WireGuard® UDP 数据包的用户，以下是确定 WireGuard 接口正确 MTU 的指南。
WireGuard MTU = 链路 MTU - IPv4 头（20 字节） - TCP 头（20 字节） - WireGuard 开销（32 字节）
或
WireGuard MTU = 链路 MTU - IPv6 头（40 字节） - TCP 头（20 字节） - WireGuard 开销（32 字节）
例如，对于具有 1500 字节 MTU 的网络链路，WireGuard 接口 MTU 应设置为：
IPv4： 1500（链路 MTU） - 20 - 20 - 32 = 1428 字节
IPv6： 1500（链路 MTU） - 40 - 20 - 32 = 1408 字节
生成的 Phantun TCP 数据包将为 1500 字节，不超过 1500 的接口 MTU。
请注意，如果数据包大小超过链路 MTU，Phantun 无法正常工作，因为 Phantun 不执行任何 IP 分片和重组。出于同样的原因，Phantun 总是在 IP 头中设置 DF（不分片）位，以防止中间设备对数据包进行任何分片。
还强烈建议在 WireGuard 隧道的两端使用相同的接口 MTU，否则可能会发生意外的数据包丢失，而且此类问题通常非常难以排查。
虽然 TCP 栈相当稳定，但一般期望在两端运行相同次要版本的 Phantun 服务端/客户端，以确保最大兼容性。
希望在自己的项目中使用 fake-tcp 库的用户，请参阅该库的文档：https://docs.rs/fake-tcp。
性能测试在两台 AWS t4g.xlarge 实例上进行，配备 4 个 vCPU 和 5 Gb/s 网卡，位于 LAN 中。使用 nftables 将 iperf3 的 UDP 流重定向，使其通过两个测试实例之间的 Phantun/udp2raw 隧道，并调整了 MTU 以避免分片。
使用了 Phantun v0.3.2 和 udp2raw_arm_asm_aes 20200818.0。这些是截至 2022 年 4 月两个项目的最新版本。
测试命令：iperf3 -c <IP> -p <PORT> -R -u -l 1400 -b 1000m -t 30 -P 5
关于 Phantun 用于实现此性能结果的部分技术文章：用 Rust 编写高效 UDP 服务器。
udp2raw 是另一个由 @wangyu- 开发的热门项目，功能与 Phantun 非常相似。实际上，Phantun 的灵感来源于 udp2raw。开发 Phantun 的最大原因是 udp2raw 运行时的性能不足（尤其是在 Raspberry Pi 等多核系统上）。不过，目标并非像 udp2raw 那样功能完备，只支持最常见的用例。最值得注意的是，不支持 UDP over ICMP 和 UDP over UDP 模式，也没有抗重放和加密支持。其优势在于整体性能更好，并且由于 TCP 负载内没有额外头部，MTU 开销更小。
以下是两者之间的快速比较，帮助您选择：
Copyright 2021-2025 孙大同一（[email protected]）
根据 Apache 许可证 2.0 版（<LICENSE-APACHE 或 https://www.apache.org/licenses/LICENSE-2.0>）或 MIT 许可证（<LICENSE-MIT 或 https://opensource.org/licenses/MIT>）进行许可，由您选择。项目中文件不得在未遵守这些条款的情况下复制、修改或分发。
| 模式 | 发送速度 | 接收速度 | 总体 CPU 使用率 |
|---|
| 直连（1 流） | 3.00 Gbits/sec | 2.37 Gbits/sec | 25%（1 核满载） |
| Phantun（1 流） | 1.30 Gbits/sec | 1.20 Gbits/sec | 60%（1 核满载，3 核 50%） |
udp2raw（cipher-mode=none auth-mode=none disable-anti-replay）（1 流） | 1.30 Gbits/sec | 715 Mbits/sec | 40%（1 核满载，1 核 50%，2 核空闲） |
| 直连（5 流） | 5.00 Gbits/sec | 3.64 Gbits/sec | 25%（1 核满载） |
| Phantun（5 流） | 5.00 Gbits/sec | 2.38 Gbits/sec | 95%（所有核均被利用） |
udp2raw（cipher-mode=none auth-mode=none disable-anti-replay）（5 流） | 5.00 Gbits/sec | 770 Mbits/sec | 50%（2 核满载） |
| Phantun | udp2raw |
|---|
| UDP over FakeTCP 混淆 | ✅ | ✅ |
| UDP over ICMP 混淆 | ❌ | ✅ |
| UDP over UDP 混淆 | ❌ | ✅ |
| 多线程 | ✅ | ❌ |
| 吞吐量 | 更好 | 良好 |
| 三层模式 | TUN 接口 | 原始套接字 + BPF |
| 隧道 MTU 开销 | 12 字节 | 44 字节 |
| 每个 UDP 连接使用独立的 TCP 连接 | 客户端/服务端 | 仅服务端 |
| 抗重放、加密 | ❌ | ✅ |
| IPv6 | ✅ | ✅ |