是否允许Amazon VPC A到达VPC B上的新私有子网？ [英] Allowing Amazon VPC A to get to a new private subnet on VPC B?
问题描述
我有一个现有的VPC（ vpcA ），最近设置了一个新的VPC（ vpcB ），私有子网（ privateSubnet ）和公共子网（ publicSubnet ）。我想允许从 vpcA 到 vpcB 的连接。
I have an existing VPC (vpcA) and have recently setup a new VPC (vpcB) with both a private subnet (privateSubnet) and public subnet (publicSubnet). I want to allow connectivity from vpcA to vpcB.
vpcB 已安装了堡垒服务器，以允许来自 publicSubnet 和 privateSubnet -这可以正常工作，所以我知道ssh设置正确...因此，我开始我想我会尝试允许的ssh连接vpcA 到 vpcB 上的 privateSubnet 。
vpcB was setup with a Bastion server to allow ssh from publicSubnet and privateSubnet - this works so I know ssh is setup properly... so to get started I figured I would try allow ssh connectivity from vpcA to the privateSubnet on vpcB.
我已经建立了一个Peer Connection，并且已经按照解决VPC对等网络连接问题。连接处于活动状态，我已设置从 vpcA 到 10.0.1.0/24 到专用网络的路由设置（专用地址为 10.0.1.10 ），ACL策略似乎允许端口22上的所有流量（暂时），安全组允许端口22上的访问（暂时）。 。当前没有在实例本身上配置防火墙规则，但是当我尝试通过ssh从 vpcA 上的实例进行连接时，得到的是：
I've setup a Peer Connection and I've followed all the instructions in Amazon's Troubleshooting guide on resolving VPC peer network connectivity issues. The connection is active, I have routes setup from vpcA to route 10.0.1.0/24 to the private network (the private address is 10.0.1.10), ACL policies appear to allow all traffic on port 22 (for now), and the security groups allow access on port 22 (again for now). There are no firewall rules currently configured on the instances themselves, but when I attempt to connect via ssh from an instance on vpcA what I get is:
$ ssh -vvv 10.0.1.10
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.1.10 [10.0.1.10] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 10.0.1.10 port 22: Connection timed out
ssh: connect to host 10.0.1.10 port 22: Connection timed out
traceroute给了我这个：
traceroute gives me this:
traceroute to 10.0.1.10 (10.0.1.10), 30 hops max, 60 byte packets
1 * * *
2 * * *
... [same up to 30]
ssh来自 publicSubnet 在 vpcB 上到 privateSubnet vpcB 上的c>正常工作，所以我知道ssh本身正在实例本身上工作。但是很明显，流量没有通过VPC对等连接。
ssh from bastion server in publicSubnet on vpcB to privateSubnet on vpcB works fine so I know ssh itself is working on the instance itself. But clearly traffic is not getting through the VPC Peer Connection.
我知道故障排除可能需要比我到目前为止提供的更多的细节，但是外面有人有这种设置吗？有什么建议可以让我们了解问题的根源吗？
I realize troubleshooting might require more detail than what I've so far provided but does anyone out there have this setup? Any suggestions on where to look next or what piece of configuration I can supply to give us hints on where the problem lies?
谢谢！
推荐答案
helloV 需要涵盖，因为这里有很多地方可能出错。但是，我的具体情况是，我有条目要从vpcA路由到vpcB，但没有从vpcB到vpcA的返回流量的路由。
All of the things mentioned by helloV need to be covered since there are many things that can go wrong here. However, my specific case was that I had entries to route from vpcA to vpcB BUT no route for the return traffic from vpcB to vpcA.
有关VPC对等路由表的Amazon文档暗示此报价中的这一需求：
The Amazon documentation on routing tables for VPC Peering alludes to this need in this quote:
要在VPC对等连接中启用VPC之间的流量路由，必须将路由添加到一个或指向VPC对等连接的更多VPC路由表，以访问对等连接中另一个VPC的全部或部分CIDR块。同样，另一个VPC的所有者必须在其VPC路由表中添加一条路由，以将流量路由回到您的VPC。
To enable the routing of traffic between VPCs in a VPC peering connection, you must add a route to one or more of your VPC route tables that points to the VPC peering connection to access all or part of the CIDR block of the other VPC in the peering connection. Similarly, the owner of the other VPC must add a route to their VPC route table to route traffic back to your VPC.
最后一个这句话很关键-提到的例子突出了这个问题。老实说，最初我对此有点困惑，但是关于路由中重叠CIDR块的解释也阐明了为什么需要此路由：
The last sentence here is the key - and the examples mentioned highlight the issue. Honestly I was a little confused by this initially but this explanation which refers to overlapping CIDR blocks in routes also sheds light on why this route is needed:
AWS当前在VPC对等连接中不支持单播反向路径转发，该功能会检查数据包的源IP并将路由响应数据包路由回源。
AWS currently does not support unicast reverse path forwarding in VPC peering connections that checks the source IP of packets and routes reply packets back to the source.
因此，总体遵循此建议以及helloV帖子中的建议。但是请记住，这些路由必须在所讨论的子网之间是双向的，以便使数据包双向双向流动。
So overall follow this advice and the advice in helloV's post. But keep in mind that those routes need to be bi-directional between the subnets in question in order for you to get packets flowing in both directions.
这篇关于是否允许Amazon VPC A到达VPC B上的新私有子网？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
