第213篇：分支与总部 IPsec VPN 组网

关键词：IPsec VPN、Hub-Spoke、Full-Mesh、分支互联、总部互联、NAT-Keepalive、VPN路由、IPsec组网拓扑

一、引言

在实际企业网络中，IPsec VPN 最常见的应用场景是总部与多个分支机构之间的组网互联。前几篇文章介绍了 IPsec 的封装模式、IKE 协商机制等底层技术。当网络规模从一个站点扩展到多个站点时，如何设计 VPN 拓扑、配置路由策略、实现分支互联，成为网络工程师面临的核心挑战。

分支与总部 IPsec VPN 组网的核心问题是：选择 Hub-Spoke（星型）还是 Full-Mesh（全网状）拓扑？分支之间如何互通？动态 IP 和 NAT 环境如何处理？

二、核心概念

2.1 Hub-Spoke（星型）拓扑

Hub-Spoke 拓扑中，所有分支机构（Spoke）只与总部（Hub）建立 IPsec VPN 隧道。总部作为中心节点，负责转发各分支之间的流量。

Hub-Spoke（星型）拓扑 - 图示

2.2 Full-Mesh（全网状）拓扑

Full-Mesh 拓扑中，每两个站点之间都建立独立的 IPsec VPN 隧道。N 个站点需要 N(N-1)/2 条隧道。

Full-Mesh（全网状）拓扑 - 图示

2.3 拓扑对比

对比维度 Hub-Spoke（星型） Full-Mesh（全网状）
隧道数量 N-1 条 N(N-1)/2 条
配置复杂度 低（分支只需配置到总部一条隧道） 高（每个站点需配置 N-1 条隧道）
流量路径 分支间流量经总部绕行 分支间直连，路径最短
总部性能压力 高（所有流量经总部转发） 无（总部只处理本地流量）
单点故障 总部故障导致全网断联 单点故障影响局部
带宽成本 总部链路需承载所有流量 分散负载，带宽利用率高
适用规模 中小规模（10 个站点以内） 大规模或高带宽需求

2.4 分支互联模式

模式 说明
Hub 转发（默认） 分支间流量经总部转发，需总部开启 VPN 间转发
Spoke-to-Spoke 在总部协助下，分支间动态建立直连隧道
Hub-Spoke + Full-Mesh 混合 重要分支之间建立直连隧道，其余经总部转发

三、技术细节

3.1 Hub-Spoke 拓扑配置要点

Hub-Spoke 拓扑配置要点 - 图示

3.2 Spoke-to-Spoke（分支直连）机制

在 Hub-Spoke 拓扑中，如果希望分支之间直连通信而不经过总部，可以使用 IKE 的 Spoke-to-Spoke 特性。其工作原理是：

  1. 两个分支均与总部建立 IPsec VPN 隧道
  2. 当北京分支发起对上海分支的业务流量时，流量首先到达总部
  3. 总部检测到流量穿越两个不同隧道，通过 IKE 通知消息将上海分支的公网 IP 告知北京分支
  4. 北京分支与上海分支直接建立新的 IPsec SA，后续流量直连

3.3 NAT Keepalive 机制

当分支网关位于 NAT 设备后方时，NAT 设备会定期清理空闲的映射表项。如果 IPsec VPN 隧道长时间无业务流量，NAT 映射被清除，隧道中断。NAT Keepalive 机制定期发送空的 ESP 报文（Type 0 Payload），维持 NAT 映射表项的存活。

3.4 路由设计原则

原则 说明
静态路由 + ACL 小规模网络，静态路由指向对端 VPN 隧道
OSPF over IPsec 中等规模，在 IPsec 隧道上运行 OSPF 动态路由
BGP over IPsec 大规模网络，利用 BGP 的路由策略和冗余能力
汇总路由 总部向分支通告汇总路由，减少路由表规模
默认路由 分支向总部通告默认路由，简化分支配置

四、实战配置/案例分析

4.1 华为 AR 路由器：Hub-Spoke 完整配置

# ========== 总部侧配置 ==========
system-view
sysname HQ-Router

# 总部内网接口
interface GigabitEthernet 0/0/0
 ip address 10.100.0.1 255.255.0.0
 quit

# 公网接口
interface GigabitEthernet 0/0/1
 ip address 203.0.113.1 255.255.255.252
 quit

# ===== 到北京分支的IPsec VPN =====
ike peer BJ-Branch
  version v1
  address 203.0.113.5
  authentication-mode pre-shared-key
  pre-shared-key cipher Huawei@BJ2024
  proposal 1
  exchange-mode main
quit

acl 3000
 rule 5 permit ip source 10.100.0.0 0.0.255.255 destination 10.10.1.0 0.0.0.255
quit

ipsec proposal HQ-BJ
 encapsulation-mode tunnel
 auth-algorithm sha256
 encrypt-algorithm aes-256
 dh-group group14
quit

ipsec policy HQ-BJ-Policy 10 isakmp
 security-acquire-method ike
 proposal HQ-BJ
 conn acl 3000
 peer BJ-Branch
quit

interface GigabitEthernet 0/0/1
 ipsec policy HQ-BJ-Policy
 quit

# ===== 到上海分支的IPsec VPN =====
ike peer SH-Branch
  version v1
  address 198.51.100.5
  authentication-mode pre-shared-key
  pre-shared-key cipher Huawei@SH2024
  proposal 1
quit

acl 3001
 rule 5 permit ip source 10.100.0.0 0.0.255.255 destination 10.20.1.0 0.0.0.255
quit

ipsec proposal HQ-SH
 encapsulation-mode tunnel
 auth-algorithm sha256
 encrypt-algorithm aes-256
 dh-group group14
quit

ipsec policy HQ-SH-Policy 10 isakmp
 security-acquire-method ike
 proposal HQ-SH
 conn acl 3001
 peer SH-Branch
quit

interface GigabitEthernet 0/0/1
 ipsec policy HQ-SH-Policy
 quit

# 到各分支的路由
ip route-static 10.10.1.0 255.255.255.0 203.0.113.5
ip route-static 10.20.1.0 255.255.255.0 198.51.100.5

# 允许VPN间转发（北京访问上海流量经总部转发）
ipsec policy VPN-Inter-Forward 10 advance
 utp inbound-policy HQ-BJ-Policy
 utp outbound-policy HQ-SH-Policy
quit

acl 3002
 rule 5 permit ip source 10.10.1.0 0.0.0.255 destination 10.20.1.0 0.0.0.255
quit

ipsec policy VPN-Inter-Forward 20 isakmp
 security-acquire-method manual
 proposal HQ-BJ
 conn acl 3002
quit

interface GigabitEthernet 0/0/1
 ipsec policy VPN-Inter-Forward
 quit

# ========== 北京分支侧配置 ==========
system-view
sysname BJ-Router

# 内网接口
interface GigabitEthernet 0/0/0
 ip address 10.10.1.1 255.255.255.0
 quit

# 公网接口
interface GigabitEthernet 0/0/1
 ip address 203.0.113.6 255.255.255.252
 quit

ike peer HQ
  version v1
  address 203.0.113.1
  authentication-mode pre-shared-key
  pre-shared-key cipher Huawei@BJ2024
  proposal 1
  exchange-mode main
quit

acl 3000
 rule 5 permit ip source 10.10.1.0 0.0.0.255 destination 10.100.0.0 0.0.255.255
quit

ipsec proposal BJ-HQ
 encapsulation-mode tunnel
 auth-algorithm sha256
 encrypt-algorithm aes-256
 dh-group group14
quit

ipsec policy BJ-HQ-Policy 10 isakmp
 security-acquire-method ike
 proposal BJ-HQ
 conn acl 3000
 peer HQ
quit

interface GigabitEthernet 0/0/1
 ipsec policy BJ-HQ-Policy
 quit

# 到总部的路由
ip route-static 10.100.0.0 255.255.0.0 203.0.113.1
# 到上海分支的路由（经总部转发）
ip route-static 10.20.1.0 255.255.255.0 203.0.113.1

4.2 故障排查案例：分支间流量无法互通

故障现象：北京分支和上海的 IPsec VPN 分别到总部正常建立，但北京分支无法 ping 通上海分支的内网地址。

排查步骤：

  1. 检查总部侧 SA 状态
display ipsec sa

显示北京到总部、上海到总部的 SA 均处于 ACTIVE 状态。

  1. 检查总部侧路由表
display ip routing-table

确认存在指向两个分支的路由条目。

  1. 检查总部侧 ACL 匹配
display acl 3002

发现 ACL 3002（用于 VPN 间转发）的命中计数为 0，说明北京到上海的流量未被正确匹配。

  1. 根因分析 总部配置了独立的 IPsec policy（HQ-BJ-Policy 和 HQ-SH-Policy），但两个策略分别绑定到独立的 ACL。当北京分支的流量到达总部后，总部解封装得到原始 IP 报文（源 10.10.1.x，目的 10.20.1.x），需要重新匹配到上海的 IPsec 策略进行二次封装。但总部没有配置跨隧道的策略映射。

  2. 解决方案

# 方法一：配置统一IPsec策略，覆盖所有分支间流量
acl 3003
 rule 5 permit ip source 10.10.0.0 0.0.255.255 destination 10.20.0.0 0.0.255.255
quit

# 在总部配置统一的IPsec策略，支持多分支间流量
ipsec policy HQ-Unified 10 isakmp
 security-acquire-method ike
 proposal HQ-BJ
 conn acl 3003
 peer BJ-Branch
quit

ipsec policy HQ-Unified 20 isakmp
 security-acquire-method ike
 proposal HQ-SH
 conn acl 3003
 peer SH-Branch
quit

interface GigabitEthernet 0/0/1
 ipsec policy HQ-Unified
 quit

修改后，北京到上海的 ping 测试正常，display ipsec sa 显示跨分支 SA 流量计数持续增长。

五、总结

知识点 要点
Hub-Spoke 拓扑 所有分支连接总部，N-1 条隧道，配置简单
Full-Mesh 拓扑 每两个站点直连，N(N-1)/2 条隧道，路径最优
分支互联 Hub 转发（默认）或 Spoke-to-Spoke（直连）
NAT Keepalive 维持 NAT 映射表项，避免空闲隧道中断
路由设计 静态路由适用于小网络，OSPF/BGP 适用于大规模
VPN 间转发 总部需配置跨隧道的 IPsec 策略映射
常见故障 总部未配置跨隧道策略导致分支间无法互通

思考

  1. 当总部防火墙性能有限时，Hub-Spoke 拓扑中总部需要转发所有分支间流量，会造成瓶颈。有哪些方案可以缓解总部的性能压力？
  2. 如果一个企业有 20 个分支站点，采用 Full-Mesh 拓扑需要建立多少条 IPsec 隧道？配置和维护的工作量是否可控？
  3. Spoke-to-Spoke 机制依赖总部协助交换分支公网 IP 地址。如果分支使用动态公网 IP（如 4G CPE），这种机制还能正常工作吗？

下篇预告：第214篇：L2TP over IPsec 远程拨号