## 功能与适用场景飞连 SD\-WAN 域名调度在解析业务域名时，结合员工身份或接入分支选择出口，并将解析结果与后续业务转发关联。本文面向网络管理员，介绍云 VPN 与员工选路、分支组网与分支选路两种场景的工作原理、域名匹配规则和报文路径。员工通过云 VPN 访问业务系统时，可以按员工身份使用相应出口；分支办公室访问同一业务域名时，可以按入口 CPE 使用相应出口。域名调度将“访问哪个域名”与“从哪个出口访问”关联起来。 **场景对比** |场景 |DNS 查询入口 |数据接入 |数据出口 |调度粒度 | |---|---|---|---|---| |云 VPN + 员工选路 |云 VPN 客户端 `dnsproxy` |**接入 POP**（POP\-VPN，客户端接入的 POP 节点） |**出口 POP** → 出口 CPE / vCPE |按用户身份区分出口节点 | |分支组网 + 分支选路 |分支入口 CPE `dnsmasq` |**入口 CPE** → 接入 POP |**出口 POP** → 出口 CPE |按入口 CPE 区分出口 CPE | **DNS 调度的作用** * **按业务域名选择出口**：SaaS、内部系统和跨境资源通常通过域名访问。DNS 调度根据域名选择出口，将域名规则与后续的 IP 报文转发关联。 * **将调度结果用于报文转发**：中心 DNS 返回业务 A 记录和 tun IP。客户端建立 fake IP 映射，入口 CPE 建立业务真实 IP 与 tun IP 的映射，后续报文据此经 SD\-WAN 隧道转发到指定出口 CPE。 * **两种场景共用域名规则**：员工选路与分支选路使用同一份租户域名匹配规则，分别根据用户身份和入口 CPE 匹配出口 CPE。 ## 基本概念与架构 |概念 |说明 | |---|---| |调度域名 |需要由飞连 SD\-WAN 域名调度处理的业务域名。命中调度范围后，解析请求发送到中心 DNS。 | |中心 DNS |结合租户域名规则及员工或入口 CPE 信息选择出口，并协调出口侧完成域名解析。 | |入口 CPE |分支侧的接入设备，接收分支终端的 DNS 请求和业务流量。 | |出口 CPE / vCPE |连接目标资源所在网络的出口设备，负责出口侧域名解析和业务转发。 | |POP |SD\-WAN 网络接入节点。接入 POP 接收客户端或入口 CPE 的流量，出口 POP 将流量转发到出口 CPE。 | |业务真实 IP |出口 CPE 通过 DNS 解析获得的目标业务 IPv4 地址。 | |隧道虚拟 IP（tun IP） |由 POP 分配的隧道地址，用于 SD\-WAN 网络内的转发。 | |客户端映射地址（fake IP） |客户端返回给本地应用的地址，客户端维护其与业务真实 IP、隧道虚拟 IP 的关联。 | 整体架构包括管理面、DNS 调度控制面，以及承载业务流量的接入、骨干和出口网络。中心 DNS 负责选择出口和解析协调；客户端、CPE 和 POP 负责业务转发。下图分别展示员工客户端与分支 CPE 两种接入方式。虚线表示配置下发，细实线表示 DNS 查询及出口解析协调，粗实线表示业务转发路径。接入 POP 与出口 POP 之间通过骨干网络转发。 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/sdwan-domain-20261012/topic-architecture.svg) ## 员工接入调度流程员工通过云 VPN 访问业务域名时，客户端负责 DNS 分流、调度结果映射和接入侧报文转换。以下按解析、请求转发和回包三个阶段说明完整过程。 **客户端两组 DNS 的分工** 客户端接入云 VPN 之前请求 `/vpn/list`，服务端针对该云 VPN 下发两组 DNS： |DNS 组 |用途 |下游递归 / 权威 | |---|---|---| |租户配置 DNS（主 / 备） |解析**非调度域名**（普通公网 / 常规 SaaS） |上游递归 / DNS 服务器 | |中心 DNS IP |解析**调度域名**（客户端 Bloom Filter 命中项） |由中心 DNS 汇总 → 出口 CPE 本地解析 | **调度域名的判定与扩展字段** * **域名判定**：客户端 `dnsproxy` 在 Bloom Filter 命中即视为调度域名，将查询交给中心 DNS；未命中则交给租户配置 DNS。 * **请求扩展字段**： * **云 VPN 客户端选路**：请求携带"租户 + 建议出口节点"，中心 DNS 按客户端建议使用出口 CPE。 * **员工选路**：请求携带"租户 + 员工身份 + 设备身份 + 客户端虚拟 IP + 连接模式"等信息，中心 DNS 结合员工选路规则综合判定出口 CPE，可能覆盖客户端建议值。 * **响应内容**：中心 DNS 响应中除 A 记录外，同时携带 tun IP，供客户端在本地建立"业务真实 IP ↔ fake IP ↔ tun IP"三段映射。 ### 调度时序 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/sdwan-domain-20261012/topic-employee.svg) **处理过程** 1. **预置阶段**：客户端从 `/vpn/list` 获取租户 DNS 与中心 DNS 两组配置，接入云 VPN 后由接入 POP 分配虚拟 IP 与 tun IP；出口 CPE 已通过 gRPC 49920 与中心 DNS 建立长连接。 2. **域名判定**：应用发起 DNS 查询到本地 `dnsproxy`，Bloom Filter 命中即走中心 DNS，否则走租户配置 DNS。 3. **发送查询**：`dnsproxy` 通过 UDP 443 向中心 DNS 发送 DNS 查询，扩展字段携带员工选路信息。 4. **选择出口**：中心 DNS 按租户匹配域名规则；进一步按员工身份匹配出口 CPE。 5. **本地解析**：中心 DNS 通过 gRPC 49920 向出口 CPE 下发解析请求。出口 CPE 向 DNS 服务器发起本地解析，获得业务 A 记录后回传给中心 DNS。 6. **返回解析结果**：中心 DNS 将 A 记录 + tun IP 通过 UDP 443 回给客户端；客户端 `dnsproxy` 分配 fake IP，建立"真实 IP ↔ fake IP"映射，最终返回 fake IP 给应用。 7. **数据面转发**：应用以 fake IP 发包，客户端做 DNAT 转为 tun IP 进入 WireGuard 隧道；沿"接入 POP → 骨干 → 出口 POP → 出口 CPE"到达，出口 CPE 恢复业务真实目的 IP 后 SNAT 转发到目的资源；回包经隧道返回客户端，客户端恢复地址后交给应用。 ### 访问示例以下以中国区员工通过云 VPN 访问美国 SaaS 为例。业务域名为 `portal.example.com`，出口位于美国 vCPE。以下网络参数为示例。 **示例网络参数** |元素 |取值（示例） | |---|---| |目标域名 |`portal.example.com` | |客户端物理网卡 IP |`192.168.1.100` | |客户端 VPN 虚拟 IP（接入 POP 分配） |`100.64.10.5` | |员工身份（脱敏） |`openUID=1234`，`deviceID=5678` | |接入 POP · POP\-VPN（SH\-POP） |`192.0.2.10`（对外 WireGuard，端口按租户随机） | |中心 DNS 服务 IP |`10.100.0.53`（UDP 443） | |出口 POP（US\-POP） |骨干出口 POP | |出口 CPE · US\-vCPE（cpe\-us\-1） |物理网卡 `10.20.30.40` | |出口 CPE tun IP（出口 POP 分配下发） |`169.254.1.10` | |业务真实 IP（出口 CPE 本地解析结果） |`203.0.113.50` | |客户端本地 fake IP |`30.100.0.7`（拿到响应时 dnsproxy 分配） | **阶段 1：DNS 解析** 解析路径：客户端 → 中心 DNS → 出口 CPE。 1. 应用发起 `gethostbyname("portal.example.com")`，系统 DNS 指向 `dnsproxy`。 2. `dnsproxy` 通过 Bloom Filter 判定命中 → 走中心 DNS 而不是租户配置 DNS。 3. `dnsproxy` 构造 DNS 查询报文，扩展字段填入员工选路信息 `{租户=T, openUID=1234, deviceID=5678, 客户端虚 IP=100.64.10.5, 连接模式=WireGuard}`。 4. 通过 **UDP 443** 向中心 DNS `10.100.0.53` 发送查询。 5. 中心 DNS 匹配租户 T 的域名规则，命中 `portal.example.com`；进一步按员工身份匹配得出口 CPE = `cpe-us-1`（US\-vCPE）。 6. 中心 DNS 通过与 `cpe-us-1` 建立的 **gRPC 49920** 长连接下发解析请求： *"请为租户 T 本地解析 portal.example.com"* 。 7. US\-vCPE 根据 /etc/resolv.conf 配置向 DNS 服务器请求 A 记录，得 `A = 203.0.113.50`。 8. US\-vCPE 沿 gRPC 长连接把 A 记录回传中心 DNS。 9. 中心 DNS 根据"出口 POP 已分配给 US\-vCPE 的 tun IP"取到 `tun IP = 169.254.1.10`，把 `A + tun IP` 通过 UDP 443 响应给客户端 `dnsproxy`。 10. `dnsproxy` 从 `30.100.0.0/16` 分配 fake IP `30.100.0.7`，建立三段映射 `fake IP 30.100.0.7 ↔ 真实 IP 203.0.113.50 ↔ tun IP 169.254.1.10`；把 `30.100.0.7` 作为 A 记录返回给应用。 **阶段 2：请求转发** 以下报文结构展示客户端 wg\-go 完成 DNAT 后、报文进入 WireGuard 隧道时的报文格式。后续表格列出报文从应用层到目的服务器逐跳的字段变化。 ```text +------------------------------------------------------------+ | Outer IP Header (IPv4) | | | | src = 192.168.1.100 (Client physical NIC) | | dst = 192.0.2.10 (Ingress POP · POP-VPN) | | proto = 17 (UDP) TTL = 64 | +------------------------------------------------------------+ | Outer UDP Header | | | | sport = dport = | | (per-tenant, randomized) | +------------------------------------------------------------+ | WireGuard Transport Data | | | | msg_type = 4 (Transport Data) | | receiver_index / counter / encrypted-payload | | AEAD encrypted with per-tenant WireGuard session key | +------------------------------------------------------------+ [ Encrypted · carries the inner packet ] +------------------------------------------------------------+ | Inner IP Header (IPv4) | | | | src = 100.64.10.5 (Client VPN vIP) | | dst = 169.254.1.10 (Egress CPE tun IP) | | proto = 6 (TCP) TTL = 64 | | options : original_dst = 203.0.113.50 | +------------------------------------------------------------+ | Inner TCP Header | | | | sport = dport = 443 | | flags = SYN | +------------------------------------------------------------+ | Application Payload | | | | TLS ClientHello · SNI = portal.example.com | +------------------------------------------------------------+ ``` 应用向 `30.100.0.7:443` 发起 TCP SYN，报文从内到外的字段变化如下： |跳点 |内层 src |内层 dst |备注 | |---|---|---|---| |① 应用发出 |`100.64.10.5` |`30.100.0.7` (fake IP) |应用视角 | |② 客户端 wg\-go DNAT |`100.64.10.5` |`169.254.1.10` (tun IP) |原 dst=`203.0.113.50` 写入 IP option 供出口 CPE 恢复 | |③ 客户端 WireGuard 封装 |外层 `192.168.1.100:随机 → 192.0.2.10:租户 WG 端口` ||UDP，端口按租户随机分配 | |④ 接入 POP · POP\-VPN 解封装 |`100.64.10.5` |`169.254.1.10` |按 tun IP 路由到骨干 | |⑤ 接入 POP → 出口 POP 骨干转发 |外层封装保持，报文在 POP 间沿骨干跨区路由（非 WireGuard） ||骨干隧道 | |⑥ 出口 POP → US\-vCPE |`100.64.10.5` |`169.254.1.10` |通过 WireGuard 隧道转发到出口 CPE | |⑦ US\-vCPE 目的地址恢复与 SNAT |`10.20.30.40` (物理网卡) |`203.0.113.50` (真实 IP) |从 IP option 还原 dst；SNAT 出网 | **阶段 3：回包处理** 回包依次经过目标服务器、出口 CPE、出口 POP、骨干网络和接入 POP，返回客户端 wg\-go。以下报文结构对应接入 POP 向客户端 wg\-go 发送的 WireGuard 报文：外层为最后一跳的公网 UDP 报文，内层已由出口 CPE 完成回程 DNAT，真实源地址保存在 IP option 中。客户端 wg\-go 收到后，根据映射将内层源地址从 tun IP 恢复为 fake IP，再交给应用。 ```text +------------------------------------------------------------+ | Outer IP Header (IPv4) | | | | src = 192.0.2.10 (Ingress POP · POP-VPN) | | dst = 192.168.1.100 (Client physical NIC) | | proto = 17 (UDP) TTL = 64 | +------------------------------------------------------------+ | Outer UDP Header | | | | sport = dport = | +------------------------------------------------------------+ | WireGuard Transport Data | | | | msg_type = 4 (Transport Data) | | receiver_index / counter / encrypted-payload | | AEAD encrypted with per-tenant WireGuard session key | +------------------------------------------------------------+ [ Encrypted · carries the inner packet ] +------------------------------------------------------------+ | Inner IP Header (IPv4) | | | | src = 169.254.1.10 (Egress CPE tun IP) | | dst = 100.64.10.5 (Client VPN vIP) | | proto = 6 (TCP) TTL = 64 | | options : original_src = 203.0.113.50 | +------------------------------------------------------------+ | Inner TCP Header | | | | sport = 443 dport = | | flags = SYN + ACK | +------------------------------------------------------------+ | Application Payload | | | | TLS ServerHello · portal.example.com | +------------------------------------------------------------+ ``` 随后客户端 wg\-go 依据本地映射把内层 `src = 169.254.1.10` 恢复为 `src = 30.100.0.7`（fake IP），并根据 IP option 中的 `original_src = 203.0.113.50` 保持四元组一致性，最终应用侧看到 `src=30.100.0.7:443, dst=100.64.10.5:`。 1. 目的服务器 `203.0.113.50` 回包，`src=203.0.113.50, dst=10.20.30.40`。 2. US\-vCPE 匹配 SNAT 会话反向恢复 `dst=100.64.10.5`；同时把 src 记入 IP option，改为 `src=169.254.1.10`。 3. 沿"出口 CPE → 出口 POP → 骨干 → 接入 POP → 客户端"反向隧道回到客户端。 4. 客户端 wg\-go 收到内层 `src=169.254.1.10, dst=100.64.10.5`，从 IP option 读回真实 src `203.0.113.50`，根据已有映射恢复为 `30.100.0.7`（fake IP）。 5. 应用看到回包 `src=30.100.0.7, dst=100.64.10.5`，与请求对应同一连接。 ## 分支组网调度流程分支终端的 DNS 查询由入口 CPE 接收。入口 CPE 负责域名分流和接入侧报文转换，中心 DNS 根据入口 CPE 选择出口。 **入口 CPE 的 DNS 分流** * 分支终端将入口 CPE LAN IP 作为默认 DNS。 * 入口 CPE 上的 `dnsmasq` 按**域名后缀严格匹配**判定： * 命中调度域名 → 通过 **UDP 443** 转发到中心 DNS； * 未命中 → 转发到上游 DNS 服务器（公共递归 / 客户自建）。 **扩展字段（分支选路）** 请求扩展字段携带"租户 + 入口 CPE 标识"，中心 DNS 用其定位租户，然后**按入口 CPE 匹配出口 CPE**；未命中则回落到租户级默认出口。同一域名在不同分支可以走不同出口。 ### 调度时序 ![图片](https://lf3-static.bytednsdoc.com/obj/eden-cn/809eh7uhkbd/topic-docs/feilian/sdwan-domain-20261012/topic-branch.svg) **处理过程** 1. **预置阶段**：分支入口和出口 CPE 均已被 POP 分配 tun IP；出口 CPE 已通过 gRPC 49920 与中心 DNS 建立长连接。 2. **入口分流**：分支终端 DNS 请求先到入口 CPE，`dnsmasq` 按域名后缀严格匹配判定是否为调度域名。 3. **发送查询**：命中即通过 UDP 443 转到中心 DNS，扩展字段携带分支选路信息（租户 + 入口 CPE）。 4. **选择出口**：中心 DNS 按租户匹配域名规则；进一步按入口 CPE 匹配出口 CPE，未命中回落到租户默认出口。 5. **本地解析**：中心 DNS 通过 gRPC 49920 向出口 CPE 下发解析请求。出口 CPE 向 DNS 服务器发起本地解析并回传结果。 6. **返回解析结果**：中心 DNS 将 A 记录 + tun IP 通过 UDP 443 回给入口 CPE；入口 CPE 响应给分支终端。 7. **数据面转发**：分支终端按 A 记录发包，入口 CPE 做 DNAT + WireGuard 隧道封装，沿"接入 POP → 骨干 → 出口 POP → 出口 CPE"到达；出口 CPE 恢复业务真实目的地址后 SNAT 转发到目的资源，回包经隧道返回入口 CPE，入口 CPE 恢复地址后转发给分支终端。 ### 访问示例以下以中国区分支办公室通过分支组网访问美国资源为例。业务域名为 `portal.example.com`，出口位于美国 vCPE。以下网络参数为示例。 **示例网络参数** |元素 |取值（示例） | |---|---| |目标域名 |`portal.example.com` | |分支终端 IP |`10.10.1.50` | |入口 CPE LAN IP（同时也是分支 DNS） |`10.10.1.1` | |入口 CPE ID |`cpe-sh-1，WAN IP 198.51.100.20（示例）` | |入口 CPE tun IP（接入 POP 分配下发） |`169.254.2.20` | |接入 POP（SH\-POP） |公网 192.0.2.10（WireGuard 端口按租户随机） | |中心 DNS 服务 IP |`10.100.0.53`（UDP 443） | |出口 POP（US\-POP） |骨干出口 POP | |出口 CPE · US\-vCPE（cpe\-us\-1） |物理网卡 `10.20.30.40` | |出口 CPE tun IP（出口 POP 分配下发） |`169.254.1.10` | |业务真实 IP（出口 CPE 本地解析结果） |`203.0.113.50` | **阶段 1：DNS 解析** 解析路径：分支终端 → 入口 CPE → 中心 DNS → 出口 CPE。 1. 分支终端 `10.10.1.50` 向 `10.10.1.1:53`（入口 CPE LAN DNS）发起 DNS 查询 `portal.example.com`。 2. 入口 CPE 上 `dnsmasq` 按域名后缀严格匹配命中调度域名 → 进入中心 DNS 转发路径。 3. `dnsmasq` 构造 DNS 查询报文，扩展字段填入分支选路信息 `{租户=T, 入口 CPE=cpe-sh-1，WAN IP 198.51.100.20（示例）}`。 4. 通过 **UDP 443** 向中心 DNS `10.100.0.53` 发送查询。 5. 中心 DNS 匹配租户 T 的域名规则命中 `portal.example.com`；进一步按入口 CPE `cpe-sh-1，WAN IP 198.51.100.20（示例）` 匹配到出口 CPE = `cpe-us-1`（US\-vCPE）；若未命中则回落到租户默认出口。 6. 中心 DNS 通过与 `cpe-us-1` 建立的 **gRPC 49920** 长连接下发解析请求： *"请为租户 T 本地解析 portal.example.com"* 。 7. US\-vCPE 根据 /etc/resolv.conf 配置向 DNS 服务器请求，得 `A = 203.0.113.50`。 8. US\-vCPE 沿 gRPC 长连接把 A 记录回传中心 DNS。 9. 中心 DNS 从出口 POP 已分配的 tun IP 表取到 `tun IP = 169.254.1.10`，把 `A + tun IP` 通过 UDP 443 响应给入口 CPE。 10. 入口 CPE 在本地建立 `203.0.113.50 ↔ 169.254.1.10` 映射，然后把 `A = 203.0.113.50` 作为 DNS 响应返回给分支终端（分支终端不感知 tun IP）。 **阶段 2：请求转发** 以下报文结构展示入口 CPE 完成 DNAT 后、报文进入 WireGuard 隧道时的报文格式。后续表格列出报文从分支终端到目的服务器逐跳的字段变化。 ```text +------------------------------------------------------------+ | Outer IP Header (IPv4) | | | | src = 198.51.100.20 (Ingress CPE WAN) | | dst = 192.0.2.10 (Ingress POP) | | proto = 17 (UDP) TTL = 64 | +------------------------------------------------------------+ | Outer UDP Header | | | | sport = dport = | | (per-tenant, randomized) | +------------------------------------------------------------+ | WireGuard Transport Data | | | | msg_type = 4 (Transport Data) | | receiver_index / counter / encrypted-payload | | AEAD encrypted with per-tenant WireGuard session key | +------------------------------------------------------------+ [ Encrypted · carries the inner packet ] +------------------------------------------------------------+ | Inner IP Header (IPv4) | | | | src = 10.10.1.50 (Branch endpoint) | | dst = 169.254.1.10 (Egress CPE tun IP) | | proto = 6 (TCP) TTL = 64 | | options : original_dst = 203.0.113.50 | +------------------------------------------------------------+ | Inner TCP Header | | | | sport = dport = 443 | | flags = SYN | +------------------------------------------------------------+ | Application Payload | | | | TLS ClientHello · SNI = portal.example.com | +------------------------------------------------------------+ ``` 分支终端向 `203.0.113.50:443` 发起 TCP SYN，报文从内到外的字段变化如下： |跳点 |内层 src |内层 dst |备注 | |---|---|---|---| |① 分支终端发出 |`10.10.1.50` |`203.0.113.50` |终端视角，dst 为业务真实 IP | |② 入口 CPE 命中 SD\-WAN PBR + DNAT |`10.10.1.50` |`169.254.1.10` (出口 CPE tun IP) |按之前建立的 `203.0.113.50 ↔ 169.254.1.10` 映射转换；原 dst 存入 IP option 供恢复 | |③ 入口 CPE WireGuard 封装 |外层 `198.51.100.20 (入口 CPE WAN) → 192.0.2.10 (接入 POP):(租户 WG 端口)` ||UDP，端口按租户随机分配 | |④ 接入 POP 解封装 |`10.10.1.50` |`169.254.1.10` |按 tun IP 路由到骨干 | |⑤ 接入 POP → 出口 POP 骨干转发 |外层封装保持，报文在 POP 间沿骨干跨区路由（非 WireGuard） ||骨干隧道 | |⑥ 出口 POP → US\-vCPE |`10.10.1.50` |`169.254.1.10` |通过 WireGuard 隧道转发到出口 CPE | |⑦ US\-vCPE 目的地址恢复与 SNAT |`10.20.30.40` (物理网卡) |`203.0.113.50` (真实 IP) |从 IP option 恢复真实 dst；SNAT 出网 | **阶段 3：回包处理** 回包依次经过目标服务器、出口 CPE、出口 POP、骨干网络和接入 POP，返回入口 CPE。以下报文结构对应接入 POP 向入口 CPE 发送的 WireGuard 报文：外层为最后一跳的公网 UDP 报文，内层已由出口 CPE 完成回程 DNAT，真实源地址保存在 IP option 中。入口 CPE 收到后，根据映射将内层源地址从 tun IP 恢复为业务真实 IP，再交给分支终端。 ```text +------------------------------------------------------------+ | Outer IP Header (IPv4) | | | | src = 192.0.2.10 (Ingress POP) | | dst = 198.51.100.20 (Ingress CPE WAN) | | proto = 17 (UDP) TTL = 64 | +------------------------------------------------------------+ | Outer UDP Header | | | | sport = dport = | +------------------------------------------------------------+ | WireGuard Transport Data | | | | msg_type = 4 (Transport Data) | | receiver_index / counter / encrypted-payload | | AEAD encrypted with per-tenant WireGuard session key | +------------------------------------------------------------+ [ Encrypted · carries the inner packet ] +------------------------------------------------------------+ | Inner IP Header (IPv4) | | | | src = 169.254.1.10 (Egress CPE tun IP) | | dst = 10.10.1.50 (Branch endpoint) | | proto = 6 (TCP) TTL = 64 | | options : original_src = 203.0.113.50 | +------------------------------------------------------------+ | Inner TCP Header | | | | sport = 443 dport = | | flags = SYN + ACK | +------------------------------------------------------------+ | Application Payload | | | | TLS ServerHello · portal.example.com | +------------------------------------------------------------+ ``` 入口 CPE 收到解密后的内层报文，从 IP option 读回 `original_src = 203.0.113.50`，将内层 `src = 169.254.1.10` 恢复为 `src = 203.0.113.50`，再按分支 LAN 路由转发给分支终端；分支终端最终看到 `src=203.0.113.50:443, dst=10.10.1.50:`，与请求对应同一连接。 1. 目的服务器 `203.0.113.50` 回包，`src=203.0.113.50, dst=10.20.30.40`。 2. US\-vCPE 匹配 SNAT 会话反向恢复内层 `dst=10.10.1.50`；同时把 src 记入 IP option，改为 `src=169.254.1.10`。 3. 沿"出口 CPE → 出口 POP → 骨干 → 接入 POP → 入口 CPE"反向隧道回到入口 CPE。 4. 入口 CPE 收到内层 `src=169.254.1.10, dst=10.10.1.50`，从 IP option 读回真实 src `203.0.113.50`，恢复源地址后转发给分支终端。 5. 分支终端看到回包 `src=203.0.113.50, dst=10.10.1.50`，与之前发出的四元组一致。 ## 两种场景差异两种场景共用中心 DNS 调度能力，但 DNS 入口、域名判定方式、出口选择依据和终端看到的地址不同。 |维度 |云 VPN + 员工选路 |分支组网 + 分支选路 | |---|---|---| |DNS 查询入口 |客户端 `dnsproxy` |入口 CPE `dnsmasq` | |查询协议 / 端口 |UDP 443 |UDP 443 | |调度域名判定方式 |Bloom Filter 命中 |域名后缀严格匹配 | |后缀匹配限制 |二 / 三级；不支持四级及以上；`*.abc.com` 等价于 `abc.com` |任意深度后缀；不支持通配符 `*.abc.com` | |选择出口依据 |按用户身份匹配出口 CPE（可能覆盖客户端建议值） |按入口 CPE 匹配出口 CPE，未命中回落默认出口 | |fake IP 归属 |客户端本地分配 `30.100.x.y` |入口 CPE 返回业务真实 IP，不向分支终端分配 fake IP | |数据接入 |接入 POP（POP\-VPN） |入口 CPE → 接入 POP | |数据出口 |出口 POP → 出口 CPE |出口 POP → 出口 CPE | |调度粒度 |员工级 / 设备级 |分支级 / 入口 CPE 级 | ## 域名匹配规则与注意事项客户端与分支入口 CPE 的域名匹配方式不同。同一规则用于两种场景时，需要同时考虑域名层级、通配符和后缀范围。 |配置写法 |云 VPN 客户端侧（Bloom Filter） |分支侧（dnsmasq 后缀匹配） | |---|---|---| |`abc.com` |命中 `abc.com` 及其任意子域 |命中所有以 `.abc.com` 结尾的域名 | |`*.abc.com` |等价于 `abc.com` |**不生效**（不识别通配符） | |`x.y.z.abc.com`（四级及以上） |**不生效** |命中该后缀所有域名 | |`x.com` |命中 `x.com` 及其子域 |命中所有以 `x.com` 结尾的域名（含 `abcx.com`） | * **云 VPN 侧四级域限制**：需区分 `a.b.c.example.com` 与 `d.e.f.example.com` 的场景，客户端侧不支持，需由分支侧匹配规则处理。 * **分支侧短后缀风险**：不要用不足以唯一标识业务的短后缀（如 `x.com`），必要时改用精确匹配或延长后缀。 * **DoH / Secure DNS 绕过**：Chrome / Firefox Secure DNS 会绕过客户端 `dnsproxy` 直接走公共 DNS，调度必然失效。 ## 必要的协议及端口说明域名查询、出口侧解析协调和业务隧道使用不同链路。客户端及入口 CPE 通过 UDP 443 查询中心 DNS；出口 CPE 主动建立 TCP 49920 的 gRPC 双向连接，供中心 DNS 下发解析请求及接收结果。 |链路 |发起方 |端口 |协议 / 报文 |用途 | |---|---|---|---|---| |云 VPN 客户端 → 中心 DNS |客户端 `dnsproxy` |**UDP 443** |DNS 报文 + 扩展字段（云 VPN 客户端选路 / 员工选路） |调度域名解析；**无状态、非 gRPC** | |入口 CPE → 中心 DNS |入口 CPE `dnsmasq` |**UDP 443** |DNS 报文 + 扩展字段（分支选路） |调度域名解析；**无状态、非 gRPC** | |出口 CPE ↔ 中心 DNS |出口 CPE 主动 |**TCP 49920** |**gRPC 双向长连接** |承载出口 CPE 注册、心跳，以及中心 DNS 下发的解析请求 | |客户端 / CPE ↔ 接入 POP |数据面 |UDP（端口按租户随机分配） |WireGuard |数据隧道；**tun IP 由接入 POP 分配下发** | |出口 POP ↔ 出口 CPE |数据面 |UDP（端口按租户随机分配） |WireGuard |数据隧道；**出口 CPE 侧 tun IP 由出口 POP 分配下发** | |骨干 POP ↔ POP |数据面 |— |骨干跨区转发（不使用 WireGuard） |负责将内层报文在 POP 间路由转发 | **链路与地址分配说明** * **所有 DNS 查询到中心 DNS 都走 UDP 443**（不是 53、也不是 gRPC 49920）。查询链路是无状态的，中心 DNS 不需要对海量客户端 / 入口 CPE 维护长连接。 * **gRPC 49920 只用于出口 CPE 一侧**：中心 DNS 通过该连接向出口 CPE 下发解析请求。日志信息 `dns_grpc: connection refused` 特指该通道异常。 * **tun IP（** **`169.254.x.y`** **）由 POP 分配下发**，CPE 自身不分配。POP 集中管理避免网段冲突，并统一维护隧道地址的分配。 ### 地址网段与映射关系下表汇总各类地址的用途、分配方和生成时机。隧道虚拟 IP 由 POP 分配，客户端 fake IP 在获得调度响应后由客户端分配。 |映射 / 网段 |默认网段 |分配 / 维护方 |生成时机 | |---|---|---|---| |tun IP（隧道虚拟 IP） |`169.254.0.0/16` |**接入和出口 POP 分配** |WireGuard 隧道建立时 | |fake IP ↔ 真实 IP |`30.100.0.0/16` |客户端 `dnsproxy` 本地分配 |拿到中心 DNS 响应时 | |fake IP ↔ tun IP |客户端内部 |客户端 `wg-go` |发包做 DNAT 时 | |tun IP ↔ 真实 IP |出口 CPE 内部 |出口 CPE dst restore |报文过 CPE 时 | |客户端虚拟 IP |`100.64.0.0/16` |接入 POP 分配 |客户端接入云 VPN 时 |