AWS Site-to-Site VPN：外侧、内侧与 LAN 网段

同一条 AWS VPN 上，三种地址角色容易混淆：外侧对端、内侧 /30 链路，以及受保护的 LAN 网段。都能在下载的配置里读到。

AWS Site-to-Site VPN 的大多数错误都是地址错误，而且发生在任何一个数据包移动之前。隧道的外侧地址到达 IPsec 对端，内侧地址构成两者之间的路由链路，而受保护的网段正是这条链路存在的目的。把一个角色抄成另一个，隧道会起来，却什么都不通。下面是我在 BGP 客户网关上使用的读—核对—配置顺序，其中的值取自下载的设备配置，而不是凭记忆。

三个地址角色，一条隧道

外侧地址是公网地址，属于 IPsec 对端：AWS 侧每条隧道一个，你这一侧是客户网关的可达标识，并按你实际的 NAT 方案调整。内侧地址是私有地址，属于逻辑链路，AWS 将其记录为从 169.254.0.0/16 中取出的 /30。受保护网段则是你通过这条链路路由并宣告的 VPC、本地或中转网络。

把 LAN 网段当成隧道接口的地址，是这类错误的经典形态。接口看起来配好了，LAN 却没有被宣告，对端也没有到它的路由。隧道甚至能通自己的内侧 ping，而每个应用名都超时。隧道选项参考列出了内侧 CIDR 的限制，包括它必须取自哪个地址范围。

从下载的配置里读值

从连接上下载你所用设备型号的配置，然后把它的地址表当作唯一依据。控制台对每条隧道显示相同的值：外侧 IP、内侧 CIDR，以及 AWS 侧的 BGP 对端地址。两条隧道是独立对象，有独立的外侧端点和独立的内侧 /30，尽管它们承载相同的受保护网络。

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

如果下载的文件和实时控制台不一致，说明文件已过期。重新下载，而不是手工改地址，因为内侧地址对与对端配置的邻居不一致，是一种静默的 BGP 故障。

用正确的地址搭链路

在 Linux 网关上，隧道是 VTI 或 XFRM 接口，内侧 /30 放在该接口上。两条隧道意味着两个接口和两个 BGP 邻居，每个 AWS 端点一个。AWS 在下载的设备配置中印出的约定，把虚拟私有网关放在每个内侧 /30 的第一个地址，把你的客户网关放在第二个，所以你要取较高的地址，与较低的那个建邻居。这里没有任何地方需要 LAN 地址。

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

如果你设备型号的文件印的是相反的配对，就用它的数字并守住规则：接口上的地址是你的，对端地址属于 AWS。反过来做会得到一条永远到不了 Established 的隧道，因为你配的邻居正是自己接口已经持有的地址。

让 mark 和 VTI key 与 IKE 守护进程把子 SA 绑到接口时使用的值保持一致，否则流量到了隧道却没有接口可以落地。MTU 要对照路径和 IKE 守护进程自身的设置来查，而不是从另一个站点抄一个数字。

先验证 BGP，再验证路由

IPsec 起来只证明对端就安全联盟达成一致，别的什么也证明不了。BGP 会话是在内侧链路上的另一场协商，所以要读邻居状态和前缀计数，再与你打算宣告的内容对比。

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

状态是 Established 却收到零条前缀，属于策略或宣告问题，而不是隧道问题。在第二条隧道上把整套检查重做一遍；第一条隧道能用只说明地址是合理的，并不说明第二条隧道配过。

跟一个被路由的包，然后停下来

会话开始承载前缀之后，从网关往两个方向测路由：源地址、下一跳，以及放行流量的安全策略。BGP 会话可以是通的，而你的应用所需的那条具体前缀却被过滤、被汇总掉，或指向了错误的接口。

Reachability Analyzer 是 AWS 侧的工具，它接收源、目的和路径，报告在受支持的配置中是哪个组件阻断的。用它来测从 VPC 到你客户网关地址的路径，而不是从应用主机出发。它只分析配置，不会把数据包真正送过本地防火墙，所以要把它的结论和你自己的接口计数、抓包分开看。

把每条隧道的外侧地址对、内侧 /30 和宣告的前缀记进一张表。正是这张表让下一次变更可以被复核。

相关文章