第8课：组建看不见的实验室局域网

约 13163 字大约 44 分钟

虚拟化虚拟网络隔离网络libvirt

2026-08-17

实验目标

本实验通过 libvirt 定义并启动纯隔离虚拟网络 lab-isolated，搭建由 Linux 内核软件网桥 virbr-lab 驱动的二层私有交换环境；将 Ubuntu Server svr01 与 Ubuntu Desktop desk01 接入该网络，通过内嵌 DHCP 自动获取专用网段地址；在虚拟机内搭建并验证轻量 HTTP 服务的同网段全双工通信；借助宿主机 tcpdump 抓包捕获 ARP、ICMP 与 TCP 握手流量；掌握基于“链路—地址—路由—防火墙—端口”的五层网络排错决策方法与深层网络虚拟化工作机理。

拓扑说明｜ 在宿主机内部，libvirt 通过 Linux Bridge 模块构建了一台看不见的纯软件虚拟以太网交换机 virbr-lab。两台虚拟机通过动态 TAP 端口插在这个虚拟交换机上，形成完全独立、无法随意跨越宿主物理网卡访问外部互联网的安全私网。

网络对象	标识 / 参数	对应作用与说明
libvirt 网络名称	`lab-isolated`	libvirt 管理层面的虚拟网络对象名
宿主软件网桥	`virbr-lab`	Linux 内核生成的二层虚拟交换网桥接口
IPv4 网络号与子网掩码	`192.168.77.0/24`	隔离局域网私有 IPv4 地址空间
宿主机网桥接口 IP	`192.168.77.1`	宿主机接入该局域网的管理地址兼内置 DNS/DHCP 网关
DHCP 动态地址池	`192.168.77.100` — `192.168.77.199`	分配给接入本隔离局域网的虚拟机地址范围
服务端虚拟机	`svr01` (Ubuntu Server 26.04)	部署 Python 8080 端口测试 Web 服务
客户端虚拟机	`desk01` (Ubuntu Desktop 26.04)	执行 ping 连通性探测与 curl HTTP 网页测试

本实验核心网络规划

实验前准备：推荐 3 个终端窗口分工

为避免在多台虚拟机与宿主机之间频繁切换上下文造成操作混乱，强烈建议在进入实训前准备好 3 个独立的终端窗口并排或分屏摆放：

窗口 1【宿主机终端 Host】：负责执行 virsh 网络与虚拟机管理、验证网桥状态、运行 tcpdump 网桥抓包等全局操作。
窗口 2【服务端虚拟机 svr01】：通过控制台登录，专门负责启动 Python HTTP 后台服务、监控端口监听与服务端网络状态。
窗口 3【客户端虚拟机 desk01】：通过控制台登录，专门负责清空 ARP 缓存、执行 ping 连通性探测及运行 curl 发起 HTTP 请求。

8.1 任务一：创建并启动隔离虚拟交换机——libvirt Network XML 与软件桥

在企业开发或攻防实训中，许多网络环境要求严格的安全边界——既能允许多台虚拟机高速内网协作，又严禁虚拟机向外部互联网收发数据包。本任务将使用 libvirt Network XML 构建这样一张无外部转发的隔离网络。

1. 【动手做】规划与创建隔离虚拟网络

在【宿主机终端 Host】中，检查当前宿主路由表，确保计划使用的 192.168.77.0/24 网段未与宿主局域网产生重叠：

# 【宿主机终端 Host】检查宿主路由表是否冲突
ip -4 route show | grep '192.168.77' || echo "网段未占用，可以安全使用"

在【宿主机终端 Host】中，编写网络定义文件 lab-isolated.xml：

# 【宿主机终端 Host】编写隔离网络 XML 定义文件
cat <<'EOF' > lab-isolated.xml
<network>
  <name>lab-isolated</name>
  <bridge name='virbr-lab' stp='on' delay='0'/>
  <domain name='lab.internal' localOnly='yes'/>
  <ip address='192.168.77.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.77.100' end='192.168.77.199'/>
    </dhcp>
  </ip>
</network>
EOF

XML 核心配置说明｜ <domain name='lab.internal' localOnly='yes'/> 为局域网虚拟机指定内部域名后缀（如 svr01.lab.internal），其中 localOnly='yes' 告知内置 DNS 仅在隔离内网解析，绝不向外部互联网转发递归查询，进一步强化隔离安全。

在【宿主机终端 Host】中，执行 libvirt 命令定义、启动网络并设置开机自动启动：

# 【宿主机终端 Host】定义、启动并自启隔离网络
virsh --connect qemu:///system net-define lab-isolated.xml
virsh --connect qemu:///system net-start lab-isolated
virsh --connect qemu:///system net-autostart lab-isolated

2. 【看现象】验证软件网桥状态

在【宿主机终端 Host】中，检查 libvirt 网络列表与运行详情：

# 【宿主机终端 Host】检查网络对象状态
virsh --connect qemu:///system net-info lab-isolated

预期输出中 Active: yes 且 Autostart: yes：

Name:           lab-isolated
UUID:           7c65d9a0-9742-4f36-8db8-1c4b8b6e22f1
Active:         yes
Persistent:     yes
Autostart:      yes
Bridge:         virbr-lab

在【宿主机终端 Host】内核接口中查看新生成的 virbr-lab 软件网桥状态与 IP：

# 【宿主机终端 Host】查看宿主网桥接口与 IP
ip -4 -br addr show virbr-lab

预期输出：

virbr-lab        UP             192.168.77.1/24

关键避坑指南

如果在执行 net-start lab-isolated 时报错 Network is already in use by interface virbr-lab，说明内核残留了之前未清理的旧网桥。可以使用 sudo ip link delete virbr-lab 删除残留网桥后再启动。

3. 【学原理与拓展】Linux 软件网桥底层机制与 Network XML 架构

在物理数据中心中，服务器之间要实现互联，必须依靠一根根物理网线插入机架上的物理以太网交换机中。交换机内部依靠专用硬件 ASIC 芯片完成二层数据帧的快速转发。而在虚拟化环境中，Linux 内核通过模块化设计，将操作系统本身变成了一台高性能的纯软件二层交换机。

(1) Linux Bridge 内核实现与 FDB MAC 地址转发表机制

Linux 软件网桥由内核模块 bridge.ko 驱动，它严格工作在 OSI 模型的第二层（数据链路层）。当一个虚拟网络接口（如 vnet0）被添加到网桥 virbr-lab 中后，网桥的核心任务就是维护一张 转发表（Forwarding Database，简称 FDB）：

源 MAC 自主学习（Source Learning）：当虚拟机 svr01 从其虚拟网卡发送一个以太网数据帧时，数据帧流入 TAP 端口 vnet0 并进入网桥。Linux 网桥首先解析以太网帧头，提取出发送方的 源 MAC 地址（Source MAC），并将该 MAC 地址与进入的端口号 vnet0 绑定，记录到内核 FDB 哈希表中。
老化定时器（Aging Timer）： FDB 表项并非永久固定。内核为每个动态学习到的条目设置了老化定时器（默认 300 秒）。如果在老化时间内没有再次收到该 MAC 的数据帧，该条目将被自动清除，以适应虚拟机迁移或网卡更换。
三种转发决策（Forwarding Decisions）：网桥提取数据帧的 目标 MAC 地址（Destination MAC），根据 FDB 表项做出精准决策：
- 已知单播（Known Unicast）：若目标 MAC 在 FDB 中存在，且记录的出口端口不是进入端口，则网桥直接将数据帧定向推送到该端口（如从 vnet0 精准转发给 vnet1），其他端口完全听不到该通信，保证通信私密性与总线效率；
- 未知单播与广播泛洪（Flooding）：若目标 MAC 不在 FDB 中，或是以太网广播地址（FF:FF:FF:FF:FF:FF），网桥执行泛洪操作，向除进入端口之外的所有激活从属端口复制发送该帧；
- 同端口过滤（Drop）：若目标 MAC 记录的端口就是当前输入端口，网桥直接丢弃该数据帧，杜绝无效折返。

在宿主机终端中，你可以使用 bridge fdb show 命令直接查看当前内核网桥学习到的物理转发表：

# 【宿主机终端 Host】查看内核网桥的 FDB MAC 转发表
bridge fdb show dev virbr-lab

(2) 生成树协议（STP）与 `delay='0'` 的工程含义

在我们的 XML 中，有一行配置：<bridge name='virbr-lab' stp='on' delay='0'/>。这行配置包含两个至关重要的网络工程原理：

为什么需要 STP（Spanning Tree Protocol，生成树协议）？ 在复杂网络中，若多台交换机之间存在冗余线路，或者网桥之间错误地形成了闭环互联，广播帧会在环路中被无休止地复制泛洪，瞬间占满所有 CPU 和带宽，导致整个网络瘫痪，这被称为“广播风暴（Broadcast Storm）”，同时还会导致 FDB 表项在不同端口间剧烈跳变（MAC 震荡）。STP 协议通过在网桥间交换 BPDU（网桥协议数据单元）报文，自主发现环路并逻辑阻塞冗余端口，确保任意两点间只有一条活动二层路径。
为什么必须设置 delay='0'？ 物理交换机在启用 STP 时，端口为了防止环路，接入新设备后需要经历 Blocking（阻塞）➔ Listening（监听）➔ Learning（学习）➔ Forwarding（转发） 四个阶段。默认的转发延迟（Forward Delay）长达 15 到 30 秒！如果虚拟机开机时网桥端口处于 15 秒的监听等待期，虚拟机的 DHCP 请求发出时端口还未开放转发，虚拟机就会因为拿不到 IP 而开机网络报错。在虚拟化单网桥私有环境下，不存在复杂的物理冗余环路，因此将 delay 显式设为 0，使得虚拟端口一开机即可跳过等待、瞬间进入 Forwarding 转发状态，保证虚拟机 DHCP 能够秒级获取 IP。

(3) libvirt Network XML 四大网络模式对比与隔离本质

很多初学者容易将虚拟网桥和物理桥接混淆。libvirt 提供了四种截然不同的网络模式，它们的核心区别就在于数据包如何从虚拟网桥跨越到宿主物理网卡：

模式名称	XML 核心特征	二层/三层转发行为	宿主防火墙规则	虚拟机外部联网能力	生产适用场景
隔离网络 (Isolated)	无 `<forward>` 标签	仅网桥内部二层转发，不转发至宿主物理网卡	`FORWARD` 链默认 `DROP`，仅放行网桥内部流量	完全无法访问外部互联网	恶意代码沙箱、纯内网中间件测试、封闭实训
NAT 模式	`<forward mode='nat'/>`	宿主机内核执行三层路由与 IP 源地址伪装（MASQUERADE）	启用连接跟踪（conntrack）并修改报文源 IP	可主动访问互联网，外部无法直接主动访问虚拟机	个人开发环境、标准桌面虚机联网（libvirt 默认）
路由模式 (Route)	`<forward mode='route'/>`	仅执行三层标准 IP 路由，不执行 NAT 地址伪装	转发双向原始 IP，外部路由器需配置静态回包路由	具备双向直通能力（虚拟机拥有独立路由子网）	具备网络自治能力的企业私有云内网
物理桥接 (Bridge)	`<forward mode='bridge'/>`	虚拟网桥与宿主物理网卡直接绑定成同一二层交换机	旁路宿主三层网络栈，物理交换机直接可见虚机 MAC	虚拟机等同于机房的一台物理机，直接从机房 DHCP 领 IP	生产业务服务器、高吞吐虚拟化集群

libvirt 虚拟网络四大模式技术对比

(4) 缺失 `<forward>` 标签构建物理级隔离的内核机制

在 Linux 内核中，网络接口之间默认是不会自动互相转发数据包的。只有在开启了内核 IP 转发（net.ipv4.ip_forward=1）且防火墙允许的情况下，数据包才能从网卡 A 跨越到网卡 B。

当你在 libvirt 中创建没有 <forward> 标签的隔离网络时，libvirt 在宿主内核防火墙（iptables/nftables）中构建了一道坚不可摧的铁壁：

阻断跨网卡路由：在 FORWARD 过滤链中，宿主机只配置了一条放行规则：-i virbr-lab -o virbr-lab -j ACCEPT（仅允许从 virbr-lab 进、并且从 virbr-lab 出的流量通过）。
静默丢弃外发流量：当虚拟机尝试向外部 IP（如 1.1.1.1）发送数据包时，数据包从 vnet0 进入 virbr-lab。网桥发现这不是内部广播也不是内部单播，便上交给内核路由表；内核试图将其转发给宿主物理网卡（如 eth0），但防火墙检查规则时发现出接口是 eth0，不匹配内部放行规则，直接触发 DROP 策略，将数据包在接口边界静默销毁！
彻底去除 NAT：宿主机 POSTROUTING 链中不会包含任何针对 192.168.77.0/24 的 MASQUERADE 地址伪装规则，即使有数据包逃逸，外网路由器也无法识别私有网段并直接丢弃。

(5) 核心生活化心智模型总结

为了建立清晰持久的直观理解，请牢记以下两个生活化心智模型：

直观理解：Linux 网桥就像【房间里的独立多孔排插】｜ Linux 软件网桥 virbr-lab 就像在封闭房间中央放置的一个独立多孔排插。排插上插满了接入该房间各台虚拟机的网线，虚拟机之间可以通过多孔排插线速互联互通、交换数据。但核心关键在于：这个排插本身并没有插入房间墙壁上的外网光纤总插座，因此插在上面的设备自成闭环，任何数据都绝不可能流向外部互联网。
直观理解：宿主桥 IP 192.168.77.1 是【宿管大爷兼小卖部】｜ 宿主机自己也把一根虚拟网线插在了这个多孔排插上，持有 192.168.77.1 这个 IP，扮演着【宿管大爷兼小卖部】的关键角色：宿管大爷负责给进入房间的住户按序发放门牌号与登记花名册（内嵌 dnsmasq 运行 DHCP 分配与 DNS 解析服务）；大爷还可以随时进房间检查卫生与设备状态（宿主机运维管理与通信）。但大爷恪尽职守：他绝不当“黄牛”帮房间里的任何住户向小区外跑腿代寄包裹（不提供 NAT 与外网路由转发）。

下面的交互式动画组件直观演示了网桥创建、动态 TAP 端口接入、以太网数据帧在网桥内部的广播泛洪与单播定向转发过程，以及外网请求如何在网桥边界被有效阻断：

Linux 软件网桥核心原理libvirt 隔离网络架构

Linux 软件虚拟网桥与隔离网络拓扑 (virbr-lab)

直观观察宿主 Linux 软件网桥 (192.168.77.1)、动态 TAP 从属端口 (vnet0/vnet1) 及二层交换机帧转发与无外网出口隔离边界。

🌐

外部互联网 / 宿主上行物理网卡XML 中无 <forward> 节点，与公网物理完全隔断

隔离防护边界

🖥 宿主机 Ubuntu 26.04 (qemu:///system)宿主协议栈管理地址: 192.168.77.1/24

🔀Linux 软件虚拟网桥：virbr-lab● UP / RUNNING

STP: onDelay: 0DHCP: dnsmasq (192.168.77.1)

端口: vnet0

从属状态: 未挂载对端: svr01 (VirtIO)

二层 MAC 学习与交换引擎

⚡ 状态正常，待命转发

端口: vnet1

从属状态: 未挂载对端: desk01 (VirtIO)

📋 网桥实时 MAC 转发表 (FDB Table)动态记录每个 MAC 对应的出端口

MAC 地址绑定端口记录类型

52:54:00:77:00:01virbr-lab (Self)static

TAP 虚拟通道 (vnet0)

TAP 虚拟通道 (vnet1)

🖧svr01 (服务端来宾)

Ubuntu Server 26.04

虚拟网卡:VirtIO (ens3)

分配 IP:192.168.77.101/24

MAC 地址:52:54:00:aa:01:01

运行服务:Python HTTP :8080 (0.0.0.0)

💻desk01 (客户端来宾)

Ubuntu Desktop 26.04

虚拟网卡:VirtIO (enp1s0)

分配 IP:192.168.77.102/24

MAC 地址:52:54:00:bb:02:02

执行测试:ping & curl 测试客户端

第 1 阶段

步骤 1：创建软件虚拟网桥与宿主就绪

libvirt 定义并启动 lab-isolated，宿主内核生成 virbr-lab 软件网桥

💡 原理解析：

Linux 网桥（Bridge）在内核中模拟一台物理以太网交换机。libvirt 的虚拟网络 XML 决定了网桥的属性。因为 XML 中没有 <forward> 标签，宿主机不会在 iptables/nftables 中为它注入任何 SNAT/MASQUERADE 规则，形成了天然隔离。

🔍 网桥内部动作：

网桥处于 UP 状态，此时尚未挂载虚拟机端口。dnsmasq 守护进程绑定监听 192.168.77.1 提供 DHCP。

💻 对应 Linux 验证命令：$ virsh net-start lab-isolated && ip -4 -br addr show virbr-lab

8.2 任务二：将虚拟机接入隔离局域网——网卡接入与 DHCP 租约

虚拟网络创建完毕后，它如同一台放置在机房但尚未插线的物理交换机。本任务将把 svr01 与 desk01 的虚拟网卡接入这台虚拟交换机，观察 TAP 端口的动态挂载过程及 DHCP 租约的自动分发。

1. 【动手做】修改虚拟机网络接口并开机

首先在【宿主机终端 Host】中，确保 svr01 与 desk01 处于关机状态：

# 【宿主机终端 Host】检查两台虚拟机运行状态
virsh --connect qemu:///system domstate svr01
virsh --connect qemu:///system domstate desk01

图形化操作 (virt-manager)

打开 virt-manager 虚拟机管理器，双击 svr01 进入详情面板；
点击灯泡图标进入“虚拟硬件详情”，选中现有的 NIC（虚拟网卡）；
将“网络源”从 Virtual network 'default' : NAT 改为 Virtual network 'lab-isolated' : Isolated network；
设备型号保持 virtio，点击右下角“应用”保存；
对 desk01 重复相同操作，将网卡源接入 lab-isolated；
逐台启动 svr01 与 desk01。

命令行操作 (virsh)

也可以直接在【宿主机终端 Host】使用命令行热插拔或关机修改网络配置：

命令语法小贴士

命令中的 <( ... ) 是 Linux Bash 的临时进程替换（Process Substitution）语法，等价于在内存中生成一个临时虚拟文件传递给命令，无需手动创建保存临时文件，方便整段复制粘贴执行。

# 【宿主机终端 Host】1. 修改 svr01 的网络源为 lab-isolated
virsh --connect qemu:///system update-device svr01 <(cat <<EOF
<interface type='network'>
  <source network='lab-isolated'/>
  <model type='virtio'/>
</interface>
EOF
) --config

# 【宿主机终端 Host】2. 修改 desk01 的网络源为 lab-isolated（确保两台机器均切入隔离网）
virsh --connect qemu:///system update-device desk01 <(cat <<EOF
<interface type='network'>
  <source network='lab-isolated'/>
  <model type='virtio'/>
</interface>
EOF
) --config

# 【宿主机终端 Host】3. 逐台启动两台虚拟机
virsh --connect qemu:///system start svr01
virsh --connect qemu:///system start desk01

:::

2. 【看现象】查看动态 TAP 端口与 DHCP 租约

虚拟机开机后，在【宿主机终端 Host】执行以下命令查看挂载到 virbr-lab 网桥的从属端口：

# 【宿主机终端 Host】查看挂载到网桥的从属 TAP 端口
bridge link show master virbr-lab

预期输出展现动态生成的 vnet 端口：

12: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master virbr-lab state forwarding priority 32 cost 2
13: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master virbr-lab state forwarding priority 32 cost 2

接着在【宿主机终端 Host】查看 libvirt 为 lab-isolated 网络分配的 DHCP 租约表：

# 【宿主机终端 Host】查询隔离网络 DHCP 租约分配表
virsh --connect qemu:///system net-dhcp-leases lab-isolated

预期输出：

 Expiry Time           MAC address         Protocol   IP address          Hostname   Client ID or DUID
-------------------------------------------------------------------------------------------------------------------
 2026-08-17 15:30:12   52:54:00:aa:01:01   ipv4       192.168.77.101/24   svr01      01:52:54:00:aa:01:01
 2026-08-17 15:30:25   52:54:00:bb:02:02   ipv4       192.168.77.102/24   desk01     01:52:54:00:bb:02:02

虚拟机控制台登录与 IP 确认

确认虚拟机成功启动并分配租约后，需要登录虚拟机内部核验实际分配的网卡 IP。控制台登录有两种常用途径：

途径一（推荐零基础直观操作）：图形界面双击 在宿主机打开 virt-manager 界面，双击列表中的 svr01 或 desk01，即可打开图形控制台窗口直接进入登录界面。
途径二（进阶纯命令行）：virsh console 在【宿主机终端 Host】中直接接入对应虚拟机的串行字符控制台：
```
# 【宿主机终端 Host】登录 svr01 控制台（或换成 desk01）
virsh --connect qemu:///system console svr01
```

终端控制台登录与逃生指南

黑屏无响应？敲击 Enter 激活：执行 virsh console 连接成功后，屏幕往往只显示 Connected to domain... Escape character is ^] 便停住、无任何登录提示。这并不是死机，只需在键盘上敲击一到两次 Enter（回车键），即可唤醒并激活 Linux 系统的 login: 登录提示符。
逃生组合键 Ctrl + ] 必记：字符控制台会拦截所有常规快捷键。如果需要从虚拟机控制台退出、返回宿主机终端提示符，必须按下逃生组合键：按住 Ctrl 键的同时按下右方括号键 ]（即 Ctrl + ]）。请务必牢记此快捷键，避免出现“进得去、出不来”被困在控制台的情况！

登录两台虚拟机后，分别执行 ip -4 -br addr 确认各自网卡实际获取的 IP：

# 【服务端虚拟机 svr01】确认网卡获取到的 IP 地址
ip -4 -br addr
# 输出示例：ens3 UP 192.168.77.101/24

# 【客户端虚拟机 desk01】确认网卡获取到的 IP 地址
ip -4 -br addr
# 输出示例：enp1s0 UP 192.168.77.102/24

3. 【学原理与拓展】TAP 虚拟网络设备、I/O 数据通路与 dnsmasq 伴生架构

在物理世界中，网卡是一块插在主板 PCI 插槽上的实体硬件，网线是一根双绞线铜缆。那么在 KVM 虚拟机里，这一切是如何用纯软件代码呈现的呢？

(1) TAP vs TUN 虚拟设备的本质对比

Linux 内核提供了两种通用的虚拟网络接口驱动：TUN 与 TAP，它们常被并称为 TUN/TAP 驱动，但两者在网络协议栈中的工作层级截然不同：

特性维度	TUN 虚拟设备 (Tunnel)	TAP 虚拟设备 (Network Tap)
工作 OSI 层级	第三层（网络层）	第二层（数据链路层）
数据单元	纯 IP 数据报（IP Datagram，无以太网帧头）	完整以太网帧（Ethernet Frame，带 14 字节以太网帧头）
硬件仿真属性	点对点虚拟隧道（类似串行线路 PPP）	真实虚拟以太网网卡（仿真 PCI 网卡）
MAC 地址	无 MAC 地址，不支持二层协议（如 ARP）	拥有独立 MAC 地址，完全支持 ARP、广播与 VLAN
能否加入网桥	不能（网桥只接收二层以太网设备）	完美支持接入 Linux Bridge 或 Open vSwitch
经典工业应用	OpenVPN、WireGuard、点对点加密隧道	KVM / QEMU 虚拟机虚拟网卡、Docker 容器二层组网

TUN 与 TAP 虚拟设备特性对比

由此可见，KVM 虚拟机的虚拟网卡必须使用 TAP 设备！因为 Guest OS 内部运行的是通用的操作系统内核（Linux 或 Windows），操作系统始终认为自己插着一块真实的以太网卡，会在发包时严格按照以太网规范压入前导码、源 MAC、目标 MAC 和 EtherType；只有 TAP 设备能够承接完整的以太网帧并送入软件网桥。

(2) QEMU、VirtIO 与内核 TAP 的完整 I/O 数据通路

当虚拟机 svr01 向外发送一个数据包时，整个数据包在硬件与软件间的完整穿透路径如下：

Guest OS 用户态 ➔ 内核态：来宾系统内的应用程序（如 Python HTTP）生成数据，经过 Guest Linux 协议栈封装成 TCP 报文和 IP 报文，最后交由 VirtIO 网络驱动程序（virtio_net）封装成以太网帧。
Virtqueue 共享内存环：VirtIO 驱动将以太网帧的内存指针写入宿主机与虚拟机共享的环形缓冲区——Virtqueue（发送队列 TX Ring），并向虚拟 PCI 寄存器发送 VM-Exit 触发通知。
QEMU 用户态 ➔ 内核 TAP 设备：宿主机的 QEMU 进程从 Virtqueue 中取出以太网帧，调用宿主内核提供的 /dev/net/tun 字符设备接口，通过 write() 系统调用将以太网帧注入宿主机内核。
内核 TAP 端口 ➔ Linux 软件网桥：宿主机内核的 TAP 驱动模块（如 vnet0）收到数据帧，将其作为网络包上交给绑定的主设备——virbr-lab 软件网桥。
网桥 FDB 寻址 ➔ 目标 TAP 端口：virbr-lab 网桥查询 FDB 表，找到目标 MAC 对应的从属设备是 vnet1，直接将帧转发给 vnet1 的接收队列。
注入目标虚拟机：QEMU 进程或内核加速模块从 vnet1 读取数据帧，将其写入 desk01 的接收 Virtqueue（RX Ring），并向 desk01 发送虚拟中断，desk01 的内核驱动收到中断后开始解包，最终交由 curl 进程接收。

(3) 进阶工业技术：vhost-net 内核加速机制

细心的同学可能会发现：在上述经典路径中，以太网帧必须先从 Guest 内存进入宿主机用户态的 QEMU 进程，再通过系统调用写入宿主机内核 TAP 设备。这其中经历了两次用户态与内核态的上下文切换（Context Switch）和内存拷贝，在万兆（10Gbps）以上的高并发流量下，CPU 会把大量时间浪费在上下文切换上。

为了解决这一性能瓶颈，现代企业级 KVM 均标配了 vhost-net 内核加速驱动：

它在宿主机内核空间启动了一个轻量级内核线程（vhost-worker）；
该线程直接在内核空间（Ring 0）监听和消费 Virtqueue 共享环，收到帧后直接在内核内部交给 TAP 设备，彻底绕过了 QEMU 用户态中转！
相比传统 QEMU 模拟，vhost-net 将虚拟网络的数据面吞吐提升了 3~5 倍，网络延迟降低了 40% 以上。

(4) 动态 TAP 端口命名规则与生命周期状态机

很多同学会好奇：vnet0、vnet1 的名字到底是谁起的？为什么虚拟机关机后它就不见了？

生命周期状态机： TAP 端口的生命周期与 QEMU 虚拟机的生命周期完全绑定。 虚拟机开机 ➔ QEMU 打开 /dev/net/tun 并调用 ioctl(TUNSETIFF) 动态创建 TAP 设备（内核按可用编号自动命名为 vnet0、vnet1 等） ➔ libvirt 自动执行 br_add_if 将其挂载至 virbr-lab ➔ 网桥将其状态置为 forwarding。 虚拟机关机 ➔ QEMU 进程退出并关闭文件描述符 ➔ 内核自动从网桥摘除该端口并销毁设备。
编号漂移陷阱：端口编号取决于开机时间先后。如果先开 desk01 再开 svr01，则 desk01 抢先占用了 vnet0，而 svr01 分配到 vnet1。 工程铁律：在自动化运维脚本中，绝对不要写死 vnet0 或 vnet1 接口名！要查询具体虚拟机的动态端口，必须始终使用命令：
```
virsh domiflist svr01
```

(5) dnsmasq 伴生守护进程架构

当你在 libvirt 中启动 lab-isolated 网络时，libvirt 并不会凭空变出 DHCP 和 DNS 功能，而是在宿主机后台拉起了一个专属的轻量级伴生进程——dnsmasq。

在宿主机终端中运行以下命令，你可以亲眼看到这个专属于 lab-isolated 的守护进程：

# 【宿主机终端 Host】查看 lab-isolated 专属的 dnsmasq 进程
ps aux | grep dnsmasq | grep 'virbr-lab'

该进程由系统级管理，被限定绑定在 virbr-lab 接口的 IP 192.168.77.1 上，监听 UDP 67（DHCP 服务）和 UDP 53（DNS 解析）；
它从 XML 中读取地址池 192.168.77.100~.199；
当新虚拟机开机发起 DHCP Discover 广播时，dnsmasq 负责签发租约，并将分配记录实时写入宿主机磁盘文件：
```
/var/lib/libvirt/dnsmasq/lab-isolated.leases
```
这也就是为什么执行 virsh net-dhcp-leases lab-isolated 能够秒级查出各虚拟机分配到的 MAC 与 IP 对应关系。

8.3 任务三：双机互通与隔离边界双向验证——从 ICMP 到 HTTP 服务

网络连通性的终极目标是服务交付。本任务将在 svr01 上部署一个无外部依赖的轻量 Python HTTP 实验服务，从 desk01 验证局域网全双工通信，并同时验证跨越公网时网络边界的绝对阻断。

1. 【动手做】部署服务与连通性验证

直观理解：监听 0.0.0.0 vs 127.0.0.1 是【大开正门迎客 vs 关起房门自嗨】｜ 启动网络服务时，绑定地址的选择至关重要。如果将服务绑定到 127.0.0.1（本地回环地址），就好比服务人员关起自家房门“自嗨”，外部任何人无论如何也敲不开门，仅允许虚拟机自身访问；而指定 --bind 0.0.0.0 则是“大开所有正门迎客”，通知内核在所有可用网卡接口上全面监听，隔离局域网内的邻居（如 desk01）与宿主机便都能畅通访问。

在【服务端虚拟机 svr01】内，创建实验目录并启动基于 Python 的轻量 HTTP 服务（监听 0.0.0.0:8080）：

# 【服务端虚拟机 svr01】创建测试网页并后台启动 HTTP 服务
mkdir -p ~/web-lab
echo "Starship isolated lab is reachable." > ~/web-lab/index.html

# 使用 nohup 重定向日志，并在后台常驻运行
nohup python3 -m http.server 8080 --bind 0.0.0.0 --directory ~/web-lab > ~/web-lab/http.log 2>&1 &

终端防卡死与后台运行机制解析

末尾 & 的含义：指示 Shell 将该命令置于后台（Background）执行，立即交还终端命令行提示符，允许继续输入后续命令。
nohup 与 > .../http.log 2>&1 的作用：将服务的标准输出（stdout）和错误输出（stderr）统一重定向到日志文件中，防止后续网页请求访问日志持续刷屏，污染打断你的终端输入界面。
万一漏敲 & 卡在前台怎么办？：如果不小心漏掉了末尾的 &，Python 服务将独占前台，终端似乎“卡死”。千万不要直接关闭终端！ 此时只需使用以下应急急救快捷键：
- 按下 Ctrl + Z：向当前前台进程发送 SIGTSTP 信号，强制将前台卡住的任务挂起（暂停）；
- 输入 bg 并回车：将刚才被挂起的任务转入后台继续运行（Background），终端提示符立刻恢复自由！

在【服务端虚拟机 svr01】内确认端口监听状态：

# 【服务端虚拟机 svr01】确认 8080 端口处于 LISTEN 监听状态
ss -lntp | grep ':8080'

预期输出应显示 0.0.0.0:8080 处于 LISTEN 状态。

⚠️ 动态 IP 替换提示

下文命令中的 192.168.77.101 为示例 IP。请务必替换为你在 8.2 节中实际获取到的 svr01 真实 IP（例如若你的 svr01 分配到的是 192.168.77.105，请将命令中的 IP 同步改为 192.168.77.105），切勿盲目直接复制！

切换到【客户端虚拟机 desk01】，执行 ICMP 探测与 HTTP 业务拉取：

# 【客户端虚拟机 desk01】1. 测试与服务端的 ICMP 双向连通性（注意替换 svr01 真实 IP）
ping -c 3 192.168.77.101

# 【客户端虚拟机 desk01】2. 发起 HTTP GET 请求获取网页内容
curl -i --connect-timeout 3 http://192.168.77.101:8080/

# 【客户端虚拟机 desk01】3. 查看本地 ARP 邻居缓存表
ip neigh show 192.168.77.101

2. 【看现象】内网成功响应与外网阻断对比

在【客户端虚拟机 desk01】执行上述命令后，观察终端输出：

# ping 输出正常收到应答
64 bytes from 192.168.77.101: icmp_seq=1 ttl=64 time=0.342 ms
64 bytes from 192.168.77.101: icmp_seq=2 ttl=64 time=0.285 ms
3 packets transmitted, 3 received, 0% packet loss

# curl 成功返回网页标头与内容
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.12.3
Date: Mon, 17 Aug 2026 14:30:12 GMT
Content-type: text/html
Content-Length: 36

Starship isolated lab is reachable.

# 邻居表正确记录对应 MAC
192.168.77.101 dev enp1s0 lladdr 52:54:00:aa:01:01 REACHABLE

接下来在【客户端虚拟机 desk01】中测试向外部公网 IP（如 1.1.1.1 或 8.8.8.8）发送请求：

# 【客户端虚拟机 desk01】测试外网公网 IP 访问（验证隔离边界阻断）
ping -c 2 -W 1 1.1.1.1
curl -i --connect-timeout 2 http://1.1.1.1/

预期输出：

ping: connect: Network is unreachable
# 或者
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss
curl: (7) Failed to connect to 1.1.1.1: Network is unreachable

外网阻断现象解读｜
若看到 Network is unreachable：属于最标准的纯隔离现象（内核无默认网关，本地直接拦截阻断）；
若看到 100% packet loss：则是宿主机防火墙在接口处直接丢弃数据包。
两者皆证明隔离铁壁成功生效，无需担心。

3. 【学原理与拓展】操作系统路由决策与企业级安全沙箱架构

通过上述实验，我们观察到了极其鲜明的现象对比：虚拟机之间 ping 和 curl 极其顺畅，时延甚至低于 0.5 毫秒；但向外部互联网发起的请求全部瞬间报错 Network is unreachable 或超时丢包。这背后的计算机网络原理是什么？

(1) 操作系统网络栈的路由决策机制（Routing Decision）

当你在 desk01 终端敲入 ping 1.1.1.1 时，Linux 内核网络栈在底层经历了以下精密的路由查找逻辑：

查阅本地路由表（FIB 路由信息库）：在虚拟机内部执行 ip route，你会发现类似如下的路由表输出：
```
192.168.77.0/24 dev enp1s0 proto kernel scope link src 192.168.77.102
```
关键发现：在这张路由表中，只有一条通往 192.168.77.0/24 网段的直连路由（Scope Link），完全没有任何 default via ...（默认网关 0.0.0.0/0）条目！
本地协议栈直接阻断（Fail Fast）：
- 当目标 IP 是 192.168.77.101 时，内核比对前 24 位子网掩码，发现命中 192.168.77.0/24 直连路由，立即封装成以太网帧从 enp1s0 网卡发出；
- 当目标 IP 是 1.1.1.1 时，内核逐行扫描路由表，没有任何一条子网能匹配 1.1.1.1，同时又没有配置默认网关（Default Gateway）兜底。此时，内核网络栈在应用层发包前就直接做出裁决：抛出错误码 ENETUNREACH，上层应用直接输出 Network is unreachable！
- 这意味着：没有默认网关时，发往外网的数据包根本连虚拟网卡都没机会离开，直接被虚拟机本地内核拒之门外！
即使伪造网关也无法逃逸：如果有安全攻击者在虚拟机内手动执行 sudo ip route add default via 192.168.77.1，强行把宿主机网桥设为网关，数据包能送达外网吗？ 答案依然是绝不可能！ 当外网数据包被强行发到宿主机网桥 virbr-lab 后，宿主机内核会介入处理：宿主机检查针对 virbr-lab 的转发策略，前面在 8.1 节我们讲过，libvirt 在防火墙 FORWARD 链配置了规则，任何由 virbr-lab 进、试图从其他物理网卡出的流量都会命中默认的 DROP 策略，数据包在宿主机内核直接被静默粉碎！

(2) 宿主机与虚拟机双向通信的直连路由机制

在【宿主机终端 Host】中执行 ping 192.168.77.101 或 curl http://192.168.77.101:8080/，你会发现宿主机完全可以访问隔离网内的虚拟机。

很多同学会产生直觉误区：“既然叫隔离网络，为什么宿主机能看见虚拟机？”

隔离网络的核心定义是：隔离虚拟机与外部不可信互联网（External World）；
宿主机本身是虚拟化平台的管理者，它在 virbr-lab 上持有 192.168.77.1 节点。在宿主机的路由表中，天然拥有一条到达 192.168.77.0/24 的直连路由；
宿主机访问虚拟机属于同一二层网桥内的内部通信。这种设计使得管理员能够安全地对虚拟机进行 SSH 运维、配置下发和监控采集，而无需让虚拟机暴露在外部互联网中。

(3) 隔离局域网的三大企业级工业应用场景

隔离网络绝非仅用于课堂练习，在现代企业云计算与网络安全领域，它是不可或缺的核心基础设施：

恶意软件与勒索病毒分析沙箱（Malware Analysis Sandbox）：安全实验室在分析未知可疑样本或勒索病毒时，必须在虚拟沙箱中运行样本以观察其行为。样本极有可能包含外联木马（C2 通道）或局域网横向蠕虫（如利用 SMB 永恒之蓝漏洞传播）。如果将病毒放在常规网络中，它会瞬间窃取数据外发，或瘫痪整个公司局域网。而将沙箱置入纯隔离网络，恶意软件即使疯狂扫描或外发，所有网络流量也只能在孤岛内打转，彻底阻断了任何破坏与泄密通道。
多租户安全隔离与零信任架构（VPC & Zero Trust）：在公有云数据中心（如 AWS、阿里云、腾讯云）中，不同企业的虚拟机运行在同一台物理宿主机上。利用隔离虚拟交换网络，可以确保 A 公司的所有虚拟机流量在二层/三层对 B 公司完全物理级不可见，彻底消除通过混杂模式窃听相邻虚机数据或伪造 ARP 欺骗攻击的可能性。
金融/核心系统离线容灾压测：在银行业务上线前，工程师需要模拟高可用双机热备（如 Keepalived 漂移 VIP）和数据库主从高并发同步压测。这类压测流量巨大且包含高度敏感的模拟金融数据，使用隔离网络可以在逼真模拟生产双机交互的同时，确保压测流量绝不溢出到办公网络，避免造成网络风暴或真实业务中断。

8.4 任务四：网络流量抓包与分层故障排查决策

虚拟网络通信全靠内核软转发，看似抽象神秘。然而在 Linux 宿主机上，我们可以像抓取物理网络光纤一样，使用 tcpdump 直接监听 virbr-lab 网桥，将每一个流经网桥的数据帧精准捕获。

1. 【动手做】宿主机抓包实录

在【宿主机终端 Host】中，使用 tcpdump 监听 virbr-lab 接口，设置过滤条件并捕获 15 个数据包：

# 【宿主机终端 Host】启动 tcpdump 监听 virbr-lab 网桥
sudo tcpdump -nn -i virbr-lab -c 15 'arp or icmp or (tcp port 8080)'

⚠️ 动态 IP 替换提示

下文命令中的 192.168.77.101 为示例 IP，请务必替换为你在 8.2 节中实际获取到的 svr01 真实 IP。

命令启动处于等待监听状态后，切换到【客户端虚拟机 desk01】终端，先清空 ARP 缓存以触发二层寻址广播，再执行探测与网页请求：

# 【客户端虚拟机 desk01】1. 清空本地 ARP 邻居缓存，强制触发 ARP 广播寻址
sudo ip neigh flush all

# 【客户端虚拟机 desk01】2. 发起 3 次 ICMP 探测（生成 ARP 广播/单播 2 包 + ICMP 6 包）
ping -c 3 192.168.77.101

# 【客户端虚拟机 desk01】3. 发起 HTTP 请求（生成 TCP 三次握手 3 包 + HTTP 请求/响应/确认包 4~6 包）
curl http://192.168.77.101:8080/

回到【宿主机终端 Host】，观察 tcpdump 自动捕获满 15 个包并退出输出的控制台文本。

保姆级提示：抓包未自动退出怎么办？

命令中的 -c 15 表示“抓取满 15 个符合条件的数据包后自动终止退出”。若网络偶发丢包或 HTTP 数据包合并导致捕获总数未达 15 个，宿主机终端可能会持续等待。此时无需慌张，在【宿主机终端 Host】直接敲击快捷键 Ctrl + C 即可安全强制终止抓包，之前已捕获到的完整数据报文依然会完整保留并打印在屏幕上，不影响实验结果与截图记录！

2. 【看现象】逐层报文字段解析

捕获到的输出真实呈现了网络通信从二层到七层的完整协议演进流程：

# 1. ARP 阶段：广播询问（拿大喇叭喊）与单播应答
14:35:01.102310 ARP, Request who-has 192.168.77.101 tell 192.168.77.102, length 28
14:35:01.102550 ARP, Reply 192.168.77.101 is-at 52:54:00:aa:01:01, length 28

# 2. ICMP 阶段：Echo Request 与 Echo Reply
14:35:01.103100 IP 192.168.77.102 > 192.168.77.101: ICMP echo request, id 4102, seq 1, length 64
14:35:01.103320 IP 192.168.77.101 > 192.168.77.102: ICMP echo reply, id 4102, seq 1, length 64

# 3. TCP 握手阶段：三次握手建立连接
14:35:02.201100 IP 192.168.77.102.49120 > 192.168.77.101.8080: Flags [S], seq 28192019, win 64240, length 0
14:35:02.201320 IP 192.168.77.101.8080 > 192.168.77.102.49120: Flags [S.], seq 91827102, ack 28192020, win 65160, length 0
14:35:02.201410 IP 192.168.77.102.49120 > 192.168.77.101.8080: Flags [.], ack 1, win 64240, length 0

# 4. HTTP 数据交互：请求与应答推送
14:35:02.202100 IP 192.168.77.102.49120 > 192.168.77.101.8080: Flags [P.], seq 1:82, ack 1, length 81: HTTP: GET / HTTP/1.1
14:35:02.203200 IP 192.168.77.101.8080 > 192.168.77.102.49120: Flags [P.], seq 1:198, ack 82, length 197: HTTP: HTTP/1.0 200 OK

3. 【学原理与拓展】网络抓包实录深度剖析与五层排错科学体系

很多初学者只知道 tcpdump 会刷出一行行日志，却不知道屏幕上跳动的每一个字母和标志位代表什么含义。下面我们对上述捕获的四个经典阶段进行深入字段拆解。

(1) 四阶段网络通信报文逐层拆解

第一阶段：二层 ARP 寻址报文（以太网地址解析协议）

报文 1 行析：ARP, Request who-has 192.168.77.101 tell 192.168.77.102, length 28
- 直观理解【大教室里拿大喇叭喊人】：desk01（192.168.77.102）在清空 ARP 缓存后，只知道目标 IP 是 192.168.77.101，但以太网二层转发必须依赖物理 MAC 地址。它不知道该把网线信号发给谁，于是向全班广播高喊（以太网目标 MAC 为全 F：FF:FF:FF:FF:FF:FF）。
- Opcode（操作码）：Request（代码 1），表示请求解析目标 MAC 地址。
报文 2 行析：ARP, Reply 192.168.77.101 is-at 52:54:00:aa:01:01, length 28
- 只有真正持有该 IP 的 svr01 做出应答（Opcode 2: Reply）。应答帧是精准单播给 desk01 的，告知其真实物理工位是 52:54:00:aa:01:01。
- 随后双方在各自操作系统的内核中更新 ARP 邻居表（ip neigh），在接下来 30~60 秒内无需再次广播，实现线速通信。

第二阶段：三层 ICMP 报文（互联网控制消息协议）

报文 3 行析：IP 192.168.77.102 > 192.168.77.101: ICMP echo request, id 4102, seq 1, length 64
- Type 8 Code 0：标准的 ICMP Echo Request（回显请求）。seq 1 表示这是当前 ping 会话的第一个探测包。
报文 4 行析：IP 192.168.77.101 > 192.168.77.102: ICMP echo reply, id 4102, seq 1, length 64
- Type 0 Code 0：目标主机内核协议栈收到请求后，原样打包并返回 ICMP Echo Reply（回显应答）。这证明两台虚拟机之间的三层 IP 协议栈双向可达。

第三阶段：四层 TCP 三次握手报文（传输控制协议）

在 HTTP 网页传输前，客户端与服务端必须先建立可靠的面向连接的 TCP 会话：

第一次握手（SYN 包）： IP 192.168.77.102.49120 > 192.168.77.101.8080: Flags [S], seq 28192019, win 64240
- 客户端随机挑选临时端口 49120，向服务端的 8080 发起连接请求；
- Flags [S]：SYN 标志位置 1，表示同步序列号；
- seq 28192019：客户端随机生成的初始序列号（ISN）；
- win 64240：滑动窗口大小，通知对端本机的最大接收缓冲能力。
第二次握手（SYN-ACK 包）： IP 192.168.77.101.8080 > 192.168.77.102.49120: Flags [S.], seq 91827102, ack 28192020
- Flags [S.]：SYN 与 ACK 标志位同时置 1；
- seq 91827102：服务端随机生成的初始序列号；
- ack 28192020：确认号，等于客户端序列号加 1（ $28192019 + 1$ ），表示“已收到你的 SYN，期待你的下一条报文”。
第三次握手（ACK 包）： IP 192.168.77.102.49120 > 192.168.77.101.8080: Flags [.], ack 1
- Flags [.]：仅 ACK 标志位置 1，连接正式确立，双方状态迁移为 ESTABLISHED。

第四阶段：七层 HTTP 数据传输报文（应用层协议）

Flags [P.]：PUSH 与 ACK 标志。PUSH 标志指示接收端操作系统无需等待缓冲区填满，立刻将此数据推交上层应用程序（Python HTTP 服务）；
HTTP: GET / HTTP/1.1：客户端发起的应用层标准 HTTP 请求；
HTTP: HTTP/1.0 200 OK：服务端返回的网页响应正文。

(2) 五层排错科学决策模型（Layered Troubleshooting Methodology）

在实际云计算与系统运维工作中，当出现“网页无法打开”或“服务调用超时”时，新手往往会盲目重启虚拟机、重装服务甚至推倒重建网络。而成熟的工程师会严格遵循自底向上的五层排错决策模型，绝不凭空猜测。

排查层次	核心关注点	诊断命令与观察点	典型故障表现与错误原文	底层根本诱因	标准工程修复手段
第 1 层：物理与虚拟链路层 (Link)	虚拟网卡与 TAP 接口物理连接状态	`virsh domif-getlink <vm> <vnet>` 或宿主 `ip link show`	提示 `State: down` 或宿主端口显示 `NO-CARRIER`	虚拟网线被管理员断开，或虚拟网卡未正确关联到虚拟机	执行 `virsh domif-setlink <vm> <vnet> up` 重新闭合虚拟接口链路
第 2 层：二层地址解析层 (ARP)	IP 到 MAC 的二层硬件地址解析	来宾执行 `ip neigh` 或宿主 `bridge fdb show`	条目显示 `FAILED` 或 `INCOMPLETE`	两台主机 IP 不在同一二层广播域、子网掩码错误或对端关机	核验 `net-dhcp-leases`，检查子网掩码一致性，必要时执行 `ip neigh flush all`
第 3 层：三层路由寻址层 (Routing)	本地内核协议栈三层可达性与网关	来宾执行 `ip route get <目标IP>`	输出 `RTNETLINK answers: Network is unreachable`	路由表缺失目标子网路由，且系统无默认网关可用	检查 `systemd-networkd` 或 Netplan 配置，确保正确获取局域网子网路由
第 4 层：四层防火墙与安全策略 (Firewall)	端口访问控制与安全策略丢包	来宾执行 `sudo ufw status` 或 `sudo iptables -S`	ping 正常，但 curl 提示 `Connection timed out` 挂起	服务端开启了防火墙，ICMP 被允许，但 TCP 端口规则被配置为 `DROP` 丢弃	执行 `sudo ufw allow 8080/tcp` 放行目标服务端口，或调整 `iptables` 入站规则
第 5/7 层：应用进程与服务监听 (Service)	后台进程是否运行及绑定的监听地址	服务端执行 `ss -lntp \| grep :8080`	ping 正常，但 curl 秒报 `curl: (7) Failed: Connection refused`	进程根本未运行；或者错误绑定了 `127.0.0.1` 本地回环，拒绝外部网络连接	启动服务并确保加上 `--bind 0.0.0.0`，使服务在所有网络接口上全面监听

网络故障五层分层排错决策表

下面的交互式组件展示了四阶段报文的详细字段结构，并提供了一个可交互的五层排错决策树模拟器。你可以自由切换故障案例，体验不同层级断点对应的终端报错特征与排错逻辑：

网络流量抓包实录五层排错决策模型

网络流量逐层流向与分层排错决策树

从以太网数据包逐层封装流向（ARP ➔ ICMP ➔ TCP 握手 ➔ HTTP 8080），到“网卡—地址—路由—防火墙—监听端口”分层排错决策树的交互推演。

💻

desk01192.168.77.10252:54:00:bb:02:02

ARPL2 (数据链路层)

desk01 ➔ virbr-lab ➔ svr01 (广播请求) | svr01 ➔ desk01 (单播应答)

🖧

svr01192.168.77.10152:54:00:aa:01:01

L2 (数据链路层)

阶段一：ARP 广播地址解析 (Address Resolution)

ARP 协议报文详情

二层源 MAC (Eth Src):52:54:00:bb:02:02 (desk01)

二层目标 MAC (Eth Dst):ff:ff:ff:ff:ff:ff (以太网广播) / 回包: 52:54:00:bb:02:02

三/四层源 (IP/Port):192.168.77.102

三/四层目标 (IP/Port):192.168.77.101

载荷信息 (Payload):Opcode: Request (1) -> Opcode: Reply (2) [MAC解析成功，写入ip neigh邻居表]

📡 宿主机抓包实时输出 (tcpdump -nn -i virbr-lab)

14:25:10.102340 ARP, Request who-has 192.168.77.101 tell 192.168.77.102, length 28
14:25:10.102590 ARP, Reply 192.168.77.101 is-at 52:54:00:aa:01:01, length 28

⚡ 排错判断口径：若执行 ip neigh 显示 FAILED 或 INCOMPLETE，说明二层未通（网卡未接、Link Down 或 IP 根本不存在）。

8.5 常见问题排错矩阵

故障现象	发生层次	根本诱因	快速诊断命令	推荐解决方案
`net-start` 报错 `bridge virbr-lab exists`	宿主系统层	系统内核遗留了未正常释放的同名网桥	`ip link show virbr-lab`	执行 `sudo ip link delete virbr-lab` 清理后再次 `net-start`
虚拟机开机后未分配到 IP 地址	链路/DHCP层	虚拟机网卡未接入 `lab-isolated` 或 Link 处于 down	`virsh domiflist <vm>` 及 `virsh domif-getlink`	检查网络源为 `lab-isolated` 并确保 link 为 up；重启虚拟机内 `systemd-networkd`
`bridge link` 查不到 `vnet` 从属端口	虚拟化层	对应虚拟机尚未开机或网卡配置错误	`virsh list --all`	确认对应虚拟机处于 `running` 状态，vnet 端口随 QEMU 进程动态生成
ping 成功但 curl 报 `Connection refused`	应用层	Python HTTP 服务未运行，或仅绑定了 `127.0.0.1`	`ss -lntp \| grep :8080`	在服务端重新启动服务，明确指定 `--bind 0.0.0.0` 允许跨机监听
ping 成功、端口监听正常，但 curl 超时挂起	防火墙层	服务端开启了 `ufw` 或 `nftables` 且未放行 8080	`sudo ufw status verbose` 或 `sudo nft list ruleset`	执行 `sudo ufw allow 8080/tcp` 或调整防火墙入站过滤策略
虚拟机仍可 ping 通公网 IP (1.1.1.1)	网络隔离层	虚拟机上还挂接了属于 `default` 网络的第二张网卡	`virsh domiflist <vm>` 与虚拟机内 `ip route`	移除 `default` NAT 虚拟网卡，确保虚拟机只保留 `lab-isolated` 单一网卡

Ubuntu 26.04 虚拟网络常见问题与排错方案

8.6 提交内容

完成本实验所有任务后，请整理并提交以下 4 张必交终端操作截图：

截图一：隔离网络定义与网桥 IP 状态
在【宿主机终端 Host】中执行并截屏包含完整提示符的输出：
```
virsh --connect qemu:///system net-list --all
ip -4 -br addr show virbr-lab
```
验证要点： lab-isolated 状态为 active 且 autostart 为 yes；virbr-lab 成功分配 192.168.77.1/24 地址。
截图二：动态端口挂载与 DHCP 租约分配
在【宿主机终端 Host】中执行并截屏包含完整提示符的输出：
```
bridge link show master virbr-lab
virsh --connect qemu:///system net-dhcp-leases lab-isolated
```
验证要点： 清晰显示 vnet0 和 vnet1 处于 forwarding 状态；租约表记录了两台虚拟机不同的 MAC 与 IP（192.168.77.100~.199 范围内）。
截图三：客户端服务访问与外网隔离双向验证
在【客户端虚拟机 desk01】终端中执行并截屏包含完整提示符的输出：
```
ping -c 3 192.168.77.101
curl -i http://192.168.77.101:8080/
ping -c 2 -W 1 1.1.1.1
```
验证要点： 内网 ping 响应 0% 丢包；curl 成功输出 HTTP/1.0 200 OK 与实验网页正文；外网 ping 提示 Network is unreachable 或 100% 丢包，证明隔离边界生效。
截图四：宿主机网桥抓包证据
在【宿主机终端 Host】执行 sudo tcpdump -nn -i virbr-lab -c 15 并在【客户端虚拟机 desk01】触发通信后的抓包截屏： 验证要点： 截图须清晰展现 ARP 广播解析、ICMP Echo 或 TCP 三次握手 Flags [S] / [S.] / [.] 的报文行。

本章小结

本章围绕“组建看不见的实验室隔离局域网”展开，系统掌握了基于 Linux 内核与 libvirt 的虚拟网络技术与深层网络架构：

Linux 软件虚拟网桥本质：virbr-lab 是由 Linux Bridge 内核模块实现的纯软件二层以太网交换机，通过维护 FDB 转发哈希表，实现以太网帧的 MAC 地址自主学习、广播泛洪与已知单播线速转发。
STP 生成树防环机制：STP 能够阻断网络物理或逻辑环路，防止广播风暴与 MAC 震荡；在纯虚拟网络中设置 delay='0' 能够消灭 15~30 秒的转发延迟等待，实现虚拟机开机秒级联网。
隔离网络配置关键与内核阻断：libvirt Network XML 中不包含 <forward> 标签即为纯隔离网络。宿主机在防火墙 FORWARD 链默认实施 DROP 策略，彻底杜绝跨物理网卡的数据转发与 NAT 伪装，构建物理级的私网安全屏障。
TAP 二层虚拟设备与数据通道：KVM 依赖工作在 OSI 第二层的 TAP 接口（vnetX）仿真真实以太网卡；借助 Virtqueue 共享环与企业级 vhost-net 内核加速，大幅降低上下文切换开销，实现万兆线速数据转发。
网络报文逐层解析：从 ARP 广播寻址获取目标 MAC，到 ICMP 网络层可达性探测，再到 TCP 传输层三次握手建连，最后到 HTTP 应用层数据交互，清晰展现各层协议如何紧密协同工作。
五层分层排错工程思维：遇网络异常时，从底层虚拟链路（Link）向上逐层递推至 ARP、路由、防火墙规则与监听端口（0.0.0.0 绑定），杜绝盲目猜测与重启，建立现代工程师的科学排错思维。