动态 IP 场景下的 Site-to-Site VPN组网方案

摘要：在企业混合云组网中，Site-to-Site VPN 是连接办公地点与亚马逊云科技的常用方案。然而，当办公地点使用部分 ISP 接入时，公网 IP 为动态分配，按照以往的经验，Customer Gateway需要固定 IP， IP变化会导致隧道中断，无法自动恢复。
本文介绍一种解决方案，IP变化后隧道可自动恢复的配置方式，并阐述方案原理、架构设计及部署步骤。

01 一、背景与原理分析

02 二、方案架构

03 三、部署与动手实验

04 四、总结

05 五、参考资料

一、背景与原理分析

1.1 客户场景

某跨国企业在海外偏远地区设有办公地点，核心业务系统部署在亚马逊云科技。办公地点通过当地运营商提供的固网线路，以 Site-to-Site VPN方式接入亚马逊云科技网络。由于当地运营商网络偶尔出现丢包，客户决定新增一条互联网线路作为冗余，以提高网络可靠性。

然而，新增线路是卫星互联网，它的公网 IP 为动态分配，不具备固定 IP。而 Site-to-Site VPN 创建 Customer Gateway 时，按照以往的经验，认证方式要求提供对端设备的固定公网 IP 地址。公网 IP 一旦变化，VPN 隧道将中断，业务访问受阻，无法满足生产环境的稳定性要求。

1.2 原理分析

1. VPN 与 IPsec 的关系

VPN（Virtual Private Network）：让两个物理上隔离的私有网络，通过公共互联网安全地互相通信。IPsec 是实现 VPN 最常用的协议族之一——它定义了”怎么加密、怎么认证、怎么封装”。在 Site-to-Site VPN 中，底层正是基于 IPsec 实现的。

2. IPsec 建立连接的两个阶段

IPsec 建立一条 VPN 隧道分为两个阶段，各自解决不同的问题：

┌─────────────────────────────────────────────────────────────┐
│  阶段 1：IKE SA 协商                                         │
│  ─────────────────────                                      │
│  • 双方互相确认身份（PSK 或证书）                             │
│  • 协商加密参数（算法、DH 组）                                │
│  • Diffie-Hellman 密钥交换生成共享密钥                        │
│  • 协议：UDP 500 / UDP 4500（NAT-T）                         │
│                                                             │
│  产物：IKE SA（一条安全的控制通道）                            │
└──────────────────────────┬──────────────────────────────────┘
                           │ 基于 IKE SA 的安全通道
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  阶段 2：Child SA（IPsec SA）协商                            │
│  ─────────────────────────────                              │
│  • 协商业务流量的加密参数和密钥                                │
│  • 确定保护的流量范围（Traffic Selector）                     │
│  • 协议：仍通过 IKE 通道协商                                  │
│                                                             │
│  产物：IPsec SA（使用 ESP 协议加密用户流量，IP 协议号 50）     │
└─────────────────────────────────────────────────────────────┘

阶段 1 解决"信任"问题，阶段 2 解决"加密传输"问题。Customer Gateway 的固定 IP 主要在阶段 1 被使用。

3. 固定 IP 在认证中的作用

当使用 PSK（Pre-Shared Key）认证时，Customer Gateway 的公网 IP 在 IKE 阶段承担了身份标识的角色：

4. 用 IP 查找对应的 PSK

亚马逊云科技侧的 VPN 网关收到 IKE 请求时，第一步是根据来源 IP 查找”这个 IP 对应哪个 Customer Gateway、该用哪个 PSK”：

收到 IKE 请求，来源 IP = 203.0.113.5
    │
    ▼
查找 Customer Gateway 表：
    203.0.113.5 → cgw-abc123 → PSK = "xxxxxxxx"
    198.51.100.1 → cgw-def456 → PSK = "yyyyyyyy"
    │
    ▼
找到匹配，用对应的 PSK 进行认证计算

5. IP 作为身份参与认证计算

找到 PSK 后，双方要互相证明”我确实持有这个 PSK”。证明方式是各自算一个认证值发给对方比对。计算这个认证值时，会把身份标识也算进去——而在 PSK 模式下，身份标识就是 IP 地址：

认证值 = 哈希函数(PSK派生密钥, 协商数据 | 随机数 | 身份标识)
                                                    │
                                                  身份标识 = IP 地址（如 203.0.113.5）

这意味着 IP 不仅用来”找到密钥”，还被绑定进了认证结果本身。IP 一变，算出来的认证值就对不上，认证直接失败。

6. 数据传输阶段：外层 IP 头用于路由和 SA 匹配

隧道建立后，每个加密数据包都带有 SPI（隧道编号）和外层源 IP。接收端用 SPI 找到对应的 SA，通常还会校验源 IP 是否与协商时记录的对端地址一致。IP 变化后，数据包也可能被拒绝。

7. 结论：IP 变了会怎样？

IP 变化
  │
  ├─► IKE 阶段： 找不到匹配的 Customer Gateway → 无法查找 PSK → 无法新建/重建隧道
  │
  └─► 已建立的隧道：新 IP 发出的 ESP 包源地址与 SA 记录不匹配 → 被对端丢弃 → 隧道中断

核心矛盾：IP 本身是一个网络地址，但在 PSK 认证中却被当成了”身份”来用。一旦地址变了，身份就变了，认证就失败了。

8. 解决思路：把身份标识从 IP 地址换成一个不会随网络变化的东西——证书。

9. 证书认证为什么不依赖固定 IP

10. 什么是数字证书？

数字证书是由一个可信的第三方机构（CA，Certificate Authority）签发的”电子身份证”。它包含：

┌─────────────────────────────────────────────┐
│  数字证书                                    │
├─────────────────────────────────────────────┤
│  持有者身份：CN=vpn-client.internal          │  ← 名字（不是 IP）
│  持有者公钥：MIIBIjANBgkqh...                │  ← 公开的，任何人可见
│  签发者：CN=My Private CA                    │  ← 谁担保的
│  有效期：2025-01-01 ~ 2026-01-01             │
│  ───────────────────────────────────────────┤
│  CA 的数字签名：MEUCIQD3...                  │  ← CA 用自己的私钥签的章
└─────────────────────────────────────────────┘

与证书配对的还有一把私钥，只有证书持有者自己保管。公钥和私钥的关系：

私钥签名的数据，可以用公钥验证（证明”这确实是持有者本人操作的”）
公钥是公开的（写在证书里），私钥绝对保密

11. 证书认证的三步验证逻辑

对比 PSK 的三步（用 IP 找 PSK → 用 PSK 算哈希 → 比对哈希），证书认证也是三步，但完全不涉及 IP：

12. 验证证书本身是否可信（”这个身份证是真的吗？”）

Customer Gateway 发来证书：CN=vpn-client.internal，签发者=My Private CA
    │
    ▼
亚马逊云科技侧检查：
    • 我是否信任 "My Private CA"？
      → 查看本地配置的信任 CA 列表 → 找到了 ✅
    • 证书上 CA 的签名能否验证通过？
      → 用 CA 的公钥验证证书上的签名 → 通过 ✅
    • 证书是否过期？是否被吊销？
      → 检查有效期和吊销列表 → 正常 ✅

VPN Endpoint 收到未知 IP 的 IKE 请求时，先完成 DH 密钥交换（IKE_SA_INIT，这一步不需要认证），然后在 IKE_AUTH 阶段根据对方出示的证书及其签发 CA，匹配到对应的 Customer Gateway。

13. 验证对方确实持有该证书的私钥（”拿证书的人是本人吗？”）

证书是公开的，任何人都能拿到一份。所以光出示证书不够，还要证明”我有配对的私钥”：

Customer Gateway 计算：
    认证值 = 用私钥签名(协商数据 | 随机数 | 身份标识)
                 │                             │
                 │                             └─ CN=vpn-client.internal（不是 IP！）
                 └─ 只有持有私钥的人才能算出这个签名
    │
    ▼
亚马逊云科技 侧验证：
    用证书中的公钥验证签名 → 通过 ✅
    （证明对方确实持有私钥，不是拿了别人的证书来冒充）

14. 将身份绑定到本次协商（”这个证明是针对这次连接的吗？”）

和 PSK 类似，认证值中也包含了本次协商的数据（DH 交换结果、随机数），防止重放攻击：

认证值 = 用私钥签名(本次 IKE 协商的完整数据 | 对端随机数 | 身份标识)
                                   │              │
                                   │              └─ 防重放：每次协商随机数不同
                                   └─ 防篡改：协商数据被绑定进签名

15. IP 变化时证书认证的隧道恢复过程

[T0] 隧道正常，IP = 203.0.113.5

[T1] 运营商重新分配 IP → 变为 203.0.113.99
     │
     └─ 同样会触发 DPD 超时 → 隧道断开（这一步和 PSK 一样）

[T2] Customer Gateway 用新 IP 重新发起连接
     │
     ├─ PSK 模式： 用源 IP 查找 CGW → 找不到 → 拒绝 ❌
     │
     └─ 证书模式：不查 IP，等对方出示证书
          → 收到证书 CN=vpn-client.internal
          → 验证证书链 ✅ → 验证签名 ✅
          → 认证通过，隧道重新建立 ✅

[T3] 隧道自动恢复，业务短暂中断后恢复（通常 30~60 秒）

关键区别：隧道断开后，证书认证可以自动恢复（因为新 IP 发来的连接请求不会被拒绝），而 PSK 认证需要人工到亚马逊云科技 Console 更新 Customer Gateway IP 并重新配置 VPN Connection，无法自动恢复。

注意：证书认证并不意味着”任何人拿到一张证书就能连上你的 VPN”。亚马逊云科技侧配置了只信任特定 Private CA 签发的证书，所以只有你自己签发的证书才能通过验证。这等同于 PSK 模式下”只有知道密钥的人才能连接”的安全保证。

1.3 亚马逊云科技侧解决方案

亚马逊云科技 Site-to-Site VPN 支持两种隧道认证方式：

认证方式	Customer Gateway IP	身份验证
Pre-Shared Key（PSK）	必填	通过 IP + PSK 验证
Private CA 证书	可选（可留空）	通过证书验证

参考：Site-to-Site VPN tunnel authentication options、Customer gateway options

使用证书认证时，亚马逊云科技文档明确指出：

“If you do not specify the IP address of your customer gateway device, we do not check the IP address. This operation allows you to move the customer gateway device to a different IP address without having to re-configure the VPN connection.”

这意味着：只要对端持有由同一 Private CA 签发的有效证书，无论其 IP 如何变化，亚马逊云科技都能完成身份验证并建立隧道。

二、方案架构

2.1 整体架构

如图所示，方案采用两条 VPN 连接并行的架构：

上方链路（Private certificate）：办公地点通过卫星互联网线路接入，使用亚马逊云科技 Private CA 证书认证。Customer Gateway 不指定 IP 地址，通过证书验证身份。VPN Connection 关联到 Transit Gateway，每条连接自带两条隧道（Tunnel 1 / Tunnel 2）实现内置冗余。
下方链路（Public IP）：办公地点通过当地运营商的固定 IP 线路接入，使用传统的 PSK 认证。Customer Gateway 指定固定公网 IP。

两条 VPN Connection 通过各自的 VPN Attachment 汇聚到同一个 Transit Gateway，TGW 通过 VPC Attachment 连接业务 VPC。当任意一条链路故障时，TGW 自动将流量切换到另一条链路。

2.2 关键组件

组件	作用
Private CA	签发 VPN 认证证书
Customer Gateway（Private certificate）	代表卫星线路侧设备，不绑定 IP，通过证书认证
Customer Gateway（Public IP）	代表固定 IP 线路侧设备，绑定固定公网 IP
VPN Connection（Private certificate）	证书认证的 IPsec IKEv2 隧道，每条含 2 个 Tunnel
VPN Connection（Public IP）	PSK 认证的 IPsec 隧道，每条含 2 个 Tunnel
Transit Gateway	汇聚多条 VPN 连接和 VPC Attachment
VPC	承载业务系统

三、部署与动手实验

本章以一个完整的动手实验为主线，让读者仅用一个亚马逊云科技账号即可复现证书认证 VPN 的全流程。我们使用首尔（ap-northeast-2）模拟云端，东京（ap-northeast-1）模拟办公地点，通过两个 Region 的资源还原真实的混合云组网场景。每个步骤同时标注了生产环境的差异，方便读者在真实场景中参考。

3.1 实验架构与角色映射

实验资源	Region	模拟的真实角色
VPC（172.31.0.0/16）+ EC2-Server	首尔 ap-northeast-2	云端业务 VPC + 业务服务器
Transit Gateway	首尔 ap-northeast-2	云端 TGW
Private CA + 证书	首尔 ap-northeast-2	Private CA
Customer Gateway（证书认证，IP 留空）	首尔 ap-northeast-2	卫星线路侧 CGW
VPN Connection（证书认证）	首尔 ap-northeast-2	卫星线路的 VPN
VPC（10.0.0.0/16）+ EC2-Client（Ubuntu + StrongSwan）	东京 ap-northeast-1	办公地点内网 + 防火墙

生产环境差异：生产环境中，东京侧的 EC2 + StrongSwan 替换为真实的防火墙设备（如 Sophos、FortiGate 等），证书导入和 IPsec 配置在防火墙管理界面完成。亚马逊云科技侧的操作完全一致。本实验仅验证证书认证链路。PSK 认证链路的配置方式可参考亚马逊云科技官方文档。

3.2 Step 1：创建云端基础设施（首尔 Region）

3.2.1 在 ap-northeast-2（首尔）创建

1. VPC：seoul-vpc，CIDR 172.31.0.0/16，含公有子网、IGW、路由表

2. EC2-Server：Amazon Linux 2023，t3.micro，安全组允许 10.0.0.0/16 的 ICMP 和全部流量

3. Transit Gateway：seoul-tgw，关联 seoul-vpc

3.3 Step 2：创建 Private CA 和证书（首尔 Region）

⚠️ 费用提醒：亚马逊云科技 Private CA（General-purpose 模式）按月计费 $400/月，按天折算约 $13/天。测试完立即删除，删除时务必选择永久删除。详见亚马逊云科技 Private CA Pricing。

CA 层级结构参考：Design a CA hierarchy

上图为三层 CA 层级结构。本方案仅使用两层结构（Root CA → Subordinate CA），由 Subordinate CA 直接签发 VPN 客户端证书，满足验证场景的需求即可。

3.3.1 创建根 CA

亚马逊云科技 Private CA 控制台 → Create a private CA → General-purpose 模式 → Root CA → 安装自签名证书（建议有效期 10 年）。

3.3.2 创建从属 CA

创建 Subordinate CA，由根 CA 签发证书（建议有效期 5 年）。

⚠️ 提醒：从属 CA 的有效期不要设太短。ACM 签发证书的默认有效期为 13 个月（395 天），如果从属 CA 剩余有效期不足 395 天，签发会失败，报错”CA 的签名证书已过期”。

3.3.3 签发客户端证书

ACM → Request a private certificate → 选择从属 CA → 填写域名（如 vpn-client.internal）。

3.3.4 导出证书

导出三个文件：client-cert.pem（客户端证书）、client-key.pem（私钥）、ca-chain.pem（CA 证书链）。

3.4 Step 3：创建证书认证的 Customer Gateway 和 VPN Connection（首尔 Region）

此步骤创建——卫星互联网线路使用的证书认证 VPN。

3.4.1 创建 Customer Gateway（证书认证）— IP 留空，证书选择上一步签发的客户端证书

3.4.2 创建 VPN Connection（证书认证）

Name：vpn-certificate
Target gateway type：Transit Gateway → seoul-tgw
Customer gateway：选择 cgw-certificate
Local IPv4 network CIDR：10.0.0.0/16 ⚠️ 提醒：客户网关（本地部署）端 IPv4 CIDR 范围
Remote IPv4 network CIDR：172.31.0.0/16 ⚠️ 提醒：亚马逊云端 IPv4 CIDR 范围

创建完成后，在 Tunnel details 中记录 Tunnel 1 和 Tunnel2 的 Outside IP address。

ℹ️ 注意：

虽然 CGW 使用证书创建，亚马逊云科技仍会在下载的配置文件中显示 PSK。这是因为亚马逊云科技为每条隧道都会生成 PSK 作为备用，但实际认证走的是证书。

3.4.3 配置路由

TGW 路由表：创建静态路由 10.0.0.0/16，指向证书认证 VPN 的 Attachment
VPC 路由表：10.0.0.0/16 → TGW

3.5 Step 4：创建办公地点模拟环境（东京 Region）

生产环境差异：此步骤在生产环境中不需要。办公地点使用真实的防火墙设备。

3.5.1 在 ap-northeast-1（东京）创建

VPC：tokyo-vpc，CIDR 10.0.0.0/16，含公有子网、IGW、路由表

3.5.2 EC2-Client-Cert（模拟办公地点防火墙）

Ubuntu 24.04 LTS
t3.micro
分配 EIP，禁用源/目标检查
安全组放行 UDP 500/4500（IKE/NAT-T）和 SSH

⚠️ 为什么用 Ubuntu？ StrongSwan 对 IKEv2 证书认证的支持更成熟，而 Ubuntu 的 apt 源中有 StrongSwan 包。

3.6 Step 5：配置办公地点侧 VPN

生产环境差异：生产环境中，此步骤替换为在防火墙管理界面导入证书并配置 IKEv2 证书认证的 IPsec VPN。关键配置项相同：IKEv2、证书认证、由本端发起连接。

以下为实验环境中使用 StrongSwan 的配置步骤。

SSH 到 EC2-Client-Cert：

3.6.1 安装 StrongSwan

sudo apt-get update
sudo apt-get install -y strongswan strongswan-pki strongswan-starter libcharon-extra-plugins

3.6.2 配置内核参数

cat << 'EOF' | sudo tee /etc/sysctl.d/vpn.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
EOF
sudo sysctl -p /etc/sysctl.d/vpn.conf

3.6.3 部署证书

# 部署客户端证书和私钥，Step2中创建并导出的证书
sudo cp client-cert.pem /etc/ipsec.d/certs/
sudo cp client-key.pem /etc/ipsec.d/private/
sudo chmod 600 /etc/ipsec.d/private/client-key.pem

# ⚠️ 解密私钥（ACM 导出的私钥是加密的，StrongSwan 无法直接读取）
sudo openssl rsa \
  -in /etc/ipsec.d/private/client-key.pem \
  -out /etc/ipsec.d/private/client-key-dec.pem \
  -passin pass:<导出证书时设置的密码>
sudo mv /etc/ipsec.d/private/client-key-dec.pem /etc/ipsec.d/private/client-key.pem
sudo chmod 600 /etc/ipsec.d/private/client-key.pem

# 部署 CA 证书链（⚠️ 必须拆分！）
sudo cp ca-chain.pem /etc/ipsec.d/cacerts/
cd /etc/ipsec.d/cacerts/
sudo csplit -f ca- -b '%02d.pem' ca-chain.pem '/-----BEGIN CERTIFICATE-----/' '{*}'
sudo find . -name 'ca-*.pem' -empty -delete

# 验证拆分结果
for f in /etc/ipsec.d/cacerts/ca-*.pem; do
  echo "=== $f ==="
  openssl x509 -in "$f" -subject -issuer -noout 2>/dev/null
done

⚠️ 提醒：ACM 导出证书时强制要求设置 passphrase，导出的私钥为 ENCRYPTED PRIVATE KEY 格式。StrongSwan 默认无法读取加密私钥，会报 no private key found 错误。必须先用 openssl rsa 解密为明文私钥。

3.6.4 配置 IPsec

将 <TUNNEL1_OUTSIDE_IP> 和 <TUNNEL2_OUTSIDE_IP> 替换为 Step 3 记录的 Tunnel 1 和 Tunnel 2 的 Outside IP。将 <ROOT_CA_DN> 替换为根 CA 的完整 Subject DN（如 C=CN, O=xy, OU=Test, CN=VPN Test Root CA）。

sudo tee /etc/ipsec.conf << 'EOF'
config setup
    charondebug="ike 2, knl 2, cfg 2"
conn tunnel1
    auto=start
    type=tunnel
    authby=rsasig
    keyexchange=ikev2
    ike=aes256-sha256-modp2048
    esp=aes256-sha256-modp2048
    leftcert=client-cert.pem
    leftid="CN=vpn-client.internal"
    leftsubnet=10.0.0.0/16
    right=<TUNNEL1_OUTSIDE_IP>
    rightsubnet=172.31.0.0/16
    rightid=%any
    rightca="<ROOT_CA_DN>"
    reqid=10
    mark=10
    ikelifetime=8h
    lifetime=1h
    dpddelay=10s
    dpdtimeout=30s
    dpdaction=restart
    closeaction=restart
conn tunnel2
    auto=start
    type=tunnel
    authby=rsasig
    keyexchange=ikev2
    ike=aes256-sha256-modp2048
    esp=aes256-sha256-modp2048
    leftcert=client-cert.pem
    leftid="CN=vpn-client.internal"
    leftsubnet=10.0.0.0/16
    right=<TUNNEL2_OUTSIDE_IP>
    rightsubnet=172.31.0.0/16
    rightid=%any
    rightca="<ROOT_CA_DN>"
    reqid=20
    mark=20
    ikelifetime=8h
    lifetime=1h
    dpddelay=10s
    dpdtimeout=30s
    dpdaction=restart
    closeaction=restart
EOF

3.6.5 配置密钥引用

sudo tee /etc/ipsec.secrets << 'EOF'
: RSA client-key.pem
EOF
sudo chmod 600 /etc/ipsec.secrets

3.6.6 启动 StrongSwan

sudo systemctl restart strongswan-starter
sleep 15
sudo ipsec statusall

正常输出应包含：

tunnel1[x]: ESTABLISHED ...
tunnel1{x}: INSTALLED, TUNNEL
    10.0.0.0/16 === 172.31.0.0/16
tunnel2[x]: ESTABLISHED ...
tunnel2{x}: INSTALLED, TUNNEL
    10.0.0.0/16 === 172.31.0.0/16

在控制台查看VPN的隧道详情

3.7 Step 6：配置回程路由（东京 Region）

生产环境差异：生产环境中，回程路由在防火墙上配置（静态路由指向 VPN 隧道接口），不需要在 VPC 路由表中添加。

在东京 VPC 路由表中添加：

Destination	Target
`172.31.0.0/16`	EC2-Client 实例 ID

收紧安全组：EC2-Client 的 UDP 500/4500 Source 从 0.0.0.0/0 改为 <Tunnel1 Outside IP>/32 和 <Tunnel2 Outside IP>/32。

3.8 Step 7：验证

3.8.1 Ping 测试

# 从 EC2-Client-Cert ping 首尔 EC2-Server
ping -c 4 <首尔EC2私网IP>

# 更改 EC2-Client-Cert 的公网ip，ping 首尔 EC2-Server

ping -c 4 <首尔EC2私网IP>

# 停掉EC2-Client-Cert实例，启动一个新的实例并进行配置后，ping 首尔 EC2-Server
ping -c 4 <首尔EC2私网IP>

四、总结

亚马逊云科技 Private CA 证书认证为动态 IP 环境下的 Site-to-Site VPN 提供了一种无需额外设备、完全托管的解决方案。其核心优势是：

Customer Gateway 不需要固定 IP — 通过证书验证身份，适配动态 IP 环境
防火墙原生支持 — 主流企业级防火墙（FortiGate、Sophos、Palo Alto 等）都支持 IKEv2 证书认证，不需要额外设备
亚马逊云科技完全托管 — 不需要维护 EC2 或自建 VPN 服务

此方案适用于卫星互联网等无法获得固定公网 IP 的网络环境。

➡️ 下一步行动：

相关产品：

Amazon EC2 — 安全且可调整大小的计算容量
Amazon VPC — 隔离云网络
Amazon Connect — AI 客户体验解决方案

相关文章：

五、参考资料

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客