AWS EC2 挂载新网卡不通？从网卡启动到策略路由的完整排查指南

在 AWS 云环境中，为运行中的 EC2 实例挂载第二张弹性网卡（ENI）是一个常见需求，用于流量隔离、管理平面分离或高可用架构。

然而，很多工程师（包括我自己）都会遇到一个经典问题：在 AWS 控制台点击"附加"成功后，服务器里却死活 ping 不通新网卡 IP，NLB 健康检查也报红。

这篇文章复盘了从"网卡挂载"到"路由配置"的全过程，揭示了为什么"AWS 显示已附加"并不等于"网络已通"。

现象描述

1. 场景：有一台 EC2（主网卡 ens5，IP 10.23.0.43）。

2. 操作：在 AWS 控制台附加了第二张网卡 ens6（IP 10.23.20.28），属于同一个 VPC 的另一个子网。

3. 问题：

• AWS 控制台显示网卡状态为 In-use（已使用）。

• 但是从服务器内部或外部 ping 10.23.20.28 均不通。

• 绑定的 NLB 目标组健康检查显示 Unhealthy。

根本原因分析

AWS 的"附加网卡"操作仅仅相当于给虚拟机的物理插槽上插了一块网卡硬件。Linux 操作系统内核虽然能识别到硬件（ip link 可见），但不会自动完成以下配置：

1. 接口未启动：系统默认不会自动 UP 新网卡。

2. IP 未绑定：DHCP 在某些非主网卡上可能不自动生效，或者需要手动指定掩码范围。

3. 路由黑洞（最关键）：Linux 默认只有一个主路由表。

• 进得来：外部流量能到达 ens6。

• 出不去：回包时，内核查主路由表，发现默认网关是 ens5。于是包从 ens5 发出去，源 IP 却是 ens6 的 IP。

• 结果：AWS 底层校验（Source/Destination Check）发现 IP 与网卡不匹配，直接丢弃数据包。

---

解决方案：三步走实战

第一步：物理层与网络层唤醒

首先要让操作系统接管这块网卡，并分配正确的 IP 地址。

Bash

**# 1. 启用网卡接口
sudo ip link set ens6 up

2. 绑定 IP 地址与子网掩码

注意：必须使用 /24 (或实际子网掩码)，不能用 /32，否则网卡找不到网关

sudo ip addr add 10.23.20.28/24 dev ens6**

此时，同子网内的直连通信（10.23.20.x）通常已经通了，但跨网段访问和 NLB 依然有问题。

第二步：配置策略路由（解决回包问题）

这是解决"多网卡不通"的核心。我们需要告诉内核："凡是别人发给 ens6 的包，回信时必须强制走 ens6，不许走主网卡默认路由。"

这需要用到 Linux 的 策略路由 (Policy Routing)。

1. 创建专属路由表：
   在 /etc/iproute2/rt_tables 中添加一个新表，例如 ID 为 200，名字叫 nlb_table。

2. **配置表内容（路由条目）：
   Bash

   给 200 号表添加一条默认路由，指向 ens6 的网关

   sudo ip route add default via 10.23.20.1 dev ens6 table nlb_table**

3. **配置查表规则（策略）------ 也就是"保险开关"：
   Bash

   关键命令：源 IP 是 10.23.20.28 的包，强制去查 200 号表

   sudo ip rule add from 10.23.20.28 lookup nlb_table pref 1000
   如果没有这一步，前面的配置全是摆设，内核依然会傻傻地去查主表。**

第三步：优化出站路由（解决主动访问问题）

如果希望这台服务器访问特定网段（如 10.23.20.0/22）时，主动使用新网卡以获得更短的物理路径：

Bash

**# 添加静态路由到主表

含义：去往 /22 网段，走 ens6，网关 10.23.20.1，且源 IP 填 10.23.20.28

sudo ip route add 10.23.20.0/22 via 10.23.20.1 dev ens6 src 10.23.20.28**

---

验证与总结

配置完成后，使用以下方式验证：

1. 检查路由规则：
   ip rule show ------ 必须看到 from 10.23.20.28 lookup nlb_table。

2. 模拟内核决策：
   ip route get 8.8.8.8 from 10.23.20.28 ------ 输出必须包含 dev ens6 和 table nlb_table。

避坑指南

1. 掩码陷阱：配置 IP 时不要习惯性写 /32，一定要写 /24（或子网实际掩码），否则网卡找不到邻居和网关。

2. 重启失效：上述所有 ip 命令都是内存临时的。重启服务器后会消失。生产环境建议将这些命令写入 /etc/rc.local，或者配置 Netplan / NetworkManager 脚本实现持久化。

3. SSH 断连风险：千万不要随意修改主路由表的 default 路由（Metric），除非你已经给主网卡配置了类似的"策略路由保护"，否则 SSH 可能会瞬间断开。

总结

AWS EC2 多网卡配置不仅仅是点一下"Attach"，本质上是一次 Linux 高级网络配置实战。"路由表 (ip route) 指引方向，策略规则 (ip rule) 决定查哪张表"，理解了这一点，多网卡问题便迎刃而解。