桥接接口已启动并包含两个子接口：
@H_404_4@# brctl show bridge name bridge id STP enabled interfaces br0 8000.0e7c15e787b0 no eth0 tap0VPN服务器上的路由显然是正常的;我可以通过SSH,ping,响应来自客户端的VPN请求：
@H_404_4@# 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和Windows中ping Mac客户端到VPN服务器的IP但不到VPC子网上的任何其他IP. (那些其他IP都可以;它们可以从VPN服务器ping通.)
当我在VPN服务器上的桥接接口br0上tcpdump时,它会看到来自Windows客户端的“ARP who-has”请求.但是他们没有进入VPC子网！目标IP上的tcpdump没有看到ARP到达. Windows arp缓存仍未填充. (10.0.0.128是Windows客户端; 10.0.0.58是VPN服务器; 10.0.0.180是子网上的其他IP;下面的输出来自VPN服务器.)
@H_404_4@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服务器的唯一网络接口上检查EC2控制台.
我按照桥接HOWTO中的建议设置了IP表,并且通常完全遵循这些说明.
@H_404_4@# 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 anywherehttps://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html
我认为我不需要转储完整的配置,因为显然有很多工作：身份验证,证书,压缩,地址池,连接设置.亚马逊VPC是否只是拒绝转发数据包,我真的应该在虚拟化程度较低的云上执行此操作吗？
更多实验下一天：
VPC显然不像真正的第2层子网.特别是,有广播的ARP实际上并没有播出！当我从.180 ping不存在的IP(比如.5)时,.58看不到请求.如果通过管理控制台/ API在VPC中配置了.5,则VPC显然正在优化ARP广播并仅将其发送到.5.保留tcpdump -vv -i eth0 arp一段时间仅显示主机和网关之间的流量,适用于所有主机.
此外,ping子网上的广播地址根本不起作用.这由Amazon VPN FAQ支持.
因此,VPC很可能拒绝识别.129的未知MAC地址,因为它不存在于自己的“虚拟以太网交换机”中.我可能会在一周左右的时间内将其作为答案.要使用您自己的VPN扩展VPC,必须通过正式的“VPC网关”,该网关仅用作由专用硬件路由器和静态IP支持的企业内部网的扩展,而不是漫游笔记本电脑的情况.瞄准.
解决方法
然后,在VPC路由表中为VPN客户端子网添加静态路由,并将该路由的目标指定为vpn服务器实例的实例ID.
VPC网络是一个虚拟的软件定义网络.它不是一个纯粹的第2层网络,但在大多数情况下,它很好地模拟了一个.但是,广播不是这些方式之一.
如果您注意到,从一个实例到另一个实例的ARP流量没有1：1的相关性.您获得ARP响应的响应不是来自分配了IP的实例.它来自网络.如果目标实例实际上看到了传入的请求,那么它实际上并没有看到您发送的请求.
VPC是以这种方式设计的,它们具有一些非常令人信服的理由,可扩展性和安全性.
事实上,VPC超网范围内的IP地址只是在实例上,这是一个副作用.即使您使用可用的硬件VPN解决方案,您仍然无法在该链接的另一侧的VPC超网内拥有私人地址…所以这不是一个限制,以使您支付额外的东西……它只是设计的一部分.
推荐观看：VPC /十亿包生命中的一天(CPN401)
