CloudFront + WAF实现IPv6访问:无需改造后端基础设施的优雅方案
CloudFront + WAF实现IPv6访问:无需改造后端基础设施的优雅方案

CloudFront + WAF实现IPv6访问:无需改造后端基础设施的优雅方案

内容目录

CloudFront + WAF实现IPv6访问:无需改造后端基础设施的优雅方案

前言

最近接到一个需求,说是要支持IPv6访问我们的Web应用。一听到IPv6,脑子里第一反应就是:完了,这下要大改了吧?VPC要加IPv6 CIDR、Subnet要改、ALB要改成Dualstack、Security Group也要加规则……感觉工数至少得好几周。

但实际调查下来发现,如果你的架构里已经用了CloudFront,那事情就简单多了!今天就来分享一下这次的实战经验。

背景

系统架构(简化版)

我们的系统大概是这样的:

用户(浏览器)
↓
域名(例如 app.example.com)
↓
CloudFront
↓
ALB(Application Load Balancer)
↓
EC2 / ECS(应用服务器)

所有的Web访问都要先经过CloudFront,然后再到后端的ALB。ALB和后端的EC2都是IPv4 only的配置。

需求

客户要求支持IPv6访问。具体来说,就是要能从IPv6网络环境访问我们的Web应用。

初步担心

一开始真的很担心,因为按照常规思路,要支持IPv6的话:

  1. VPC层面:给VPC和Subnet添加IPv6 CIDR
  2. ALB层面:把ALB的IP address type改成Dualstack(IPv4 + IPv6)
  3. Security Group:添加IPv6的Ingress/Egress规则
  4. Route Table:添加IPv6的路由
  5. 应用层:确认应用是否支持IPv6(一般问题不大)

这一套下来,工数少说也得1-2周,而且影响范围很大,风险也不小。

解决方案:CloudFront救场

CloudFront的IPv6支持

后来查了一下AWS的文档,发现CloudFront本身就支持IPv6!而且重点是:

CloudFront可以接收IPv6客户端的请求,然后用IPv4连接到Origin(后端服务器)

这意味着什么呢?

IPv6客户端 (2001:xxxx:xxxx::1)
↓ [IPv6请求]
CloudFront (启用IPv6) ← 在这里做协议转换!
↓ [IPv4请求]
ALB (IPv4 only) ← 后端完全不用改!
↓
EC2 / ECS (IPv4)

后端系统完全不需要改动! 这简直是天大的好消息啊!

实施步骤

整个实施过程出奇地简单:

Step 1: 启用CloudFront的IPv6

  1. 进入CloudFront控制台
  2. 选择你的Distribution
  3. 点击"编辑"
  4. 找到IPv6选项
  5. 选择"オン"(On)
  6. 保存

就这么简单!CloudFront会自动部署到全球的边缘节点,通常5-15分钟就完成了。

Step 2: DNS设置(如果需要)

这一步取决于你的DNS配置方式:

如果用CNAME指向CloudFront

  • 不需要做任何事情!
  • DNS会自动返回CloudFront的IPv6地址(AAAA记录)

如果用Route 53的Alias Record

  • 需要添加一个AAAA记录
  • 记录类型选择:AAAA
  • Alias:是
  • 指向:你的CloudFront Distribution

Step 3: WAF IPv6白名单(如果有IP限制)

如果你的WAF配置了IP白名单,需要添加IPv6地址:

  1. 创建IPv6 IPSet

    • AWS WAF控制台
    • IP Sets → Create IP set
    • IP address version: IPv6
    • 添加IPv6地址,例如:2001:db8::/32
  2. 注意:AWS WAF的IPSet不能同时包含IPv4和IPv6地址,必须分开创建

  3. 添加WAF规则

    • 在Web ACL里添加新规则
    • 条件:源IP匹配IPv6 IPSet
    • 动作:Allow

验证方法

1. 验证DNS解析

# 查询IPv6地址(AAAA记录)
nslookup -type=AAAA app.example.com

# 或者用dig
dig AAAA app.example.com

如果返回了2600:9000:xxxx开头的地址,说明CloudFront的IPv6已经生效了。

2. 测试IPv6连接

# 强制使用IPv6访问
curl -6 -v https://app.example.com

# 查看连接详情
# 应该能看到 "Trying [2600:9000:xxxx::x]:443..."

3. 查看你的IPv6地址

# 测试你的网络有没有IPv6
curl -6 https://ipv6.google.com

# 如果成功,说明你的网络支持IPv6

注意:如果你在公司网络,很多企业内网只支持IPv4,可能测试不了。建议用手机热点或者家里的网络测试(一般都支持IPv6)。

4. IPv6 CIDR的填写

如果要在WAF添加IPv6白名单,CIDR的选择:

  • /128:只允许单个IP(最严格)
  • /64:允许一个子网(家庭/办公室网络常用)
  • /48:允许更大的范围

例如你的IPv6地址是2001:db8:1234:5678::1`:

2001:db8:1234:5678::1/128  ← 只允许这一个IP
2001:db8:1234:5678::/64    ← 允许整个子网
2001:db8:1234::/48         ← 允许更大范围

实战测试记录

测试环境搭建
我在dev环境做了完整测试:

✅ CloudFront启用IPv6

✅ WAF添加IPv6 IPSet(加了我自己的IPv6地址段)

✅ 等待部署完成(大约10分钟)

第一次测试:403 Forbidden

$ curl -6 -v https://dev-app.example.com
...
< HTTP/1.1 403 Forbidden
< Server: CloudFront
...
Request blocked.

原因:IPv6地址还没加到WAF白名单里,被拦截了。这说明WAF工作正常!

第二次测试:成功!
添加IPv6白名单后再测试:

$ curl -6 -v https://dev-app.example.com
...
* Established connection to dev-app.example.com 
  (2600:9000:xxxxxxxxxxx1 port 443) 
  from 2600:9000:xxxxxxxxxx port 12560
...
< HTTP/1.1 302 Found
...

成功了! 🎉

✅ IPv6连接建立成功

✅ 应用正常响应(302跳转到登录页)

✅ 后端ALB完全不知道客户端是IPv6(CloudFront用IPv4连接ALB)

方案A:CloudFront IPv6(本方案)

项目 内容
工作量 1-2人日
停机时间
影响范围 CloudFront + WAF设置
风险
后端改动 无需改动

方案B:全栈IPv6改造

项目 内容
工作量 10-15人日
停机时间 可能需要短时停机
影响范围 VPC、Subnet、ALB、SG、Route Table
风险 中~高
后端改动 需要大规模改造

结论:如果已经用了CloudFront,选择方案A事半功倍

注意事项和坑点

1. DNS传播需要时间

CloudFront部署完成后,DNS更新还需要一点时间(通常2-5分钟)。如果测试失败,先等等,不要急。

2. WAF的IPSet限制

  • IPv4和IPv6不能放在同一个IPSet里
  • 需要分别创建IPv4 IPSet和IPv6 IPSet
  • 规则也要分别添加

3. 测试环境的IPv6支持

很多公司内网不支持IPv6,可能测不了。建议:

  • 用手机热点(日本三大运营商都支持IPv6)
  • 在家测试
  • 找支持IPv6的云服务器测试

4. Origin Protocol Policy

确认CloudFront的Origin设置:

  • Origin Protocol Policy:建议用HTTPS OnlyMatch Viewer
  • Origin IP address type:保持IPv4 only(不要改!)

改成Dualstack的话,CloudFront会尝试用IPv6连接你的ALB,但你的ALB只支持IPv4,会失败。

5. CloudFront的IPv6是默认全球生效的

CloudFront启用IPv6后,是在全球所有边缘节点生效的,不能只在某些地区启用。

适用场景

✅ 适合用CloudFront方案的场景

  • 已经在用CloudFront做CDN
  • 后端是IPv4 only的架构
  • 希望快速支持IPv6
  • 不想大改基础设施

❌ 不适合的场景

  • 需要直接访问后端服务器(不经过CloudFront)
  • 需要保留客户端真实IPv6地址做业务逻辑
  • 对CloudFront的延迟非常敏感的应用

费用影响

CloudFront启用IPv6不会额外收费

  • IPv6请求和IPv4请求的定价一样
  • 只按照正常的CloudFront流量计费

总结

这次IPv6对应的经验让我深刻体会到:架构设计时考虑CDN/代理层的重要性

CloudFront不仅仅是个CDN,它还可以:

  • 作为协议转换层(IPv6 ↔ IPv4)
  • 提供全球加速
  • 集成WAF做安全防护
  • 减轻Origin的负载

如果你的系统还没用CloudFront,不妨考虑一下。即使现在不需要IPv6,将来也可能会需要。提前做好架构规划,可以省很多麻烦。

参考资料

后记

这次从担心要大改架构,到发现可以用CloudFront轻松搞定,真的是柳暗花明又一村的感觉😄

如果你也遇到类似的IPv6需求,希望这篇文章能帮到你!

有问题欢迎在评论区留言~

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注