避坑指南：ESXi虚拟机双网卡配置中，90%的人会忽略的网关与路由问题

深度解析：ESXi虚拟机双网卡配置中的网关与路由陷阱

当你为ESXi上的Ubuntu虚拟机配置双网卡时，是否遇到过这样的场景：两个网卡分别连接不同网段，IP地址配置正确，但虚拟机就是无法同时访问两个网络？或者更诡异的是，有时能通有时不通，流量走向完全不符合预期？这背后往往隐藏着Linux路由系统和ESXi虚拟网络联动的深层机制问题。

1. 为什么双网卡配置会出问题？

大多数教程只教你如何在ESXi上添加虚拟交换机和网卡，却很少解释背后的网络栈工作原理。实际上，当你在Ubuntu中为两个网卡都配置 gateway4 时，就已经埋下了问题的种子。

Linux系统在设计上 只允许一个默认网关 存在。当你通过Netplan或 /etc/network/interfaces 为两个网卡都指定网关时，后加载的配置会覆盖之前的默认路由。这会导致：

• 流量可能全部从一个网卡流出，另一个网卡形同虚设
• 网络访问出现间歇性故障
• 特定网段的通信完全失败

查看路由表就能发现问题：

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.1.1       0.0.0.0         UG    100    0        0 ens160
0.0.0.0         192.168.1.1    0.0.0.0         UG    101    0        0 ens192
10.1.0.0        0.0.0.0        255.255.240.0   U     0      0        0 ens160
192.168.1.0     0.0.0.0        255.255.255.0   U     0      0        0 ens192

关键提示：当看到路由表中有多个 0.0.0.0 目标时，说明存在多个默认网关配置，这是典型的问题征兆。

2. 正确的双网卡配置方案

解决这个问题的核心原则是： 一个默认网关+精确的静态路由 。以下是具体操作步骤：

2.1 Netplan配置示例

network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      addresses: [10.1.1.100/24]
      routes:
        - to: 0.0.0.0/0
          via: 10.1.1.1
          metric: 100
      nameservers:
        addresses: [114.114.114.114, 8.8.8.8]
    ens192:
      addresses: [192.168.1.100/24]
      routes:
        - to: 192.168.2.0/24
          via: 192.168.1.1
          metric: 100

关键点解析：

• 只有 ens160 配置了默认路由( 0.0.0.0/0 )
• ens192 只配置了特定网段的静态路由
• 使用 metric 确保路由优先级明确

2.2 传统interfaces配置方式

# /etc/network/interfaces
auto ens160
iface ens160 inet static
    address 10.1.1.100
    netmask 255.255.255.0
    gateway 10.1.1.1
    dns-nameservers 114.114.114.114

auto ens192
iface ens192 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    up ip route add 192.168.2.0/24 via 192.168.1.1

3. ESXi层面的关联配置

虚拟机网络问题往往需要结合ESXi配置一起分析。以下是需要特别注意的虚拟交换机设置：

常见陷阱案例 ：

• 虚拟交换机绑定了多个物理网卡(vmnic)，但未正确配置NIC Teaming策略
• 端口组VLAN ID与物理交换机不匹配
• 启用了"混杂模式"导致安全风险

诊断命令：

# ESXi Shell中查看虚拟交换机配置
esxcli network vswitch standard list
esxcli network vswitch standard portgroup list

# 查看物理网卡状态
esxcli network nic list

4. 高级场景与疑难解答

4.1 多默认网关的特殊需求

某些特殊场景确实需要多默认网关，比如：

• 策略路由(基于源地址的路由)
• 故障转移需求

这时可以使用 ip rule 实现：

# 添加基于源地址的路由规则
ip rule add from 10.1.1.100 lookup 100
ip rule add from 192.168.1.100 lookup 200

# 配置多路由表
echo "100 custom1" >> /etc/iproute2/rt_tables
echo "200 custom2" >> /etc/iproute2/rt_tables

ip route add default via 10.1.1.1 table custom1
ip route add default via 192.168.1.1 table custom2

4.2 网络命名空间隔离

对于更复杂的场景，可以考虑使用Linux网络命名空间实现完全隔离：

# 创建新的网络命名空间
ip netns add ns1

# 将ens192移到命名空间中
ip link set ens192 netns ns1

# 在命名空间中配置网络
ip netns exec ns1 ip addr add 192.168.1.100/24 dev ens192
ip netns exec ns1 ip link set ens192 up
ip netns exec ns1 ip route add default via 192.168.1.1

4.3 诊断工具与技巧

当网络不通时，按以下顺序排查：

1. 链路层检查

   ip link show  # 查看网卡状态
   ethtool ens160  # 查看物理连接状态
   

2. ARP表验证

   ip neigh  # 查看ARP缓存
   arping -I ens160 10.1.1.1  # 测试ARP解析
   

3. 路由追踪

   traceroute -n 8.8.8.8  # 查看实际路径
   ip route get 8.8.8.8  # 查看路由决策
   

4. 防火墙检查

   iptables -L -n -v  # 查看过滤规则
   nft list ruleset  # 新版防火墙检查
   

5. 性能优化与最佳实践

经过多次实战验证，我总结出以下配置原则：

• 单一默认网关 ：确保主出口明确
• 精确静态路由 ：为每个需要访问的网段添加明确路由
• 合理metric值 ：备用路由设置更高metric
• ESXi端口组隔离 ：不同网段使用不同端口组
• 定期路由检查 ：设置监控检查路由表状态

一个生产环境中的优化配置示例：

# /etc/netplan/99-multi-nic.yaml
network:
  version: 2
  ethernets:
    ens160:
      addresses: [10.1.1.100/24]
      routes:
        - to: 0.0.0.0/0
          via: 10.1.1.1
          metric: 100
        - to: 172.16.0.0/16
          via: 10.1.1.254
          metric: 200
      nameservers:
        addresses: [10.1.1.53]
    ens192:
      addresses: [192.168.1.100/24]
      routes:
        - to: 192.168.2.0/24
          via: 192.168.1.1
          metric: 100
      routing-policy:
        - from: 192.168.1.100
          table: 200
      routing-table:
        200:
          routes:
            - to: 0.0.0.0/0
              via: 192.168.1.1
              metric: 100

最后记住，在虚拟化环境中网络问题往往需要同时检查虚拟机和宿主机的配置。一次我遇到虚拟机无法访问特定网段的问题，最终发现是ESXi主机上的物理网卡连接到了错误的VLAN。这种跨层问题需要系统性的排查思路。