我在Amazon EC2 VPC的Linux服务器上安装了桥接OpenVPN。 （花费在文档上的时间，阅读类似的问题，在这里，OpenVPN论坛，没有运气。）
桥接口已经启动，并且包含两个子接口：
# brctl show bridge name bridge id STP enabled interfaces br0 8000.0e7c15e787b0 no eth0 tap0 VPN服务器上的路由显然是OK的; 我可以通过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，但不能到VPC子网上的任何其他IP。 （其他IP也可以，VPN服务器可以ping通）
当我在VPN服务器上的桥接接口br0上tcpdump时，它看到来自Windows客户端的“ARP who-has”请求。 但是他们不会进入VPC子网！ 目标IP上的tcpdump没有看到ARP到达。 Windows arpcaching仍未填充。 （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
[蟋蟀]
我已经禁用了Source / Dest。 在VPN服务器的唯一networking接口上检查EC2控制台。
我已经按照桥接HOWTO的build议设置了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
我不认为我需要转储完整的configuration，因为显然很多工作：authentication，证书，压缩，地址池，连接设置一般。 亚马逊VPC是否拒绝转发数据包，我真的应该在一个虚拟的云上做这个吗？
更多的实验下一天：VPC显然不像一个真正的第2层子网。 特别是， who-has广播的ARP实际上不广播！ 当我从.180 ping一个不存在的IP（例如.5）时，.58看不到请求。 如果在VPC中通过pipe理控制台/ APIconfiguration了一个.5 ，VPC显然是优化掉ARP广播并只发送给.5。 离开tcpdump -vv -i eth0 arp只会显示所有主机在主机和网关之间的stream量。
而且，ping子网上的广播地址根本不起作用。 这由Amazon VPN FAQ进行备份。
所以VPC可能拒绝识别.129的未知MAC地址，因为它不存在于它自己的“虚拟以太网交换机”中。 我可能会在一周左右的时间里把这个作为答案。 要使用自己的VPN来扩展VPC，必须通过正式的“VPC网关”，该网关只能用作由专用硬件路由器和静态IP支持的企业内部网的扩展，而不是漫游笔记本电脑的场景I'瞄准。
您的VPN需要路由，而不是桥接，您的VPN客户端所在的子网必须超出VPC超网的范围。
然后，为VPC路由表中的VPN客户端子网添加静态路由，并将该路由的目标指定为您的vpn服务器实例的实例ID。
VPCnetworking是一个虚拟的，软件定义的networking。 这不是一个纯粹的第2层networking，但在大多数方面，它很好地模拟了一个。 广播，但是，不是其中之一。
如果您注意到，从一个实例到另一个实例的ARPstream量不存在1：1的相关性。 你得到的ARP响应不是来自分配了IP的实例。 它来自networking。 如果目标实例实际上看到传入请求，那么实际上并没有看到您发送的请求。
VPC是以这种方式devise的，其中有一些非常有吸引力的理由，可扩展性和安全性。
在VPC的超网范围内的IP地址预计只是实例，这只是一个副作用。 即使你使用可用的硬件VPN解决scheme，你仍然不能在该链接的另一端的VPC超网内有私人地址…所以这不是一个限制楔入，使您支付额外的东西…这只是devise的一部分。
推荐阅读：VPC /十亿包数据日（CPN401）