我遇到了路由问题。
我有 2 个公共子网：172.31.1.0/24 和 172.31.100.0/24
在每个实例中我都有一个 NAT 实例。每个 NAT 实例都是一个到远程位置的 OpenSwan VPN 对等体。这允许以下 VPN 连接：
172.31.1.0/24 -> 192.168.1.0/24
172.31.100.0/24 -> 192.168.100.0/24
我设置了一个与我的两个公共子网关联的单个路由表。其中包括如下路由条目：
192.168.1.0/24 Target = NAT instance 1
192.168.100.0/24 Target = NAT instance 2
前者一切正常，但无论我做什么，后者的路由表条目都不起作用。
我为 NAT 实例 2 设置的路由均不起作用。当我跟踪路由到 192.168.100.0/24 中的任何地址时，数据包会直接发送到 192.168.100.0/24（因此失败），而不是通过 NAT 实例 2 进行路由。
我认为路由表中的并发 NAT 实例数量可能存在限制，但是即使我删除到 192.168.1.0 的路由，以便唯一存在的路由是通过 NAT 实例 2 的路由，它仍然不起作用。
我检查了所有常规内容（源/目标检查等），但似乎没有什么不对劲。所有这些都是用 CloudFormation 创建的，因此不太可能出现手动错误。
答案1
这个问题的解决方案非常简单，但它提出了一个有趣的观察，即使用 traceroute 来调试路由问题。
问题的根源在于我没有在 Nat Instance 1 之外的任何主机上启用 IP 转发。
IE
echo 1 > /proc/sys/net/ipv4/ip_forward
当我进行调试时，我一直在使用 traceroute 命令，例如
traceroute 192.168.100.1
当 Nat 实例 2 上未启用 IP 转发时，会产生以下响应：
[server1]$ traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets
当我在 Nat 实例 2 上启用 IP 转发时，响应发生了变化：
[server1]$ traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets
1 ip-172-31-100-102.ap-southeast-1.compute.internal (172.31.100.102) 0.528 ms 0.505 ms 0.491 ms
（172.31.100.102 = 自然实例 2）
这表明，虽然 traceroute 可能知道到特定网络的特定路由，但如果该路由的默认网关允许路由，它才会报告遵循该路由的尝试。
如果不是，它将尝试遵循默认路由并仅报告默认路由的成功或失败。我确信这与 traceroute 的设计一致，但可能表明 traceroute 可能不是调试路由问题的最佳工具（它更像是调试网络问题的工具）。