如何验证多网卡环境下网络优先级是否已成功切换？

Question

在多网卡（如以太网+Wi-Fi+USB共享网络）环境中，手动调整接口跃点数（metric）或通过策略路由修改优先级后，常出现“配置已保存但实际流量仍走低优链路”的问题。典型现象包括：`route print`（Windows）或`ip route show`（Linux）显示默认路由指向高metric接口；`tracert`/`mtr`探测目标IP时首跳仍为预期外网卡；`netstat -rn | grep '^0.0.0.0'` 显示的默认网关未随metric变更实时生效；甚至系统重启后metric被DHCP或网络管理服务（如NetworkManager、WLAN AutoConfig）自动重置。根本原因常涉及：路由表缓存未刷新、多路径负载均衡干扰、IPv4/IPv6 metric不同步、或第三方安全软件劫持网络栈。如何快速、准确验证当前**实际出向流量所经网卡及对应路由条目**，而非仅检查配置值？这是运维与故障排查中的高频痛点。

Answer 1

```html

一、现象层验证：确认“真实出口”而非“配置出口”

仅看 route print（Windows）或 ip route show default（Linux）极易误判。需穿透抽象配置，直击数据平面。推荐组合命令：

• Windows：netsh interface ipv4 show interfaces 查接口状态与当前 metric；Get-NetIPConfiguration | Select InterfaceAlias, IPv4DefaultGateway, InterfaceMetric（PowerShell）比 legacy 命令更实时；
• Linux：ip -4 route get 8.8.8.8 —— 关键！ 返回含 dev eth0、via 192.168.1.1、src 192.168.1.100 的完整匹配路径，精确到出向网卡与源地址。

二、协议栈层验证：绕过缓存与策略路由干扰

系统路由缓存（如 Linux 的 fib6_cache 或 Windows 的路由表快照）可能导致 ip route show 显示旧路径。强制刷新并验证：

平台	刷新命令	验证命令（带流量触发）
Linux	ip route flush cache（旧内核）或 echo 1 > /proc/sys/net/ipv4/route/flush	curl -s --interface eth1 -w "%{url_effective}\n" https://httpbin.org/ip 2>/dev/null 强制绑定出口网卡并观察响应源IP
Windows	route -f && route -p 清空+重载持久路由	Test-NetConnection -ComputerName 8.8.8.8 -TraceRoute -SourceAddress 192.168.2.50 指定源IP触发精确选路

三、内核/驱动层验证：捕获真实数据包路径

当策略路由（policy-based routing）或第三方防火墙（如 Kaspersky、Symantec）劫持转发逻辑时，用户态命令可能失真。必须下沉至数据链路层：

• Linux：tcpdump -i any -n 'host 8.8.8.8 and port 53' -c 2 观察哪个接口（eth0/wlan0/usb0）实际发出 DNS 请求包；
• Windows：Wireshark 过滤 ip.dst == 8.8.8.8 && !icmp，右键 → “Follow → UDP Stream”，查看“Interface”列；
• 进阶：Linux 使用 tc exec bpf cat /sys/fs/bpf/tc/globals/egress_dev（若部署了 eBPF 路由跟踪程序）直接读取内核选路决策。

四、策略路由与多宿主深度诊断

在多网卡场景下，main 表未必生效。需检查全路由域：

# Linux 多表检查（常见表ID：254=main, 255=local, 253=default）
ip rule show
ip route show table 254   # 主表
ip route show table 100    # 自定义策略表（如 match src 192.168.3.0/24）
ip -6 route get 2001:db8::1  # 必须单独验证 IPv6，metric 不同步是高频根因！

五、自动化验证脚本与持续可观测性

为避免人工误判，构建轻量级验证流水线：

graph TD
  A[发起探测请求] --> B{目标类型}
  B -->|公网IP| C[ip route get $TARGET]
  B -->|域名| D[nslookup $DOMAIN +short | head -1 | xargs ip route get]
  C --> E[提取 dev & src]
  D --> E
  E --> F[对比预期网卡MAC]
  F --> G[记录 timestamp + interface + gateway]
  G --> H[写入 /var/log/routing_audit.log]

六、典型顽疾根因与防御性配置

以下行为将导致“配置生效但流量不走”：

• ✅ DHCP 客户端重置 metric：Windows 中禁用 WLAN AutoConfig 服务自动调优，或组策略设置 计算机配置 → 管理模板 → 网络 → TCPIP 设置 → 接口跃点数 → 启用“为所有接口分配固定跃点数”；
• ✅ NetworkManager 覆盖：Linux 中编辑 /etc/NetworkManager/conf.d/99-metric.conf：

  [connection]
  ipv4.route-metric=50
  
  [device]
  wifi.scan-rand-mac-address=no

• ✅ IPv4/IPv6 metric 不一致：使用 netsh interface ipv6 set interface "Wi-Fi" metric=100 单独设置 IPv6 metric，否则双栈下优先走 IPv6 低 metric 链路。

七、终极验证法：应用层源地址溯源

最不可绕过的证据链：从应用发起请求，反向追踪其绑定的本地地址与出口设备：

• Python 示例（跨平台）：

  import socket
  s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
  s.connect(("8.8.8.8", 53))
  print("Bound local IP:", s.getsockname()[0])
  s.close()

• 该 IP 必须与 ip route get 8.8.8.8 输出的 src 字段完全一致，且该 src 所属子网必须归属于你期望的网卡（通过 ip addr show 交叉验证）。

```