隧道技术对比

隧道把一种通信封装到另一种通信中。选型先回答“究竟需要传送什么”：一台不能改造设备的 Ethernet 帧、一整个网段的 IP 包，还是某个服务的一条 TCP 连接。这些需求对应的广播范围、路由行为和权限边界不同，不能只按产品性能排序。

“可部署”还要考虑现有设备是否支持、运维能否管理密钥与路由、出口是否允许所需传输。设备支持 IPsec 卸载并不证明指定算法、封装和流量已经走上卸载路径。

IPIP 与 GRE：最简单的 IP 封装不是同一个协议

IPv4-in-IPv4 直接在原 IPv4 包前增加新的 IPv4 头，外层 Protocol 为 4；无选项时新增 20 B。GRE 使用协议号 47，另有基础 4 B GRE 头，其中 Protocol Type 指示被封装的协议。因此 GRE 更通用，但不能称为“没有额外头的 IPIP”。IP-in-IP RFC 2003、GRE RFC 2784

GRE 可按相应扩展携带 Key、序号或校验等字段，长度不应固定为 4 B。Key 可用于区分逻辑隧道，不能作为身份认证凭据；攻击者能构造相同 Key，并不需要知道任何加密私钥。基础 IPIP 与 GRE 都不提供业务内容机密性。

假设内层是 1400 B IPv4 包：无选项的 IPv4-in-IPv4 为 1420 B，基础 GRE over IPv4 为 1424 B。这里不含外层 Ethernet 头，也未增加加密。把这个数字与“线上占用字节”比较时，需要补齐同一层的口径。

VXLAN 与 Geneve：隧道本身不是完整虚拟网络控制面

VXLAN 把内层 Ethernet 帧封装到 UDP，基础 VXLAN 头为 8 B，VNI 为 24 位。VNI 表示逻辑网络，不是加密密钥；相同 VNI 的误接入仍需要底层隔离和入口验证防范。UDP 源端口可以为外层 ECMP 提供流量散列信息，不等于每个包都应随机换路径。VXLAN RFC 7348

Geneve 的基础头也是 8 B，支持可变长选项，适合携带网络虚拟化元数据；计算开销时必须加上实际选项长度。遇到无法理解的关键选项时，处理规则会影响能否接收，不能把选项当作对所有端点都透明的装饰。Geneve RFC 8926

封装只说明包怎么搬运，不说明远端 MAC 在哪里、未知单播应该发给谁、广播怎样复制。学习、静态配置或 EVPN 等控制方式承担这些问题。二层扩展把广播与故障影响带到更多位置；若应用只需单播 IP 互访，应先判断是否真的依赖同一广播域。

为什么 VXLAN 不要求 MTU 一定是 9000

以无 VLAN、内层帧不携带 FCS、外层 IPv4 无选项为例：一个 1500 B 内层 IP 包加内层 Ethernet 14 B、VXLAN 8 B、UDP 8 B、外层 IP 20 B，共形成 1550 B 外层 IP 包⁠。需要的是路径支持这个尺寸，9000 只是可能的网络配置之一；也可以降低内层 MTU，不能把任意分片当作无代价补救。

inner_ip = 1500
encapsulation = {
    'IPIP/IPv4': 20,
    'GRE-basic/IPv4': 20 + 4,
    'VXLAN/IPv4': 20 + 8 + 8 + 14,
    'VXLAN/IPv6': 40 + 8 + 8 + 14,
    'Geneve/IPv4+16B-options': 20 + 8 + 8 + 16 + 14,
}
assert inner_ip + encapsulation['VXLAN/IPv4'] == 1550
assert 1500 - encapsulation['VXLAN/IPv4'] == 1450
assert 1500 - encapsulation['VXLAN/IPv6'] == 1430
assert 1500 - encapsulation['Geneve/IPv4+16B-options'] == 1434
# 1550 B 外层 IP 包再加外层 Ethernet 头与 FCS；仍未算前导码和帧间隔。
assert 1550 + 14 + 4 == 1568
print('统一按外层 IP 长度计算的封装预算通过')

内层 VLAN、额外加密或第二层隧道都继续占用预算。TCP MSS 只影响 TCP 数据段；降低 MSS 不能自动解决大 UDP 数据报，也不能替代所有路径的 PMTU 处理。

1500字节内层包，外面到底装不装得下？

先比较VXLAN的IPv4与IPv6外层，内层上限相差20 B。再选ESP，把内层长度从1438增加到1439，外层不是只增加1 B，而是因对齐从1500跳到1504。预算必须包含这种离散变化。

WireGuard、IPsec 与平台能力应分别比较

WireGuard 将 peer 公钥、AllowedIPs 与 UDP 数据平面结合，协议本身没有完整用户目录或通用自动穿透服务。IPsec/IKEv2 通过策略与 SA 保护 IP 流量，认证、算法协商和设备互操作有更丰富的配置空间。性能由实现、算法加速、包长、核数与链路共同决定，没有跨环境固定冠军。

Tailscale 在 WireGuard 之上增加身份、策略分发、发现和中继。它与裸 WireGuard 的差异不只是某次吞吐测试；比较部署成本时要算上手工维护 peer、公钥和路由的工作量，以及平台控制面的依赖。

“端到端加密”的端点必须写清：两台业务主机各自终止隧道，与两台网关之间的隧道不同。后者离开网关后可继续走明文网络；应用 TLS 可以提供更远一层的保护。

反向隧道：内网客户端主动出站，公网端接收访问

普通公网端口转发方案中，内网代理 C 主动连到公网代理 S，S 把外部连接转交给 C，再由 C 连接本地服务。它避开了直接入站访问内网的要求，但公网 S 仍需可达，C 的出站也必须被允许。这里不必成功建立访问者到内网的 UDP 打洞。

rathole 与 frp 的常见部署都有 server/client 角色，不能把前者写成天然对称去中心化、后者才是集中结构。rathole 当前仓库配置支持 TCP 与 UDP 服务，并提供 TLS、Noise 等传输选择，“只支持 TCP、加密只能靠 Caddy”均不准确。rathole 项目、传输配置

产品支持 UDP 服务与“代理间必定原生 UDP 传输”是两回事。若 UDP 数据通过可靠流承载，丢包和队头阻塞行为会变化；若多个业务连接共享一个 TCP 传输，外层丢包恢复可能影响其他复用连接。frp 网络配置

连接池为什么不能消除所有握手

池把一部分连接准备工作移到业务请求到达之前，命中时减少等待；复用则允许多个逻辑连接共用已有传输。frp 同时支持这些机制，因此不能用“rathole 预建、frp 永远按请求新建 TCP”作为两者的根本区别。

即使 S—C 通道已准备，访问者到 S 的连接、C 到本地服务的连接，以及应用 TLS/登录步骤仍可能存在。池中连接失效时还需要检测和补充；不能把 early eof 唯一归因于 NAT 空闲超时，它也可能来自对端关闭、进程退出或协议不匹配。

例如请求需要按需建立通道时额外等待 40 ms，预备通道命中率为 90%，仅计算这一项的平均等待是 4 ms。剩余 10% 的请求仍有 40 ms 等待，不能用平均值说明尾延迟已消失。池越大还会占用更多 FD、内存和网关状态。

入口 TLS 与隧道加密：两个不同的终止位置

如果 Caddy 在 S 终止浏览器 TLS，S 能看到 HTTP 明文；启用 S—C 的 TLS/Noise 可以继续保护传输，但不会把 S 重新变成看不见业务内容的中继。如果从访问者到源站透传应用 TLS，S 只转发对应密文，源站负责证书与应用认证。

代理注册 token 用于证明 C 有权注册某个转发服务，并不会自动验证访问公网监听端口的每位用户。公开管理页面、数据库端口或文件服务时，访问控制需要在实际入口或应用处落地；只给隧道双方配一个 token 不等于该服务已私有化。

用一个完整场景做选择

假设需要让三位同事访问家庭 NAS 的管理页面，访问者可以安装客户端，且无需公开访问。首先比较设备覆盖网络方案的成员授权、客户端支持与恢复成本；无需先把管理页面开放到公网再叠加额外入口认证。

若目标变为无需安装客户端的公开演示站点，反向 HTTP 代理更符合入口形式，接着确定 TLS 终点、域名、源站身份与请求大小/超时。若目标变为连接两个有大量 IP 服务的网段，再比较网关 VPN、路由与回程。若应用必须依赖二层发现或特定 Ethernet 语义，才继续评估二层覆盖网络及广播边界。

这些判断不是产品永久排名。评估报告至少给出：数据实际经过谁、谁能解密、允许访问什么、最大有效包长、满载时的内存与尾延迟，以及控制连接中断后新旧业务各会怎样。只写“轻量、低延迟、企业级”无法据此复现或作出取舍。