我在 Amazon EC2 VPC 中的 Linux 服务器上设置了桥接 OpenVPN。（花了几个小时阅读文档，阅读类似的问题，这里，openVPN 论坛，但还没有运气。）
桥接接口已启动并包含两个子接口：
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0e7c15e787b0 no eth0
tap0
VPN 服务器上的路由显然没有问题；我可以通过 SSH 进入，执行 ping 操作，响应来自客户端的 VPN 请求：
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 br0
10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0
我能从 Windows 和 Mac 客户端 ping 通 VPN 服务器的 IP，但不能 ping 通 VPC 子网上的任何其他 IP。（其他 IP 没问题；可以从 VPN 服务器 ping 通它们。）
当我在 VPN 服务器上的tcpdump桥接接口上时br0看到来自 Windows 客户端的“ARP who-has”请求。但是它们不会进入 VPC 子网！tcpdump目标 IP 上的 ARP 未到达。Windows arp 缓存仍未填满。（10.0.0.128 是 Windows 客户端；10.0.0.58 是 VPN 服务器；10.0.0.180 是子网上的另一个 IP；下面的输出来自 VPN 服务器。）
root@vpn:# tcpdump -i br0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:00:21.092367 ARP, Request who-has 10.0.0.180 tell 10.0.0.128, length 28
[蟋蟀]
我已在 VPN 服务器的唯一网络接口上的 EC2 控制台中禁用源/目标检查。
我已经按照桥接 HOWTO 中的建议设置了 IP 表，并且通常严格遵循这些说明。
# iptables -L INPUT -v
Chain INPUT (policy ACCEPT 9 packets, 1008 bytes)
pkts bytes target prot opt in out source destination
38 12464 ACCEPT all -- tap0 any anywhere anywhere
10447 1297K ACCEPT all -- br0 any anywhere anywhere
# iptables -L FORWARD -v
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
918 167K ACCEPT all -- br0 any anywhere anywhere
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html
我不思考我需要转储完整配置，因为显然很多配置都在运行：身份验证、证书、压缩、地址池、连接设置等。Amazon VPC 是否只是拒绝转发数据包，而我真的应该在虚拟程度较低的云上执行此操作？
第二天进行更多实验：VPC 显然不像真正的第 2 层子网。特别是，ARPwho-has广播实际上不会广播！当我从 .180 ping 不存在的 IP（例如 .5）时，.58 看不到该请求。VPC 显然正在优化 ARP 广播并将其仅发送到 .5，如果已通过管理控制台/API 在 VPC 中配置了 .5。保持tcpdump -vv -i eth0 arp打开状态一段时间仅显示所有主机的主机和网关之间的流量。
此外，对子网上的广播地址进行 ping 操作根本不起作用。Amazon VPN FAQ 对此进行了支持。
因此，VPC 很可能拒绝识别未知的 MAC 地址 .129，因为它不存在于自己的“虚拟以太网交换机”中。我可能会在一周左右的时间内将此作为答案。要使用您自己的 VPN 扩展 VPC，必须通过正式的“VPC 网关”，该网关仅设计为由专用硬件路由器和静态 IP 支持的公司内联网的扩展，而不是我所针对的漫游笔记本电脑场景。
答案1
您的 VPN 需要路由，而不是桥接，并且您的 VPN 客户端所在的子网必须位于 VPC 超网的边界之外。
然后，在 VPC 路由表中为 VPN 客户端子网添加静态路由，并将该路由的目的地指定为您的 VPN 服务器实例的实例 ID。
VPC 网络是一种虚拟的软件定义网络。它不是纯粹的第 2 层网络，但在大多数方面，它都能很好地模拟第 2 层网络。但广播不是其中之一。
如果您注意到，从一个实例到另一个实例的 ARP 流量并不是 1:1 的关联。您收到的 ARP 响应who-has并非来自分配了 IP 的实例。它来自网络。如果目标实例实际上看到了传入的请求，那么它实际上并没有看到您发送的请求。
VPC 这样设计是出于一些非常令人信服的原因，其中包括可扩展性和安全性。
事实上，VPC 超网范围内的 IP 地址只能用于实例，这是此做法的一个副作用。即使您使用可用的硬件 VPN 解决方案，您仍然无法在该链接另一侧的 VPC 超网内拥有私有地址……因此，这不是一个让您额外付费的限制……这只是设计的一部分。
推荐观看：VPC/十亿个数据包的一天 (CPN401)