aws vpc 到 vpc 与 openvpn 的连接
Sar*_*009 0 vpn openvpn amazon-vpc vpc-peering
我在us-east-1(VPC1和VPC2) 中有 2 个 VPC ，并且是 VPC 对等连接。我运行 openVPNVPC1以连接到两个 vpc。现在我不得不在ap-southeast-1(VPC3和VPC4) 中制作 2 个新的 VPC，它们都是 VPC 配对的。我按照本教程设置us-east-1和ap-southeast-1（连接VPC1和VPC3）之间的连接。我现在能够连接到在所有情况下VPC1，VPC2和VPC3，但无法连接到VPC4。我只能VPC4从VPC3. 我openvpn在 VPC1(ovpn1和ovpn2) 中有两个实例。ovpn1用于从我的办公室ovpn2连接并连接到openvpn运行的第三个实例VPC3. 我已经验证了VPC4in 的路由表，us-east-1看起来不错。
这里也是我在 .ovpn 实例上的路由表VPC1。
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 * 255.255.240.0 U 0 0 0 eth0
10.2.0.0 169.254.255.2 255.255.0.0 UG 0 0 0 tun0
10.3.0.0 169.254.255.2 255.255.255.0 UG 0 0 0 tun0
169.254.255.2 * 255.255.255.255 UH 0 0 0 tun0
VPC CIDR块如下
VPC1 -> 10.0.0.0/16
VPC2 -> 10.2.0.0/16
VPC3 -> 10.3.0.0/24
VPC4 -> 10.1.0.0/16
我错过了什么连接 VPC4
对等连接不支持跨 VPC 传输路由 IP 流量。
对等连接不会为您提供与 VPN 或您可能熟悉的其他网络到网络互连所期望的相同级别的连接。
考虑文档中的这个例子（为了清晰起见，稍微重新格式化），诚然，它没有准确描述你的情况，但有助于理解手头的更大问题。
您在 VPC A 和 VPC B (
pcx-aaaabbbb) 之间以及 VPC A 和 VPC C (pcx-aaaacccc)之间建立了 VPC 对等连接。VPC B 和 VPC C 之间存在 VPC 对等连接。
您无法通过 VPC A 将数据包直接从 VPC B 路由到 VPC C。
这是 VPC 对等互连设计的一部分——它是一项仅影响两个 VPC 中的实例的功能——它们可以相互访问。VPC 中的其他资源，例如 NAT 和 Internet 网关、VPC 服务端点（用于 S3）、Direct Connect 和硬件 VPN，不会通过对等互连公开。
tl;dr：VPC 对等互连不会在直接对等 VPC 中的 EC2 实例之外启用任何 IP 路由或连接。
所以，以上并不是一个完美的解释，因为在文档示例中，所有三个 VPC 当然都在同一个区域，但类似的原则适用于您的配置。
问题不在于 VPC-1 无法通过通往 VPC-3 的隧道到达 VPC-4（流量可能会到达也可能不会到达），而是 VPC-4 绝对无法发送回复。VPC-4 无法在途中将 VPC-3 传输到 VPC-3 (VPC-1) 外部。
同样，这也是我提出有关 VPC-2 和 VPC-3 之间连接问题的动机。VPC-2 在访问 VPC-3 中的地址的途中无法传输 VPC-1。
发往远程网络的传入流量永远不会到达隧道服务器，因为没有跨 VPC 传输的机制，并且到隧道服务器的流量（尽管可能没有明确记录）仍然是传输的情况。
如果您在 VPC-1 和外部公司数据中心之间有 VPC 硬件 VPN，您会遇到同样的问题。无论任何对等互连如何，该 VPN 连接都不会提供从外部数据中心到 VPC-1 边界之外的任何内容的访问。AWS Direct Connect 也是如此。
仅从 API/控制台接口的角度分析这一点，请考虑如何通过对等连接发送流量：通过使用对等连接 ID 作为目标创建路由表条目，创建将外部 IP 前缀从一个 VPC 发送到另一个 VPC 的路由.
但是当流量到达对等 VPC 时会发生什么？哪个路由表应用于它？
这是一个棘手的问题，因为没有公开的路由表适用于通过 VPC 对等连接传入的流量——可用于传入流量的唯一路由是使实例可访问的隐式本地路由。
发送到实例（或运行在实例上的服务，如 RDS）以外的流量——当它到达对等 VPC 时——无处可去，并被丢弃。
合乎逻辑的解决方法是尝试通过对等连接将流量路由到充当路由器的实例......与将流量路由到 NAT 实例的方式非常相似——通过将路由表中的目的地设置为实例-id 或其关联的弹性网络接口 (ENI)。
在上面提到的文档页面的底部，我们发现对这样的实践的一句话限制：
同理，如果 VPC A 有一个 NAT 设备为 VPC A 中私有子网中的实例提供 Internet 访问权限，则 VPC B 中的实例无法使用 NAT 设备访问 Internet。
对于那些不熟悉典型 VPC 配置的人来说，这可能不太清楚，但这个限制实际上更准确地解释了为什么原始问题中提出的配置不起作用。
您可以通过在子网的路由表中创建路由来将特定的外部前缀（通常为 0.0.0.0/0，但也可以是子集）发送到实例本身或其弹性网络接口，从而将子网配置为使用 NAT 实例，通过身份证。
但是在该区域内，如果您尝试通过路由表将流量路由到对等 VPC 中的实例的 ENI，则会失败：
Error: route table rtb-xxxxxxxx and interface eni-xxxxxxxx belong to different networks
(Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameterValue;
Request ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
因此，直观的解决方法也不可用。
我能找到的唯一三个解决方案是：
更多隧道，例如您已经在 VPC-1 和 VPC-3 之间构建的隧道。您基本上需要在需要交换流量的所有 VPC 之间使用完整的 OpenVPN（或其他隧道解决方案），而不是您已对等连接的 VPC。这是我已经实施的解决方案。在每个可用区中，我都有一个 OpenVPN 服务器，该服务器具有通往国外所有其他可用区的隧道。您不一定需要每个可用区一个——每个 VPC 只需要一个就可以满足要求，但每对可用区之间的隧道将提供弹性，以防止由于丢失一个可用区而导致整个 VPC 被隔离。
来自隧道服务器的源 NAT。 这个太乱了。您在 VPC-1 和 VPC-3 之间有一条隧道，并且 VPC-3 与 VPC-4 对等，因此您可以通过 VPC- 中的 VPC 路由表将流量从 VPC-1 路由到 VPC-1 中的隧道服务器1，然后通过隧道将其发送到 VPC-3，在那里它可以通过
iptables配置假设 VPC-3 中隧道实例的源 IP 地址。VPC-3 中的隧道机器可以在 VPC-4 中访问的任何内容都可以被 VPC-1 中允许访问隧道服务器的任何内容访问。VPC-3 中的服务代理或 NAT 服务器，可从 VPC-1 访问，它们要么执行 TCP 连接的第 4 层转发，要么执行 VPC-1 地址和 VPC-4 地址之间流量的源和目标 NAT，以便 VPC-4 看到流量来自 VPC-3 地址，而 VPC-1 看到流量来自 VPC-3 地址。这与上面的类似，但通过安全组提供更好的访问控制，因为它不是前一个选项所需的全有或全无访问......但仍然是一个混乱的解决方案。
最干净的配置是所有 VPC（或所有可用区，同一 VPC 内的可用区或任何直接对等互连的可用区除外）之间的全网状隧道。