在新建的 AWS VPC（使用 Terraform 部署以尽量减少拼写错误）中，我有一个“DMZ”子网和一个内部子网。防火墙设备将两者连接起来，每个子网都有一个接口。两个接口都有 IPv4 和 IPv6 地址。IPv6 地址一个是本地链路地址，一个是全局地址。防火墙可以通过 IPv4 和 IPv6 访问 HTTPS URL，流量从 DMZ 接口路由出去。在内部区域中构建的测试服务器在内部子网中有一个接口，并且具有适当的 IPv4 和 IPv6 地址（一个是本地链路地址，一个是全局地址）。对于 IPv4 和 IPv6 路由表，服务器上的默认路由是防火墙内部接口的全局地址。
防火墙上的接口已禁用源/目标检查。安全组和网络 ACL 的设置使得内部服务器必须通过防火墙路由出站 Web 连接 - NACL 不允许内部子网上的任何入站或出站数据包（因此双宿主防火墙是唯一可以离开的防火墙）。DMZ NACL 允许出站 HTTPS 到所有目标（IPv4 和 IPv6），以及来自所有目标的高端口响应。防火墙对来自内部的出站 IPv4 连接进行 NAT，并且运行正常；服务器可以通过 IPv6 访问 HTTPS URL。但是，服务器无法访问 IPv6 地址。连接失败。
- 防火墙本身可以使用相同的 URL 成功建立出站 IPv6 连接，因此远程 URL 必须正常工作
- 服务器成功将 URL 解析为 IPv6 IP，就像防火墙所做的那样
- 防火墙 DMZ 接口上的 tcpdump 显示离开设备的数据包的源 IP 是服务器的全局 IPv6 IP，目标 IP 是远程 URL，因此数据包被成功路由到/通过防火墙
- 相同的转储显示没有来自远程 URL 的响应数据包，因此假设数据包到达远程 URL（因为防火墙发送数据包时它们确实到达了远程 URL），防火墙没有收到响应数据包
- 该设备不会尝试执行任何操作，例如 IPv6 上的 NAT 或隧道，它只是路由和转发（和防火墙）
- 该设备会记录防火墙的所有连接，因此我知道它没有阻止此连接
- AWS Reachability Analyzer 不适用于 IPv6，因此我无法使用它来查找问题
- DMZ 子网的路由表将防火墙的 DMZ 接口列为内部（和 DMZ）IP 的下一跳
- 防火墙是一个 Linux 实例，已启用 IPv6 数据包转发（否则数据包将无法到达 DMZ 接口）
我想知道安全组规则的状态性质是否是问题的核心；尽管防火墙有一个入站安全组规则，允许来自任何地方的所有协议和端口，但由于防火墙发出了一个不是源 IP 的数据包，AWS 路由系统是否会将响应数据包返回到防火墙？它应该会，因为这是 VPC 子网路由表中针对该目标的规定路由。无论如何，禁用源/目标检查不应该覆盖该领域的任何问题吗？
编辑：目标是以比 AWS 收取的每个可用区每月 40 美元左右的价格更便宜的价格部署 VPC NAT 网关；假设两个可用区和两个区域可用，则每月 160 美元，这将使我的 AWS 支出增加 100%。该设计是数十年来全球公司使用的标准内部/DMZ/外部设计，并且VPC最佳实践; 我认为安全组类似于主机防火墙；有安全组是好事（在安全组的情况下，它具有一些集中式 API 控制的优势），但仅靠安全组是不够的；在非虚拟化环境中，您不会为 Windows 服务器提供外部 IP，并希望 Windows 防火墙永远不会配置错误，如果您非常重视基础设施安全，您会在它前面放置一个单独的防火墙。因此，假设我想要对主机防火墙（未指定操作系统）进行集中式声明式“控制”，即通过 Terraform 的安全组，我需要在它前面放置其他东西。NACL 的大小太有限，因此 NAT 网关是自然的选择。它还提供了一个出口点，我可以在那里检查流量是否有内部妥协的迹象。
我注意到这个文件AWS 声明他们的 NAT 实例执行 NAT64，这更加深了我的怀疑，即 IPv6 路由在 VPC 中不起作用存在某种结构性原因。
编辑2：VPC 流日志显示出站数据包流已被接受，并且没有相应的回复流，这意味着（我认为）数据包没有被路由到 fw 接口。
答案1
答案是 Edge 关联。我尝试执行这个文件作为中间件路由；而当我读到它时，我却没有意识到的一句话是：
将此路由表与您的互联网网关关联
由于文档中没有边缘关联，我误解了它的含义，并配置了子网路由表而不是 igw 路由表（它根本没有路由表，所以我猜想它使用了某个默认路由表 - 可能是主路由表？）。因此，回复数据包不会被路由到防火墙。现在它可以顺利地路由 IPv6。
我之前从未使用过 Edge 关联，因此我并没有意识到这一点。