多 NIC 的 GCP 虚拟机：为什么应答从错误的接口发出

给 Compute Engine 虚拟机挂上第二块网卡，只是多了一个网络连接，并不会形成对称的回程路径。访客仍根据自己的路由和规则选择接口与源地址。随后 Google Cloud 围绕数据包离开的那块接口应用 VPC 路由和防火墙策略。当这两个决定不一致时，请求从一块 NIC 进来，应答却从另一块出去，分支看到的是一段半开的会话。

分五步走一遍，分歧会在你写策略规则之前暴露出来。

第 1 步：把云端 NIC 映射到访客设备

云端把接口命名为 nic0、nic1 等，而访客看到的设备名不一定相同。在做任何其他事情之前，先根据实例元数据或接口自身地址确定这一映射。DHCP 提供的普通默认路由与 nic0 关联，所以面向互联网的路径常常意外胜出。照着猜出来的设备名写策略，正是正确规则落到错误接口上的原因。

记录地址、设备名以及各自所属的 VPC。这张三列表格是后续每一步的输入。

第 2 步：为两个路由决定命名

第一个决定属于访客：这个数据包用哪块接口、哪个源地址。第二个决定属于云端：VPC 的路由和防火墙策略允许这块接口做什么。

面向 VPN 的 VPC 里可见的路由，不会自动变成选中那块 NIC 的访客路由。云端路由描述网络能送达什么，而访客路由决定数据包实际怎么走。

第 3 步：选择回程策略

对于规模小且稳定的分支前缀集合，访客里的显式目标路由是最简单的表达：发往这些前缀的应答从面向 VPN 的接口出去。当多个服务有意使用不同的本地源地址时，按接口选择路由表的源地址规则能让每个应答留在正确的上下文中。多接口文档说明了这些设计所依赖的 NIC 命名和默认路由行为。

每张路由表都需要有效的直连路由和下一跳，以及将会被查询的目标。指向不完整路由表的规则不构成回程设计。使用该 NIC 文档中给出的网关，而不是根据子网的外观臆造一个以太网网关。

第 4 步：检查访客自身的过滤

检查服务器在哪里监听，以及应答携带哪个本地源地址。监听所有地址并不会覆盖路由策略，因此绑定到所有地址并不会改变应答离开的接口。

在 Linux 上，对照预期设计复查反向路径校验。一上来就全局关闭它，等于把路由缺陷换成了被伪造的风险，还掩盖了你正在寻找的不对称。

第 5 步：每条路径测一条流

分别验证一个被允许的分支请求和一个无关的互联网请求，各自使用真实的源和目的。有条件时在两块接口上都抓包，因为有用的证据是应答走了哪块接口。然后确认云侧策略尊重了你设计的路径。一个成功的请求只能证明一条流，不能证明对称设计。

把两个测试分开记录，因为它们走的是不同路由、不同防火墙规则。

第二块 NIC 不能给你什么

第二块接口只增加一个网络连接和另一个地址。它不会自动带来对称路由，也不会绕过防火墙策略。把它当作路由修复，正是多 NIC 设计不断堆积无人能解释的规则的原因。

如果虚拟机必须转发其他机器的流量，就要明确规划这个路由器角色，包括允许转发的云端设置以及配套的访客过滤。