课程库

外观

第9课：让虚拟机借宿主 Wi‑Fi 上网

复制页面

约 9680 字大约 32 分钟

虚拟化NATWi-FiNetplan

2026-08-17

项目目标

在第 8 课中，虚拟机已经在纯二层隔离网络（lab-isolated）中建立了安全的内部通信。但在实际工程实践中，虚拟机往往需要从外部网络更新系统内核、安装软件包或拉取容器镜像；同时，宿主机通常连接在校园或企业无线局域网（Wi-Fi）环境中。

本课将带领你构建企业级经典的双网卡（Dual-Homed）虚拟机架构：为 svr01 保留原隔离内网网卡的同时，追加第二块 VirtIO 网卡接入 libvirt 的 default NAT 网络。通过掌握 Netplan 双网卡配置、NAT 出站全链路跟踪、服务发布双方案（SSH 本地端口转发与 DNAT）以及双默认网关冲突的 Metric 跃点修复，建立严密、可审计且符合现代安全规范的虚拟化网络工程能力。

一、虚拟化网络模式全貌与 NAT 核心机理

在设计虚拟化网络拓扑前，必须从宏观视角审视 Linux 虚拟化领域的网络互通方案。不同场景对物理网络、安全边界及通信性能的要求截然不同。

1.1 虚拟化网络五大经典模式横向全景对比

Linux 与 KVM 虚拟化环境中常见的网络连接模型可以归纳为五大类：

网络模式二层广播域特征三层寻址与路由物理 Wi-Fi 兼容性转发性能损耗典型工业应用场景
隔离模式 (Isolated)纯宿主内部虚拟交换机（无物理网卡介入）无外网路由，禁止与宿主外部网络通信完美兼容（不触碰物理网卡）极低（仅内核内部二层交换）安全测试靶场、多机集群内部通信、纯净开发沙箱
NAT 模式 (Address Translation)私有虚拟广播域（virbr0），与外部物理二层隔离通过宿主内核 SNAT 伪装共享宿主 IP 上网；入站需端口重定向完美兼容（只向 AP 暴露宿主物理 MAC 与 IP）轻微（软路由与连接跟踪查表开销）笔记本开发环境、校园/办公 Wi-Fi 宿主机、云桌面
物理桥接模式 (Bridged)虚拟机直接接入物理交换机广播域，独占 MAC直接从物理网络 DHCP 获取独立 IP，地位等同物理机不支持普通 Wi-Fi（受限于 802.11 协议）极低（硬件交换机直接转发）IDC 机房有线网络、生产物理服务器集群
Macvtap 模式在物理网卡上衍生独立 MAC 的虚拟端点直通物理三层网络，但宿主机与来宾默认二层互不可达不支持普通 Wi-Fi 客户端模式最低（绕过 Linux Bridge 传统转发表）极致网络 I/O 吞吐场景、高性能网络功能虚拟化 (NFV)
覆盖网络 (Overlay / VXLAN)跨三层物理网络封装二层以太网帧（MAC-in-UDP）大二层虚拟私网，支持跨多台物理主机构建扁平网络依赖底层三层 UDP 端口连通即可有封包解包损耗（约 50 字节包头与 MTU 扣减）OpenStack Neutron、Kubernetes (Calico / Flannel) 云原生集群

1.2 普通无线网卡（Wi-Fi）802.11 协议三地址限制与桥接约束

许多初学者常有疑问：“为什么在接入有线网线时可以随心所欲地创建 br0 网桥直连物理网络，而在连入 Wi-Fi 时却必须使用 NAT 模式？”

根本原因在于 IEEE 802.11 无线局域网协议帧格式的底层约束：

  1. 以太网（IEEE 802.3）的自由广播：标准有线以太网交换机具备自主 MAC 地址学习功能。无论一条网线上冒出多少个不同的源 MAC 地址，交换机都能记录在其 MAC 地址表（FDB）中并准确分发帧。
  2. Wi-Fi（IEEE 802.11）的 Station 客户端三地址限制：
    • 普通 Wi-Fi 数据帧在客户端与无线接入点（AP）之间通信时，帧头部只有 3 个 MAC 地址字段：
      • Address 1（接收端 RA, Receiver Address）：AP 的 MAC 地址。
      • Address 2（发送端 TA, Transmitter Address）：关联认证的物理无线网卡 MAC 地址。
      • Address 3（目的端 DA, Destination Address / 源端 SA, Source Address）：上层最终目的或源 MAC 地址。
    • 无线 AP 与无线客户端在建立关联（Association）握手时，AP 的转发表严格绑定了该 Station 的单唯一物理 MAC。如果宿主机将无线网卡挂载到虚拟网桥上，虚拟机会以自己的虚拟 MAC（如 52:54:00:xx:xx:xx）发射无线帧。AP 接收到未经认证关联的陌生 MAC 地址时，会直接判定为非法数据包并予以静默丢弃！
    • 虽然 802.11 标准定义了包含 4 个地址的 WDS（无线分布式系统）模式，但该模式需要无线 AP 硬件与固件的深度支持，绝大多数公共场所（校园网、企业办公 Wi-Fi、家用路由器）均关闭了此功能。

因此，NAT（网络地址转换）是所有无线宿主机环境下让虚拟机访问外部网络的最佳且事实上的唯一标准工程解法。

1.3 NAT 的现实世界全貌与工业映射

NAT 机制并非虚拟化特有，它深刻构成了当今互联网与云计算基础设施的基石：

  • 家用 / 办公无线路由器：入户光纤分配一个公网 IP（或运营商大内网 IP），多台手机、电脑接入局域网（192.168.1.0/24），路由器通过 NAPT（网络地址端口转换）将成百上千个内部私有连接伪装成同一个 IP 发往公网。
  • Docker 容器端口发布（-p 8080:80）：Docker 在宿主机创建 docker0 网桥，容器分配 172.17.0.0/16 私有 IP。外部请求到达宿主端口时，Linux 内核通过 DNAT 规则将请求精准推入容器。
  • 公有云 VPC NAT 网关：阿里云、AWS、腾讯云的私有网络（VPC）中，未挂载弹性公网 IP（EIP）的内网数据库实例通过集中式 NAT 网关统一访问公网拉取依赖，外部流量无法主动刺穿进入内网，形成单向出站的安全屏障。
  • 企业核心业务与堡垒机：生产环境中的核心应用部署在内部隔离网络，只有管理运维或经严格审核的对外服务才通过反向代理与端口转发对外界暴露。

1.4 SNAT、DNAT 与 Linux 连接跟踪（Conntrack）机制剖析

在 Linux 内核中，NAT 由 Netfilter 框架与连接跟踪系统（Conntrack）协同驱动：

  1. 源地址转换（SNAT / MASQUERADE）：
    • 发生在 Netfilter 的 POSTROUTING 链（数据包离开本机前的一刹那）。
    • 当虚拟机的出站数据包到达宿主机出口网卡时，NAT 引擎将数据包头部的源私有 IP（如 192.168.122.100）改写为宿主机物理出口 IP（如 192.168.1.50），并动态分配一个空闲的源端口。
    • 宿主机物理出口如果为动态 IP（如 DHCP 获取的 Wi-Fi），使用 MASQUERADE 目标动作，内核会自动抓取当前出口网卡的实时 IP 填充。
  2. 目标地址转换（DNAT）：
    • 发生在 Netfilter 的 PREROUTING 链（数据包刚进入本机路由决策前）。
    • 外部机器请求宿主机指定端口时，NAT 引擎拦截并将其目的 IP 改写为虚拟机私网 IP，引导数据包注入虚拟机内部。
  3. 连接跟踪（Conntrack）的灵魂作用：
    • NAT 不是无状态的简单改写。当出站数据包被修改后，内核在内存的 Conntrack 哈希表中记录一个“五元组”映射对（协议、原源 IP/Port、原目的 IP/Port、转换后源 IP/Port）。
    • 当公网服务器应答回包到达宿主机时，内核优先查验 Conntrack 表，发现命中已知会话，立刻逆向将目的 IP 还原为虚拟机的私有 IP，使得虚拟机上的应用程序能够在完全无感知的状态下完成端到端通信。

下面通过交互式动画，完整观察数据包在各网络节点间流转时的包头变化与 Conntrack 记录：

网络虚拟化核心机制RFC 1631 / Netfilter ConntrackUbuntu 26.04 / libvirt

虚拟化网络 NAT 地址转换与数据包流向全景

深度拆解 SNAT 源地址伪装、DNAT 端口重定向全链路包头重写过程，观察 Linux 连接跟踪（Conntrack）条目建立与五大网络模式横向对比。

阶段 1 / 7
💻
虚拟机 svr01
ens7: 192.168.122.100
● 当前活动节点
➡️ 出站
TAP (vnet2)
🔀
虚拟网桥 virbr0
GW: 192.168.122.1/24
内核二层交换
⚡ 路由/过滤
ip_forward=1
🛡️
Netfilter NAT 引擎
POSTROUTING (MASQUERADE)
SNAT 地址重写
🌐 出入站
802.11 Wi-Fi
📡
宿主 Wi-Fi 网卡
wlan0: 192.168.1.50
物理出口
☁️ 互联网
无线 AP 路由
🌐
公网服务器 (223.5.5.5)
阿里 DNS / 官方源
外部端点
📦数据包报文头实时剖析（Packet Header Inspection）
内网私有地址，未经转换
以太网源 MAC52:54:00:a1:01:07
以太网目的 MAC52:54:00:ee:00:01 (virbr0)
网络层源 IP (Source IP)192.168.122.100
源端口 (Sport)45678
目的 IP (Destination IP)223.5.5.5
目的端口 (Dport)80 (HTTP)
协议类型 (Protocol)TCP (SYN)
校验和 (Checksum)0x4F12 (Valid)
💡 计算机网络原理与机制洞察：

数据包通过 VirtIO 驱动注入宿主内核对应的 TAP 设备（如 vnet2），物理上接入 virbr0 网桥端口。

💻 对应 Linux 系统底层验证命令：$ ip route show | grep default # 来宾内输出: default via 192.168.122.1 dev ens7

观察要点与操作指引

  1. 点击“自动演示”，观察出站时源 IP 如何从 192.168.122.100 被改写为宿主物理 Wi-Fi 的 192.168.1.50。
  2. 重点留意数据包报文头实时剖析面板中校验和（Checksum）的变化：一旦 IP 与端口被改写，TCP/IP 校验和必须重新计算。
  3. 切换至“DNAT 入站模式”，观察外部客户端如何通过宿主物理 IP 访问到位于私网中的虚拟机服务，体会其与 Docker 容器端口映射的完全一致性。
  4. 切换至“五大虚拟化网络模式横向全景对比”，加深对不同场景选型的技术判断。

二、企业级“双网卡”（Dual-Homed）架构哲学

2.1 生产环境双网卡架构的设计原则与安全隔离价值

在初学阶段，许多人习惯让虚拟机只配置一块单网卡（要么全隔离，要么直接全放通）。但在真实企业级生产架构中，核心服务器往往跨接在两个甚至多个网络平面上，即 双宿主（Dual-Homed）架构：

这种架构具备不可替代的工程优势：

  1. 数据面与管理面分离：内部业务流量、数据库同步、跨节点 RPC 调用在隔离内网（ens3）高速且安全地传输，物理或二层隔离保证无外网嗅探风险；系统更新、运维监控、时钟同步走外部 NAT（ens7）。
  2. 极小化受攻击面（Attack Surface）：内网网卡无需且严禁暴露到公网；外网接入网卡仅用于按需出站，入站默认全阻断。
  3. 防止配置灾难：即便外网网卡发生抖动或被物理拔除，内部业务集群之间的二层通信依然稳如磐石。

2.2 Linux 内核路由选择机制与最长前缀匹配原则

在双网卡虚拟机中，操作系统协议栈面对去往不同目的地的流量，必须依赖内核路由表（FIB）决定数据包交由哪一块网卡发出。

Linux 内核路由匹配遵循以下核心原则：

  1. 最长前缀匹配原则（Longest Prefix Match, LPM）：
    • 当向一个目标 IP 发包时，内核遍历路由表中的所有条目，比较目标 IP 与路由子网掩码按位与（AND）的结果。
    • 匹配长度越长（子网掩码越精确），优先级越高！
    • 例如去往 192.168.77.102 时，匹配 192.168.77.0/24（24 位匹配），而默认路由 0.0.0.0/0 只有 0 位匹配，因此内核绝对优先选择 192.168.77.0/24 所在的 ens3 网卡直接以太网二层直发！
  2. 默认路由（Default Gateway / 0.0.0.0/0）：
    • 当目标 IP 在路由表中找不到任何明细匹配时（例如公网 IP 223.5.5.5），最后才由默认路由兜底。
    • 关键避坑指南：在一台主机上，通常只能存在一个有效的默认网关！如果两块网卡同时声明了默认网关，将引发致命的“双默认网关冲突”故障。

下面通过交互组件直观测试不同场景下的内核路由匹配判定与 Metric 跃点控制：

企业级双网卡架构Dual-Homed ArchitectureNetplan & Route Metric

双网卡虚拟机路由决策与默认网关冲突排错

体验企业级双网卡虚拟机在隔离业务内网（ens3）与外网接入 NAT（ens7）之间的路径决策、双默认网关冲突故障复现以及 Metric 跃点数修复实战。

💤 等待测试发包
🖥️双网卡虚拟机 svr01Linux 内核 6.8 / Ubuntu 26.04
🧭内核路由决策引擎 (FIB)
命中出口: ens3
网卡 1: ens3VirtIO 内网卡
IP: 192.168.77.101/24
接入: virbr-lab (隔离网)
⚡ 正在承载流量
网卡 2: ens7VirtIO 外网卡
IP: 192.168.122.100/24
接入: virbr0 (NAT 网络)
空闲待命
🏢隔离实验网络（virbr-lab）
二层交换口：vnet0 / vnet1
目标节点：desk01 (192.168.77.102)
纯二层安全沙箱，无外网
🌐NAT 网络与互联网（virbr0）
宿主网关：192.168.122.1
出站路径：宿主 Wi-Fi -> 互联网 (223.5.5.5)
SNAT 动态伪装出站
📋虚拟机内部实时路由表（Kernel IP Routing Table）最长匹配优先，若掩码长度一致则 Metric 越小越优先
Destination (目标网段)Gateway (下一跳网关)Genmask (子网掩码)FlagsMetric (跃点)Iface (网卡接口)匹配结果判定
default192.168.122.10.0.0.0UG100ens7 未匹配
192.168.77.00.0.0.0255.255.255.0U0ens3 🎯 命中最长前缀 / 最低 Metric
192.168.122.00.0.0.0255.255.255.0U0ens7 未匹配
🔬底层网络原理机制深度剖析
【网络观测现象】

内网 ping 延迟 < 0.3ms，二层交换机线速转发，数据完全不经过默认网关，不触碰宿主外网网卡。

【内核机理解析】

【最长前缀匹配原则】：192.168.77.102 与 192.168.77.0/24 匹配长度达 24 位，优先于 0 位的默认路由 (0.0.0.0/0)。内核精准选中 ens3 直发。

【排查验证命令】$ ip route get 192.168.77.102 # 输出: 192.168.77.102 dev ens3 src 192.168.77.101 uid 1000
📄对应 Netplan 规范配置（Ubuntu 26.04）
# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    ens3:
      addresses: [192.168.77.101/24] # 仅配置静态 IP，严禁写 gateway4！
    ens7:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 100

观察要点与操作指引

  1. 点击“场景一”与“场景二”，分别点击“发起数据包探测”，观察内核在访问内网与外网时如何分别命中直连路由与默认网关。
  2. 切换至“场景三：双默认网关冲突”，观察内网网卡错误添加 gateway4 后的网络震荡与黑洞丢包现象。
  3. 切换至“场景四：Metric 跃点优先级修复”，观察通过 Netplan 的 route-metric 显式设置优先级后，路由表如何消除冲突并实现双网卡和谐分流。

三、实训任务一：构建企业级经典“双网卡虚拟机”

现在开始进入实操。我们将为虚拟机 svr01 保留原有的隔离网卡 ens3，并在宿主机为其动态或静态热插第二块 VirtIO 网卡接入 default NAT 网络。

3.1 宿主机为 svr01 追加添加第二块 VirtIO 网卡

在宿主机执行网卡添加。你有两种等效的工程实施途径：

状态检查与热插拔参数说明

在为虚拟机附加虚拟网卡前，建议先在【宿主机终端 Host】检查其当前运行状态：

virsh --connect qemu:///system domstate svr01
  • 关机后静态附加（推荐）：若 svr01 处于运行状态（running），可先执行优雅关机：
    virsh --connect qemu:///system shutdown svr01
    关机后使用带有 --config 参数的命令，将网卡定义持久化写入虚拟机的 XML 配置文件中。
  • 在线热插拔（热添加）：若不希望中断虚拟机的运行，可在附加命令中同时追加 --live --config 参数。其中 --live 表示立即生效并热插拔挂载到当前运行的虚拟机中，--config 表示将修改持久写入配置文件，保证下次重启后配置依然保留。
命令行途径（virsh）

在【宿主机终端 Host】执行，为 svr01 附加一块接入 default 网络的 VirtIO 网卡：

# 1. 确认虚拟机当前网卡列表（此时应只有一块 lab-isolated 网卡）
virsh --connect qemu:///system domiflist svr01

# 2. 为 svr01 添加接入 default 虚拟网络的网络接口（推荐关机状态下使用 --config 持久化添加；若虚拟机正在运行且需热插拔，可追加 --live --config）
virsh --connect qemu:///system attach-interface \
  --domain svr01 \
  --type network \
  --source default \
  --model virtio \
  --config

# 3. 再次核验网卡清单，确认出现两个 Interface
virsh --connect qemu:///system domiflist svr01

预期终端输出中，svr01 应显示两行网卡记录，分别指向 lab-isolated 和 default：

 Interface   Type      Source         Model    MAC
-------------------------------------------------------------------
 vnet0       network   lab-isolated   virtio   52:54:00:aa:01:01
 -           network   default        virtio   52:54:00:ee:01:07

3.2 启动虚拟机并识别新网卡硬件

在【宿主机终端 Host】启动虚拟机：

virsh --connect qemu:///system start svr01

通过控制台登录进入【虚拟机 svr01】：

# 登录虚拟机 svr01 串口字符控制台
virsh --connect qemu:///system console svr01

关键操作技巧：virsh console 控制台逃生快捷键

通过 virsh console 进入虚拟机的串口字符终端后，如果需要退出并返回宿主机 shell 命令行，请按下快捷键组合： Ctrl + ]（同时按下键盘上的 Ctrl 键与右方括号键 ]）。 切勿强行关闭外部终端窗口，使用 Ctrl + ] 即可安全挂起串口连接并切回宿主机终端提示符。

在【虚拟机 svr01】内部执行硬件与接口探测：

# 查看所有网络接口
ip link show

此时你应该观察到三个网络接口：

  1. lo：本地回环接口（127.0.0.1）。
  2. ens3：第一块网卡，对应原 lab-isolated 隔离网络。
  3. ens7（或类似编号，如 ens4、enp0s7）：新识别出的第二块物理虚拟网卡，当前处于 DOWN 状态，尚未配置 IP。
# 简洁格式查看当前 IP 分配情况
ip -4 -br addr

3.3 编写 Ubuntu 26.04 Netplan 规范配置文件

Ubuntu 26.04 LTS 默认采用 Netplan + systemd-networkd 架构管理网络。

我们需要为两块网卡精确规划职责：

  • ens3（内网业务卡）：配置静态 IP 192.168.77.101/24，绝对不要配置 gateway4 或 default 路由！
  • ens7（外网出站卡）：开启 dhcp4: true，由 libvirt 内置的 dnsmasq 自动分配 192.168.122.x IP，并自动获取默认网关 192.168.122.1 与 DNS 地址。

在【虚拟机 svr01】中编辑 /etc/netplan/01-netcfg.yaml：

sudo nano /etc/netplan/01-netcfg.yaml

写入以下标准规范配置：

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      addresses:
        - 192.168.77.101/24
      # 注意：隔离内网严禁声明 gateway4 或 default 路由！
    ens7:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 100

关键避坑指南：核对新网卡名与 YAML 缩进

  1. 核对实际网卡接口名：Linux 的可预测网络接口命名规则会依据虚拟 PCI 插槽分配网卡标识符。若在 3.2 步中查到的新网卡为 ens4 或 enp1s0，请务必将配置文件中的 ens7: 替换为实际网卡名，切勿机械照抄！
  2. YAML 严格空格缩进：YAML 对缩进极其敏感，严禁使用 Tab 制表符，必须统一使用空格缩进（通常为 2 个空格）。若缩进不齐，执行 Netplan 时会抛出语法解析错误。

3.4 应用 Netplan 并验证链路与 IP 状态

在【虚拟机 svr01】中应用新配置：

# 应用 Netplan 配置生效
sudo netplan apply

# 验证网卡状态与 IP 分配
ip -4 -br addr

预期输出应清晰显示双网卡各司其职：

lo               UNKNOWN        127.0.0.1/8 
ens3             UP             192.168.77.101/24 
ens7             UP             192.168.122.100/24

同时查看路由表，确认只有一条默认路由指向 ens7：

ip route show

输出范例：

default via 192.168.122.1 dev ens7 proto dhcp src 192.168.122.100 metric 100 
192.168.77.0/24 dev ens3 proto kernel scope link src 192.168.77.101 
192.168.122.0/24 dev ens7 proto kernel scope link src 192.168.122.100 metric 100

此时，虚拟机成功具备了“内有隔离，外有出口”的双宿主基石！

四、实训任务二：NAT 出站全链路与真实软件管理实战

4.1 阶梯式出站连通性递进测试

网络排错不可盲目。当网络不通时，应当采取科学的阶梯式探测法，自底向上逐层验证：

在【虚拟机 svr01】执行：

# 阶段 1：探测首跳虚拟网关（验证虚拟交换与网桥链路）
ping -c 2 -W 2 192.168.122.1

# 阶段 2：探测公网 IP 地址（验证宿主 IP 转发与 SNAT 伪装出站）
ping -c 2 -W 2 223.5.5.5

# 阶段 3：探测域名解析（验证 DNS 转发与解析链路）
resolvectl query mirrors.aliyun.com

避坑技巧：IP 连通但域名解析失败的排查要点

如果阶段 2 成功（能 ping 通 223.5.5.5），但阶段 3 域名解析失败，说明网络三层链路完全正常，问题单纯出在 DNS 上。可以使用 resolvectl status 查看当前分配的 DNS 服务器是否有效。

4.2 配置 Ubuntu 国内开源镜像源并执行软件索引更新

Ubuntu 默认镜像源位于海外官方服务器，下载速度较慢且易受网络波动干扰。我们将虚拟机配置为国内高校或大型云厂商的开源镜像站（如清华大学源或阿里云源）。

在 Ubuntu 24.04 / 26.04 LTS 中，APT 源已迁移为现代的 deb822 格式文件 /etc/apt/sources.list.d/ubuntu.sources。

在【虚拟机 svr01】中备份并替换源：

# 备份原配置
sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak

# 替换为清华大学开源镜像源（或阿里云源）
sudo sed -i 's|http://archive.ubuntu.com/ubuntu/|https://mirrors.tuna.tsinghua.edu.cn/ubuntu/|g' /etc/apt/sources.list.d/ubuntu.sources
sudo sed -i 's|http://security.ubuntu.com/ubuntu/|https://mirrors.tuna.tsinghua.edu.cn/ubuntu/|g' /etc/apt/sources.list.d/ubuntu.sources

# 刷新软件包索引
sudo apt update

终端应飞速拉取各仓库索引，以 All packages are up to date 或提示可升级数量告终。这充分证明了虚拟机的 NAT 出站与高吞吐网络链路完全就绪！

4.3 在线安装网络诊断工具套件

在【虚拟机 svr01】中安装后续排错与探测必备的工具套件：

sudo apt install -y traceroute curl net-tools

4.4 追踪出站真实路由跳数轨迹

运行 traceroute 追踪数据包从虚拟机跃迁到公网的完整物理轨迹：

在【虚拟机 svr01】执行：

traceroute -n 223.5.5.5

观察输出的跳数（Hop）：

traceroute to 223.5.5.5 (223.5.5.5), 30 hops max, 60 byte packets
 1  192.168.122.1  0.281 ms  0.211 ms  0.198 ms
 2  192.168.1.1    2.415 ms  2.891 ms  3.102 ms
 3  10.20.0.1      5.120 ms  5.432 ms  5.890 ms
 4  ... (运营商骨干网跳数)
 8  223.5.5.5      15.231 ms  14.892 ms 15.110 ms
轨迹跳数详细解读
  • 第 1 跳（192.168.122.1）：这是宿主机上的 virbr0 虚拟网桥 IP。数据包在此处经历宿主机内核路由裁决与 Netfilter MASQUERADE 源地址改写。
  • 第 2 跳（192.168.1.1）：这是宿主机所连接的校园 Wi-Fi 或家用无线路由器的网关 IP。说明宿主机物理网卡成功将数据包推入外部真实局域网！
  • 第 3 跳及后续：跨越学校汇聚网关、城域网出口及电信/联通/移动骨干网，最终抵达目标公网服务器。

4.5 深入观察宿主侧 nftables 伪装规则与 Conntrack 连接跟踪

宿主机工具安装与实际 IP 替换提示

  1. 安装工具：conntrack 是 Linux 专用的连接跟踪表查询与状态管理工具。若在宿主机执行时系统提示 conntrack: command not found，请先在宿主机安装该工具套件：
    sudo apt install -y conntrack
  2. IP 过滤替换：命令中的 -s 192.168.122.100 为虚拟机源 IP 过滤示例，请务必替换为 svr01 在 3.4 节中实际获取到的第二网卡 IP（如 192.168.122.x）。

在【宿主机终端 Host】执行验证：

# 查看宿主内核是否开启了核心转发开关（返回 1 表示已开启）
sysctl net.ipv4.ip_forward

# 查看当前活跃的连接跟踪条目（将 192.168.122.100 替换为虚拟机实际获取的 IP）
sudo conntrack -L -s 192.168.122.100

你将清晰看到形如以下的连接跟踪记录：

tcp      6 431998 ESTABLISHED src=192.168.122.100 dst=223.5.5.5 sport=45678 dport=80 src=223.5.5.5 dst=192.168.1.50 sport=80 dport=52100 [ASSURED] mark=0 use=1

这行记录就是 SNAT 最坚实的铁证：内核记录了原始发包的私网源地址 192.168.122.100，以及向外网发送时使用的宿主物理源地址 192.168.1.50。

五、实训任务三：服务发布双方案动手演练

虽然虚拟机借助 SNAT 已经可以随意访问外网，但是由于 NAT 具有天然的单向隔离性，宿主机局域网内的其他物理机（如局域网内的其他物理测试机或移动设备）或者宿主机自身外部网络是无法直接通过虚拟机的私网 IP（192.168.122.100）访问虚拟机的。

如何将虚拟机内部开发的服务安全发布出来？本节演练两种工业级主流方案。

5.1 在 svr01 启动测试 Web 服务

首先在【虚拟机 svr01】中启动一个轻量级 Web 服务用于联调测试。

实用操作技巧：后台运行机制与防止单控制台阻塞

在实际操作中，通过 virsh console 连接虚拟机的串口控制台通常只有一个活跃会话。如果直接在前台运行服务进程，将直接霸占控制台，导致无法继续输入后续测试命令。

因此，应当使用 nohup 结合后台符 & 启动服务：

  • &（后台运行符）：通知 Shell 将命令作为后台作业（Background Job）异步执行，命令输入后终端会立即交回交互提示符控制权。
  • nohup（不挂断运行）：让进程忽略终端挂断信号（SIGHUP），即便后续串口断开重连，后台服务依然稳定运行。
  • > ... 2>&1（I/O 重定向）：将标准输出与标准错误全部定向写入日志文件，避免服务访问日志持续刷屏干扰当前终端输入。

在【虚拟机 svr01】执行：

# 1. 创建临时网站目录并生成测试页面
mkdir -p ~/web-demo && cd ~/web-demo
cat << 'EOF' > index.html
<!DOCTYPE html>
<html>
<head><meta charset="utf-8"><title>svr01 Web Service</title></head>
<body>
  <h1>Hello from svr01 Dual-Homed Virtual Machine!</h1>
  <p>Status: Online through libvirt NAT Network.</p>
</body>
</html>
EOF

# 2. 将 Python HTTP 服务置于后台运行，监听 0.0.0.0 的 8080 端口，并将访问日志重定向保存
nohup python3 -m http.server 8080 --bind 0.0.0.0 > ~/web-demo/http.log 2>&1 &

# 3. 在当前控制台直接验证本地端口监听状态
ss -lnt | grep :8080

确认输出中有 0.0.0.0:8080 或 *:8080，表明后台 Web 服务已稳定建立监听。

5.2 方案 A：宿主配置 SSH 本地端口转发（安全审计与本地发布）

原理：利用 SSH 的安全加密隧道，将宿主机本机的 127.0.0.1:18080 端口转发到虚拟机 svr01 的 8080 端口。

在【宿主机终端 Host】执行：

# 语法：ssh -N -L 宿主监听地址:宿主端口:虚拟机目标地址:虚拟机服务端口 用户名@虚拟机IP
ssh -N -L 127.0.0.1:18080:127.0.0.1:8080 labuser@192.168.122.100

在【宿主机终端 Host】新开一个终端进行访问验证：

curl -i http://127.0.0.1:18080/

预期终端立即输出 HTTP 响应头和 HTML 内容：

HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.12.3
Date: Sun, 06 Sep 2026 10:30:00 GMT
Content-type: text/html; charset=utf-8
Content-Length: 198

<!DOCTYPE html>
<html>
...

方案 A 的工程价值与安全边界

  • 监听地址限定在 127.0.0.1（回环地址），意味着只有宿主机本机能访问该服务，外界物理网络无法触及。
  • 传输全程经由 SSH 强加密，适合开发阶段调试后台数据库（MySQL 3306、Redis 6379）或管理面板，安全等级极高。

5.3 方案 B：宿主配置端口重定向跨机访问（DNAT 目标地址转换）

如果需要让同一 Wi-Fi 下其他物理机器也能访问 svr01 的 Web 服务，就必须在宿主机内核中配置 目标地址转换（DNAT）。

在【宿主机终端 Host】配置 nftables 端口重定向（请将 192.168.122.100 替换为虚拟机实际获取的 IP）：

# 允许宿主机内核转发去往该虚拟机的端口流量
sudo nft add rule ip filter FORWARD ip daddr 192.168.122.100 tcp dport 8080 ct state new,related,established accept

# 在 NAT 表的 PREROUTING 链注入 DNAT 规则：将外部访问宿主 18080 的流量重定向至虚拟机的 8080
sudo nft add rule ip nat PREROUTING tcp dport 18080 dnat to 192.168.122.100:8080

关键原理解析：PREROUTING 链的触发边界与局域网跨机测试

在配置完 DNAT 后，若直接在宿主机本机打开浏览器或执行 curl http://宿主机物理IP:18080/ 测试，常会发现连接被拒绝或超时。这是 Linux Netfilter 架构的经典设计机制所致：

  1. PREROUTING 链的生效范围：Netfilter 的 PREROUTING 链专门处理从外部物理网络接口流入（Ingress）的数据包。
  2. 本机出站流量走 OUTPUT 链：当宿主机自身进程发起访问时，流量产生于本机本地并直接进入 OUTPUT 链路由决策，根本不会经过 PREROUTING 链，因此不会命中刚才添加的 DNAT 规则。
  3. 测试验证建议：
    • 方案 B 验证方式：建议优先从同一 Wi-Fi 下的手机、平板或其他局域网测试机发起访问测试（例如在手机浏览器输入 http://宿主机物理IP:18080）；
    • 单机实验场景：若手头只有当前单台宿主机，请以 5.2 节方案 A（SSH 本地端口转发） 作为最准确、最可靠的验收标准。

从同一局域网下的外部测试设备执行访问：

curl http://宿主机物理IP:18080/

数据包经宿主物理 Wi-Fi 网卡流入并命中 PREROUTING 链，DNAT 将目标 IP 从宿主机改写为 192.168.122.100:8080，通过 virbr0 网桥顺利推入虚拟机内部！

实训结束后清理临时规则

nftables 在删除具体规则时，必须指定规则内部的句柄编号（handle）。通过在查询命令中添加 -a（或 --handle）选项即可列出具体编号：

# 1. 查看 NAT 表 PREROUTING 链中的规则及其 handle 编号
sudo nft -a list chain ip nat PREROUTING

预期输出中每条规则末尾都会标明 # handle X 编号，例如：

table ip nat {
    chain PREROUTING {
        type nat hook prerouting priority dstnat; policy accept;
        tcp dport 18080 dnat to 192.168.122.100:8080 # handle 5
    }
}
# 2. 根据查到的 handle 编号（如 5）精准删除该条临时规则
sudo nft delete rule ip nat PREROUTING handle 5

5.4 工业横向对比：DNAT 与 Docker 容器端口映射（-p）的工业一致性

在掌握了宿主机的 DNAT 配置后，请回顾 Docker 命令：

docker run -d -p 8080:80 nginx

当你执行这条命令时，Docker 底层所做的事情与我们刚才的手动配置完全如出一辙：

  1. Docker 在宿主机创建虚拟网桥 docker0（类似于 libvirt 的 virbr0）。
  2. Docker 在 iptables / nftables 的 PREROUTING 链中添加一条 DNAT 规则：将宿主机物理端口 8080 的流量，目标重写为容器的私有 IP（如 172.17.0.2:80）。
  3. 同时在 POSTROUTING 链配置 MASQUERADE，保证容器出站能正常上网。

无论技术外壳是 KVM 虚拟机还是 OCI 容器，底层依靠的都是 Linux 内核 Netfilter 的同一套 NAT 规则体系！

六、实训任务四：网络排错演练——双网卡默认网关冲突与 Metric 修复

在运维双网卡系统时，最容易出现的重大网络事故就是 “双默认网关冲突”（Dual Default Gateways Conflict）。

6.1 故障注入：在内网网卡错误配置 default 网关

我们动手人为注入该故障，体验真实的排错全流程。

在【虚拟机 svr01】中修改 Netplan 配置，在隔离网卡 ens3 处故意错误地添加一个网关：

sudo nano /etc/netplan/01-netcfg.yaml

修改为以下错误内容：

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      addresses:
        - 192.168.77.101/24
      routes:
        - to: default
          via: 192.168.77.1   # ❌ 错误注入：给隔离内网配置了默认网关！
    ens7:
      dhcp4: true

应用错误配置：

sudo netplan apply

6.2 故障现象复现与观察

查看当前的路由表：

ip route show

你将看到两条同权的 default 默认路由：

default via 192.168.77.1 dev ens3 proto static 
default via 192.168.122.1 dev ens7 proto dhcp src 192.168.122.100 metric 100 
192.168.77.0/24 dev ens3 proto kernel scope link src 192.168.77.101 
192.168.122.0/24 dev ens7 proto kernel scope link src 192.168.122.100 metric 100

此时再次尝试外网通信测试：

# 测试外网 IP
ping -c 4 -W 2 223.5.5.5

# 测试软件包索引拉取
sudo apt update

故障现象出现：

  • ping 命令出现严重的间歇性丢包，甚至 100% packet loss、Destination Host Unreachable！
  • apt update 出现长时间的卡顿（0% [Connecting to mirrors.tuna.tsinghua.edu.cn]），最终报 Connection timed out 错误！

6.3 根因剖析：Linux 内核路由裁决与黑洞网关

为什么配置了两个默认网关会导致外网瘫痪？

  1. 同权竞争：ens3 上的静态路由与 ens7 上的 DHCP 路由争抢默认出口。如果静态路由的 Metric 较小（或未指定 Metric，默认为 0），内核将始终把去往外网的流量交由 ens3 发出。
  2. 黑洞丢弃：数据包从 ens3 发送给 192.168.77.1（virbr-lab 隔离网桥）。但 virbr-lab 根本没有外网转发规则，也没有配置 SNAT，数据包在网桥边界被直接丢弃！
  3. 哈希分流震荡：在支持多路径路由的内核中，不同 TCP 会话可能被交替发往两个网卡，导致一部分握手成功、一部分连接卡死，产生极难排查的幽灵网络抖动。

6.4 规范修复：在 Netplan 中显式设置 Metric 跃点数

修复该问题有两种标准工程方案：

方案一：彻底移除内网网关（最推荐的规范做法）

由于内网网卡 ens3 只负责与同网段的伙伴机（192.168.77.0/24）通信，根本无需网关即可通过二层直连直通。如果确实需要跨路由访问其他内网子网，应当配置明细静态路由，而不是默认网关！

修改 /etc/netplan/01-netcfg.yaml：

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      addresses:
        - 192.168.77.101/24
      # 如有跨网段内网才配置明细路由，例如：
      # routes:
      #   - to: 10.0.0.0/8
      #     via: 192.168.77.254
    ens7:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 100

6.5 应用配置并验证分流恢复正常

在【虚拟机 svr01】中应用修复方案：

sudo netplan apply

# 查看当前路由表状态
ip route show default

此时输出将显示正确的路由裁决（Metric 100 处于绝对优势地位）：

default via 192.168.122.1 dev ens7 proto dhcp src 192.168.122.100 metric 100 
default via 192.168.77.1 dev ens3 proto static metric 600

使用 ip route get 验证内核针对不同目的地的实际裁决情况：

# 测试外网 IP 的出口裁决：必须走 ens7
ip route get 223.5.5.5

# 测试隔离内网 IP 的出口裁决：必须走 ens3
ip route get 192.168.77.102

预期输出：

  • 访问 223.5.5.5 显示 via 192.168.122.1 dev ens7！
  • 访问 192.168.77.102 显示 dev ens3 src 192.168.77.101！

再次执行 curl -I https://mirrors.tuna.tsinghua.edu.cn/，连接瞬间建立，排错大获全胜！

七、常见问题排错矩阵（9.5）

在虚拟化双网卡与 NAT 网络实训中，若遇到异常，请对照下表进行阶梯式分层排查：

故障现象优先排查层级定位检查命令根本原因分析规范解决措施
虚拟机无法获取 IP，网卡处于 DOWN 状态物理设备与驱动层ip link show
lspci | grep -i virtio		虚拟网卡未正确挂载，或驱动缺失在宿主机使用 virsh domiflist 核对网卡是否接入 default 网络；检查虚拟机内核 VirtIO 驱动
能 Ping 通网关，但 Ping 不通外网 IP宿主转发与 SNAT 层sysctl net.ipv4.ip_forward
sudo nft list ruleset		宿主机内核未开启三层 IP 转发，或缺少 MASQUERADE 规则在宿主机执行 sudo sysctl -w net.ipv4.ip_forward=1；检查 libvirt 的 default 网络是否处于 active 状态
能 Ping 通外网 IP，但域名无法解析域名解析应用层resolvectl status
cat /etc/resolv.conf		DNS 服务器地址未正确获取，或上游 DNS 服务不可用使用 resolvectl dns ens7 223.5.5.5 临时测试；检查 Netplan 配置中的 nameservers 声明
虚拟机外网频繁超时，丢包率极高路由表冲突与 Metric 混乱ip route show
ip route get 223.5.5.5		双默认网关冲突，流量被错误路由至隔离网卡 ens3移除内网网卡的 gateway4，或显式在 Netplan 中为外网网卡配置较低的 route-metric: 100
宿主执行 SSH 端口转发提示 Permission denied服务端认证与权限tail -f /var/log/auth.log虚拟机用户名密码错误，或 SSH 服务禁止密码登录确认虚拟机安装了 openssh-server；检查 /etc/ssh/sshd_config 中的认证配置
从宿主外部测试机无法通过 DNAT 访问 Web 服务防火墙过滤拦截sudo nft list chain ip filter FORWARD
ss -lnt		宿主机 FORWARD 链策略为 DROP，且未放通该端口转发在宿主机 filter 表的 FORWARD 链添加针对虚拟机 IP 和端口的明确放行规则

八、交付与验收标准（9.6）

完成本课实训后，必须提交以下 4 张关键证据截图，用以全面证明双网卡虚拟机的网络能力建设与排错成果：

4 张必交截图清单与验证要点

  1. 截图一：双网卡配置与 IP 状态截屏
    • 执行命令：在【虚拟机 svr01】执行 ip -4 -br addr。
    • 验证要点：必须同时展示 ens3（静态 IP 192.168.77.101/24，UP 状态）与 ens7（DHCP IP 192.168.122.x/24，UP 状态），两块网卡各就各位。
  2. 截图二：真实路由表与出站跳数轨迹截屏
    • 执行命令：在【虚拟机 svr01】先后执行 ip route show default 与 traceroute -n 223.5.5.5。
    • 验证要点：路由表中默认网关必须正确指向 192.168.122.1 dev ens7；traceroute 轨迹第一跳必须为 192.168.122.1（virbr0），第二跳必须为宿主机上游局域网网关。
  3. 截图三：在线镜像源刷新与软件管理安装截屏
    • 执行命令：在【虚拟机 svr01】执行 sudo apt update。
    • 验证要点：终端输出完整拉取国内开源镜像源（清华源或阿里源）索引的过程，最后无任何网络报错，显示 All packages are up to date 或软件包更新统计。
  4. 截图四：服务发布访问成功截屏
    • 执行命令：在【宿主机终端 Host】执行 curl -i http://127.0.0.1:18080/。
    • 验证要点：终端输出标准的 HTTP/1.0 200 OK 响应报文，以及由 svr01 的 Python 服务返回的页面标题 svr01 Web Service，完整闭环验证服务发布成功。

本章小结

本课带领你跳出单纯的“单机单网卡”初级运维思维，跨入了企业级虚拟化网络架构的专业大门：

  1. 厘清了五大网络模式定位与 Wi-Fi 限制本质：深刻理解了普通 Wi-Fi Station 模式因 802.11 协议的三地址帧限制无法直接承载虚拟化二层桥接，确立了 NAT 作为无线环境下稳定上行的工业标准地位。
  2. 践行了企业级“双网卡”（Dual-Homed）安全架构：为 svr01 成功组装了“内网数据隔离 + 外网 NAT 出站”的经典双网卡体系，做到了业务私密性与软件更新便利性的完美统一。
  3. 攻克了双默认网关冲突难题：剖析了最长前缀匹配与 Metric 跃点裁决的内核级算法，熟练运用 Ubuntu 26.04 Netplan 实现了精准、可靠的路由分流。
  4. 打通了双向网络链路：既掌握了出站 SNAT 的连接跟踪（Conntrack）机理，又掌握了入站服务的 SSH 本地安全转发与 DNAT 端口映射发布，具备了应对复杂现实网络拓扑的综合运维实战技能！