LetsVPN双栈IPv4/IPv6分流配置步骤与验证方法

功能定位：双栈分流要解决什么问题

2025 年起，国内运营商陆续默认开启 IPv6 前缀动态分配，企业出口常出现“同一 session 先 v6 后 v4”导致的会话漂移，合规侧要求留存可溯源的完整五元组。LetsVPN 在 4.7.0 版引入“双栈 IPv4/IPv6 分流”功能，核心目标是用策略路由把明文审计责任留在本地网关，同时把加密隧道流量按 IP 版本拆到不同出口，降低单栈链路抖动对日志完整性的影响。

与“智能分流”或“域名分流”相比，双栈分流只按 IP 版本做决策，不解析 Host，也不依赖 SNI，因此不会引入额外 DNS 泄漏点；代价是粒度最粗，无法针对同一域名下的双栈记录再做细分。经验性观察，在日均 20 万条会话的节点上，双栈分流能把“缺失版本流量”占比从 12 % 压到 0.3 %，直接满足监管对“完整会话链”的刚性要求。

变更脉络：从 4.5 到 4.7 做了什么

4.5 版以前，LetsVPN 采用内核层“Happy Eyeballs”透明代理，v4/v6 竞速由客户端随机决定，导致审计日志里常缺失其中一半流量。4.6 版尝试“IPv6 优先”开关，但未解决会话漂移。4.7.0 把策略下发节点拆成两条独立链路，并在本地生成两张虚拟网卡：tun0(v4) 与 tun1(v6)，使审计系统可对不同版本流量分别打标签，满足《网络安全法》第二十一条“留存网络日志不少于六个月”的刚性要求。

值得注意的是，4.7.0 在 Android 内核 5.10 以上机型启用了“多网络回调”接口，重连耗时较 4.6 缩短约 200 ms；而在 5.4 以下内核仍回落到旧有模式，升级前建议先核对内核版本，避免性能回退。

最短可达路径：分平台操作指南

Android（以 4.7.0_2412 为例）

打开 LetsVPN → 右上角「⋯」→「高级设置」→「双栈分流」。
开启「启用 IPv4/IPv6 分流」开关，此时下方出现「IPv6 出口策略」。
选择「仅当目标有 AAAA 记录时走 v6」或「强制 v6」；合规场景建议选前者，可保留完整 A/AAAA 审计对。
点「保存」后客户端自动重连，通知栏出现两条钥匙图标，代表双 tun 已建立。

若第 4 步未出现双钥匙，请检查系统是否关闭「省电限制」，否则 Android 会回收第二条 tun。示例：在小米 MIUI 14 上，需额外把 LetsVPN 加入「无限制电量」白名单并锁定后台。

iOS（需 4.7.0_532 及以上）

「设置」→「VPN 与网络」→「LetsVPN」→「双栈分流」。
由于 iOS NE 框架限制，只能「IPv4 优先」或「IPv6 优先」二选一，无法同时双 tun；合规侧需额外在「日志回传」里打开「包含 IP 版本标记」。
保存后需手动断开再连一次，系统会提示「安装 VPN 配置描述文件」，允许即可。

经验性观察，iOS 在 17.2 以上版本对“IPv6 优先”支持更完整，首次握手延迟可再降 30 ms；若低于 16.x，建议保持“IPv4 优先”避免 CDN 调度异常。

桌面端（Windows/macOS）

主界面左下角「≡」→「首选项」→「网络」→「双栈模式」。
勾选「独立虚拟网卡」，此时下拉框出现「v4 网卡 MTU」与「v6 网卡 MTU」；默认 1420/1420，若公司交换机开启 Jumbo Frame，可把 v6 侧调到 1480。
点击「应用」后会弹出 UAC/管理员密码，确认后客户端自动创建 letsvpntun_v4 与 letsvpntun_v6 两张网卡。

Windows 若出现代码 53 错误，99 % 是旧 TAP 驱动未卸载干净，下文“故障排查”小节给出一次性清理脚本。

验证与回退：确保日志可审计

验证三步法

客户端侧：在「诊断」→「实时路由」里应能看到 default via 10.8.0.1 dev tun0 与 default via fd00:7::1 dev tun1 并存。
服务端侧：登录公司 syslog，检索最近 10 条同一用户 IP，确认同时出现 %tun0 与 %tun1 标记。
样本测试：用 curl -4/-6 https://ifconfig.net 分别返回两条不同出口 IP，且 WHOIS 归属均为 LetsVPN 自有 ASN。

第三步建议写入 CI，用 GitHub Action 每 6 小时跑一次，一旦 v6 出口 IP 漂移出 ASN，立即告警。

回退方案

若在验证中发现审计系统只能识别一张网卡，可立即在「双栈分流」页右上角点「重置」，客户端会恢复默认单 tun 模式，30 秒内自动重连，历史日志不会丢失，但新流量将不再拆分。重置后仍建议保留 24 小时观测窗口，确认审计平台无“日志断层”告警再决定是否二次开启。

例外与副作用：什么时候不该开

1. 本地已部署零信任网关（Zscaler、Netskope 等）且开启“双发 DPI”时，再叠加双 tun 会导致重复封装，CPU 占用经验性观察上升 18–22 %，可直接关闭 LetsVPN 的「独立虚拟网卡」选项。

2. 若公司防火墙对 IPv6 采用“默认拒绝”策略，tun1 会一直黑洞，表现为网页首包超时 2 s 后降级 v4，体感延迟明显。此时应把「IPv6 出口策略」改成「仅当目标有 AAAA 记录」并配合防火墙放行 UDP/4500。

3. 出差场景下部分酒店网关会丢弃 1280 以上 IPv6 包，若把 v6 MTU 调到 1480 可能触发黑盒分片。建议把 v6 MTU 回退到 1280，或在「IPv6 例外路由」里把酒店网段 240e:xxx::/48 写死走 v4。

与第三方审计平台协同

经验性观察：Splunk、ELK 在接收 LetsVPN 4.7.0 的 syslog 时，需手动加字段提取器 tun_type=(tun0|tun1)，否则会被合并为同一 flow。可复现步骤：在 Splunk 新建 Sourcetype=letsvpn，添加 REGEX=tun_type=(\w+)，即可在 Dashboard 区分 v4/v6 流量占比。

若使用阿里云 SLS，可在采集配置里打开「扩展字段」，用分隔符“tun_type=”直接落库，查询语句 *| select count(*) where tun_type='tun1' 能在 2 秒内给出 v6 流量占比。

适用/不适用场景清单

场景	是否推荐	理由
10 人以内小团队，无独立日志平台	❌	审计收益低于维护成本
金融、医疗等强合规行业	✅	满足六个月内可溯源要求
CI 流水线每日 5k 次容器拉取	✅	双栈镜像源加速明显
统一出口已做 SNAT 收敛	⚠️	需确认审计系统能识别内层地址

若企业已接入 SDP（软件定义边界）且使用客户端证书做身份绑定，开启双栈分流后需同步把证书 SAN 字段加入 IPv6 地址池，否则会出现“证书与出口 IP 不匹配”告警。

故障排查：现象→原因→处置

现象：开启后部分国内站点打不开

原因：部分省运营商对 240e::/18 路由黑洞。处置：在「IPv6 例外路由」里填入240e::/18，保存后 10 秒生效，无需重连。

现象：Windows 提示“无法创建适配器”

原因：旧版 TAP 驱动残留。处置：在「设备管理器」卸载所有“TAP-Windows Adapter V9”，重启客户端会自动安装 9.27 驱动。

现象：macOS 休眠后断流 5 秒

原因：系统唤醒时先拉 v6 RA，再恢复路由，tun1 短暂掉线。处置：在「终端」执行 sudo networksetup -setv6off Wi-Fi 强制关原生 v6，冲突即可消失。

最佳实践检查表

上线前

确认审计平台已新增 tun_type 字段提取器
在防火墙放行 UDP/4500 与 IPv6 前缀
先给 5% 用户开灰度，观测 48 小时无异常再全量

上线后

每周跑一遍 curl -4/-6 样本，确保出口归属未漂移
双栈流量比异常（如 v6 突降至 <5%）时，检查运营商是否局部撤路由
保存客户端日志 30 天，方便监管抽查

版本差异与迁移建议

若您仍在 4.6.x，需要先升级到 4.7.0 才能看到「双栈分流」开关；4.5.x 及更早版本需完整卸载再安装，否则旧 TAP 驱动会与新功能冲突。迁移时建议先在 CI 环境跑一遍自动化用例，重点校验“断线重连”与“休眠唤醒”两种场景，经验性观察 4.7.0 重连耗时比 4.6 缩短约 200 ms，但休眠后唤醒要多做一次 DHCPv6，故首次握手会多 1 RTT。

示例：在 GitLab CI 中新增 job test_dualstack，用 sleep 5 && curl -4 -s https://ifconfig.net 与 curl -6 双命令对比，断言耗时差不超过 300 ms，即可在 MR 阶段拦截性能回退。

案例研究

案例 1：50 人金融初创公司

背景：公司使用 Splunk 做日志审计，监管要求 6 个月内可溯源。接入双栈分流前，v6 流量缺失率 11 %，每月被监管抽查时需人工补录，平均耗时 4 小时。

做法：周五晚切 30 % 灰度，在 Splunk 新增 tun_type 字段提取器；防火墙放行 UDP/4500；Android 关闭省电限制。

结果：周一早高峰缺失率降至 0.2 %，监管抽查时间缩短到 15 分钟；CPU 占用上升 5 %，可接受。全量推周后，连续 3 个月无罚单。

复盘：灰度窗口选在非交易日，降低用户投诉；Splunk 字段提前同步，避免“日志断层”误告警。

案例 2：5k 人跨国制造集团

背景：全球 40 厂区，统一出口做 SNAT 收敛，IPv6 默认拒绝。CI 每日 8 万次容器拉取，v6 镜像源延迟低但审计缺失。

做法：总部先升级 4.7.0，在 ELK 创建 tun_type pipeline；厂区防火墙批量下发 IPv6 白名单；MTU 统一 1420。

结果：v6 流量占比从 3 % 提升到 37 %，镜像拉取耗时下降 18 %；审计日志完整率 99.9 %，通过德国 TISAX 评审。

复盘：先拉通网络团队放行 IPv6，再推 VPN 配置，避免“先开后封”的重复施工；MTU 统一减少分片，降低厂区间投诉。

监控与回滚 Runbook

异常信号

syslog 中 tun1 流量突降至 0 持续 5 分钟。
出口 IP WHOIS 归属漂移出 LetsVPN ASN。
客户端「实时路由」只剩 tun0 默认路由。

定位步骤

在审计平台检索同一用户最近 10 条日志，确认是否出现 %tun1。
用 ping6 fd00:7::1 检测隧道连通性；若超时，检查防火墙 UDP/4500。
查看运营商是否撤回 240e::/18 路由，对比 BGP 公告平台。

回退指令

Android/iOS：「高级设置」→「双栈分流」→右上角「重置」→自动重连。桌面端：「首选项」→「网络」→取消「独立虚拟网卡」→应用。全部平台 30 秒内恢复单 tun，历史日志保留。

演练清单

每季度模拟“v6 路由被黑洞”一次，验证 240e::/18 例外是否生效。
半年度做“监管抽查”演练，30 秒内导出完整五元组。
每年 TAP 驱动升级后，跑一遍休眠唤醒用例，确保无代码 53。

FAQ

Q1：开启后电池耗电明显？: A：Android 双 tun 会唤醒两次 CPU。结论：开启「无限制电量」后耗电增加 4 %，可接受。证据：Pixel 7 实测 8 小时出差续航。
Q2：iOS 为什么看不到双钥匙？: A：NE 框架限制只能单 tun。结论：属预期行为，用「IP 版本标记」补全日志即可。证据：Apple 官方文档 NetworkExtension 头文件。
Q3：Splunk 提取器正则写错会怎样？: A：v4/v6 被合并为同 flow。结论：Dashboard 占比失真，监管视为“缺失”。证据：复现步骤见正文协同章节。
Q4：能否对同一域名再按域名细分？: A：不能，双栈分流只按 IP 版本。结论：需细分请改用“域名分流”。证据：官方 4.7.0 release note。
Q5：Windows 睡眠后 tun1 消失？: A：TAP 驱动 9.24 以下有睡眠 Bug。结论：升级到 9.27 可解。证据：LetsVPN 官网驱动下载页 checksum。
Q6：出口 IP 突然变成其他 ASN？: A：边缘节点故障，BGP 自动切换。结论：每周跑样本即可发现。证据：ifconfig.net WHOIS 历史记录。
Q7：能否关闭 v4 只留 v6？: A：暂无“仅 v6”选项。结论：可手动把 0.0.0.0/0 写进例外路由实现。证据：社区论坛置顶帖。
Q8：合规要存 PCAP 吗？: A：法律只要求五元组日志。结论：无需全包存储，降低 90 % 空间。证据：《网络安全法》第二十一条释义。
Q9：240e::/18 黑洞多久更新一次？: A：运营商无固定周期。结论：建议每月拉 BGP 平台对比。证据：APNIC 每日 BGP snapshot。
Q10：4.8 版什么时候发？: A：官方 roadmap 写 2026 Q1。结论：届时支持 ASN 例外，可一键跳过 240e。证据：LetsVPN 官网 roadmap 页面。

术语表

五元组: 源 IP、源端口、目的 IP、目的端口、协议号。首次出现：功能定位段落。
Happy Eyeballs: IPv4/IPv6 竞速算法。首次出现：变更脉络段落。
tun0 / tun1: 4.7.0 创建的 v4/v6 虚拟网卡。首次出现：变更脉络段落。
syslog: 系统日志协议，用于审计。首次出现：验证与回退段落。
UDP/4500: IPsec NAT-T 端口，IPv6 需放行。首次出现：例外与副作用段落。
WHOIS: IP 归属查询协议。首次出现：验证三步法段落。
TAP 驱动: Windows 虚拟网卡驱动。首次出现：桌面端操作指南段落。
RTT: 往返时延。首次出现：版本差异段落。
BGP: 边界网关协议，决定路由。首次出现：故障排查段落。
ASN: 自治系统号，标识运营商。首次出现：验证三步法段落。
PCAP: 抓包文件格式。首次出现：FAQ 段落。
SNAT: 源地址转换。首次出现：适用场景表格段落。
ELK: Elasticsearch+Logstash+Kibana 日志栈。首次出现：案例 2 段落。
TISAX: 德系汽车安全评估标准。首次出现：案例 2 段落。
SDP: 软件定义边界，零信任架构。首次出现：适用场景表格后续段落。

风险与边界

不可用情形：① 客户端低于 4.7.0；② iOS 需 16.0 以上，低于此版本无法使用 IPv6 优先；③ 酒店网关对 1280 以上 IPv6 包全部丢弃且无法修改 MTU。

副作用：双 tun 增加约 4 % 电量与 5 % CPU；Windows 旧 TAP 驱动未卸载时可能蓝屏。

替代方案：若只需审计不要求加密拆分，可用“域名分流”+ 本地镜像代理；若需更细粒度，可等待 4.8 的“ASN 例外”功能。

未来趋势与结语

LetsVPN 官方 roadmap 提到 2026 Q1 将在 4.8 版支持“基于 ASN 的 IPv6 例外”，届时可一键跳过国内 CDN 的 240e 黑洞，进一步减少手动维护。对合规团队而言，双栈分流不是性能优化，而是审计完整性的前置条件；只要日志平台能识别 tun_type，就能在监管检查时 30 秒内给出“该用户当日完整会话链”，避免以往“缺一半日志”导致的罚单风险。现在按本文步骤开启灰度，你就有足够时间在下一波合规抽查前跑稳整条链路。