使用 mimic + WireGuard 组网
内容提要
本文介绍用 mimic 配合 WireGuard 为鹅云轻量与瓦工两台 Debian 13 主机组网，给出 WireGuard 与 mimic 配置及 nftables 规则，并记录踩坑：mimic 过滤器只能写一个 origin，鹅云须填 NAT 前内网地址；文档推荐 MTU 1408 实测为黑洞，最大可用 1392，最终取 1380；virtio_net 上 XDP native 会断连，改用 skb；开启 max_window 后重传从 1525 降至 102；防火墙须同时放行 TCP 与 UDP。
延伸解读
MTU 黑洞：文档值不可照搬
mimic 官方文档推荐隧道 MTU 为 1408，但本文实测该值导致大包全丢，最大可用内层 MTU 为 1392，最终取 1380 留安全余量。作者推测 mimic 生成的 TCP 头带选项，使外层开销约 108 字节而非文档的 74 字节。部署后务必用 DF 位探测实测边界，不要直接套用文档值。
XDP 模式选择：virtio_net 需用 skb
在 KVM + virtio_net 环境下，mimic 默认的 XDP native 模式挂载瞬间会导致当前 SSH 会话被 RST，与文档 issue #11 现象一致。改用 xdp_mode = skb 可避免断连。虽然 skb 模式性能有损失，但鹅云出口带宽仅 6 Mbps，影响可忽略。
max_window 显著降低重传
mimic 伪造的 TCP 默认窗口约 13 KB，在 130 ms RTT 链路上窗口成为瓶颈，引发大量重传。两端开启 max_window = true 后，窗口变为 65535，重传次数从 1525 降至 102。高延迟链路组网时建议启用此选项。
防火墙需同时放行 TCP 与 UDP
mimic 的透明改写发生在 eBPF 层，netfilter 在不同方向看到的协议不同：出口方向为 TCP，入口方向为 UDP。因此防火墙规则必须同时放行 TCP 和 UDP 的 51820 端口，缺一不可。抓包证据显示出口全为 TCP，UDP 捕获数为 0。
Q&A
mimic 的 filter 配置为什么不能同时写 local 和 remote？
mimic 0.7.0 的 filter 只接受一个 origin，逗号后只能跟 padding、handshake、keepalive 等覆盖项，不能跟第二个 origin。如果写成 local=...:51820,remote=...:51820，会报错“Error unsupported option type: 'remote'”并导致配置读取失败。
在鹅云上配置 mimic 过滤器时，应该填内网地址还是公网 EIP？
必须填 NAT 转换前的内网地址，不能填鹅云提供的 EIP。因为 eBPF 程序挂在 TC/XDP 上，看到的是 NAT 转换前的数据包，所以过滤器要匹配内网地址。
mimic 官方推荐 MTU 1408，为什么实际使用中会完全不通？
因为 1408 在该环境下是硬黑洞，100% 丢包。实测最大可用内层 MTU 为 1392，最终采用 1380 留出安全余量。推测原因是 mimic 生成的 TCP 报文头带选项，使外层 TCP 头达到约 40+ 字节，实际每包开销约 108 字节而非文档所述的 74 字节，导致上限降低。
在 virtio_net 网卡上使用 mimic 的 XDP native 模式会有什么问题？如何解决？
在 virtio_net 上使用 XDP native 模式会导致当前 SSH 会话被 RST，出现“kex_exchange_identification: read: Connection reset by peer”错误。解决方法是改用 skb 模式，即在配置中设置 xdp_mode = skb。
开启 max_window 后对重传有什么改善？
开启 max_window 后，重传次数从 1525 次降至 102 次（在 6 Mbps 饱和链路、6~8 秒测试中）。抓包可见窗口变为 win 65535，有效缓解了高 RTT 链路上的窗口瓶颈。
配置防火墙时，为什么必须同时放行 TCP 和 UDP 的 51820 端口？
因为 mimic 的透明改写发生在 eBPF 层，netfilter 在不同方向看到的协议不同：出口方向（TC 在 netfilter OUTPUT 之后执行）看到的是 TCP，入口方向（XDP 在 netfilter INPUT 之前执行，已还原）看到的是 UDP。所以规则必须同时放行 TCP 和 UDP，缺一不可。
