鸟哥私房菜 - 第六章、局域网路整体环境规划

最近更新时间： 2023/11/05

建置局域网路环境，需要大量的 PC 设备，以及集中网络线的 switch 还有一堆网络线，还有最重要的...空间与空调～我们没这么多钱啦！所以全部都在一部 KVM host 里面来达成这些环境的建置！当然啦，所有的硬件将全部都是假的！虽然是虚拟的，但是这些硬件设备该仿真放置在哪里？代表的是哪个位置？基本上，我们应该要知道才行！所以，就让我们来搭建一下局域网路吧！

6.1、WiFi 无线 AP 的仿真建置：使用 iw 修改信道时脉
6.2、产生新的 switch (bridge 桥接器)
6.3、设计 Master 服务器硬件系统
- 6.3.1、进行 PCI passthrough 设置
- 6.3.2、处理网卡与 birdge 的对应等任务
6.4、设计用户端/服务器端环境硬件系统
6.5、参考数据

6.1、WiFi 无线 AP 的仿真建置

其实局域网路当中，很重要的一个部份就是无线网络，毕竟目前我们使用的手机、平板、笔记本电脑等移动式设备，大部分都使用 WiFi 无线网络。而为了无线网络，通常我们是需要一个无线访问点 (Access Point, AP)，让移动式设备可以认证连接到 AP，并从 AP 处取得适当的网络参数来上网。目前 (2023) 买一个便宜 AP，就可以用得很开心！只是，如果需要额外控制，就得要登录 AP 去调整！而且有的调整也不是这么简单～加上我们还没有讨论防火墙与 port mapping 等 NAT 技术，所以，复杂设计一个 AP 在现阶段似乎没什么道理！

不过，我们总是有可能需要用到 AP 的，所以，这一小节，我们先用 NetworkManager 的管理方式，很方便快速的帮我们把这颗原本的 USB WiFi 用户端的设备，改装成为 AP 来提供目前局域网路内的无线连接。要注意的是，NetworkManager 可能没有很细部的参数来设计速度标准！例如它就无法选择设置为 802.11n / 802.11ac 等，而只能设计 5GHz 或 2.4GHz 这种频段的选择，因此，如果速度没办法达到满意的程度，也只能将就了！毕竟 NetworkManager 设计 AP 真的很简单！

硬件检查项目

并非所有的 WiFi 终端设备都可以成为 AP 模式的！我们得要来检查一下才行。另外，要检测基础参数，也需要这个 WiFi 先连上其他的 AP 来测试！上一章节鸟哥将 USB WiFi 设备链接到 2.4GHz 频段的 AP 上，后来有链接到 5GHz 的频段，速度性能似乎比较好！所以，底下先来启动新的 5GHz 的连接：

[root@cloud ~]# nmcli connection
NAME        UUID                                  TYPE      DEVICE
eno1        24199355-b3a4-3f4d-bd6e-65be1085a499  ethernet  eno1
lo          08244c39-77bc-412e-a6dd-a632a2d7688d  loopback  lo
templan     58c9ba71-95b9-4b2a-950e-81a83891ebb0  bridge    templan
vnet0       a0abae67-eadc-4632-84ee-0c17311b6678  tun       vnet0
vbird-2.4G  51a27365-95b0-48d9-8048-390646be3ff2  wifi      --
vbird-5G    7a3262f9-d61e-4ac9-9830-6724a811166a  wifi      --

[root@cloud ~]# nmcli connection up vbird-5G
# 链接到 5GHz 流程好像都会稍微慢一些...连上要几秒钟的时间吧！

[root@cloud ~]# nmcli
....
wlp0s20f0u5: connected to vbird-5G
        "ASUSTek Computer AC51 802.11a/b/g/n/ac"          <==这个设备的产品名称
        wifi (mt76x0u), C8:7F:54:8D:98:68, hw, mtu 1500   <==使用的驱动程序与 MAC 地址
        inet4 192.168.0.116/24                            <==目前的 IP 地址
        route4 192.168.0.0/24 metric 600                  <==目前的缺省路由
....

连上线之后，来看看这个连接目前的状况，使用 iw 这个指令来查找，要注意喔！底下的某些 link 功能，是你的系统确实有连上 WiFi AP 才会有信号喔～否则只会显示没有连接而已。

[root@cloud ~]# iw dev
phy#0
   Interface wlp0s20f0u5
      ifindex 11
      wdev 0x1
      addr c8:7f:54:8d:98:68
      type managed
      channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz
      txpower 19.00 dBm
      multicast TXQ:
          qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes   tx-packets
          0       0       37      0       0       0       0       6004       39

基本上，我们可以看到硬件端口口为 phy0，设备名称为 wlp0s20f0u5，网卡卡号可能会随时更新！这点相当有趣！因为我们有连上 AP，所以这边会有连接的信道号码与频率，信道的数据操作速率 (80MHz) 等等。然后最大功率 (twpower) 大概在 19 dBm 左右，下方则是数据传输的现况。接下来，让我们来看看目前无线网络连接的情况：

[root@cloud ~]# iw dev wlp0s20f0u5 link
Connected to e8:cc:18:f1:bf:fa (on wlp0s20f0u5)
        SSID: vbird-5G
        freq: 5745
        RX: 1289619 bytes (8839 packets)
        TX: 4861 bytes (115 packets)
        signal: -50 dBm
        rx bitrate: 390.0 MBit/s VHT-MCS 9 80MHz VHT-NSS 1
        tx bitrate: 6.0 MBit/s

        bss flags:      short-preamble short-slot-time
        dtim period:    1
        beacon int:     100

[root@cloud ~]# iw dev wlp0s20f0u5 station dump

上面可以看到这次连接的情境，包括 SSID 以及使用的无线频段与实际传输的速度及相关的传输参数等。由于我们目前有两个网络界面，分别是有线网络与无线网络，有线的效率较佳，所以无线就很少被用到！因此上头的 rx/tx bitrate 会一直持续不断的变化喔！不是永远都是固定值！不过，华硕这颗 USB 竟然真的可以跑到 390Mbps 的速度，也确实够快了！使用『 iw dev wlp0s20f0u5 station dump 』也可以取得相似的内容！详细数据就请自行查阅你的环境！接下来，让我们看看这张 USB WiFi 网卡的支持度吧！

[root@cloud ~]# iw list
Wiphy phy0
        wiphy index: 0
        max # scan SSIDs: 4
        ....
        Device supports RSN-IBSS.
        Device supports AP-side u-APSD.
        Device supports T-DLS.
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP-128 (00-0f-ac:4)
                * CCMP-256 (00-0f-ac:10)
                ....
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * P2P-client
                 * P2P-GO
        Band 1:      <==第一个频段，大概是 2.4GHz 的频段说明
                Capabilities: 0x17e
                ....
                Bitrates (non-HT):
                        * 1.0 Mbps (short preamble supported)
                        * 2.0 Mbps (short preamble supported)
                        ....
                        * 54.0 Mbps
                Frequencies:
                        * 2412 MHz [1] (16.0 dBm)
                        * 2417 MHz [2] (16.0 dBm)
                        ....
                        * 2484 MHz [14] (disabled)
        Band 2:      <==第二个频段，大概是 5GHz 的频段说明
                Capabilities: 0x17e
                        HT20/HT40
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                ....
                VHT Capabilities (0x31800120):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                        short GI (80 MHz)
                        RX antenna pattern consistency
                        TX antenna pattern consistency
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: not supported
                        ....
                Bitrates (non-HT):
                        * 6.0 Mbps
                        ....
                        * 54.0 Mbps
                Frequencies:
                        * 5180 MHz [36] (20.0 dBm)
                        * 5200 MHz [40] (20.0 dBm)
                        ....
                        * 5745 MHz [149] (20.0 dBm)
                        ....
        valid interface combinations:
                 * #{ IBSS } <= 1, #{ managed, AP, P2P-client, P2P-GO } <= 2,
                   total <= 2, #channels <= 1, STA/AP BI must match
        ....

数据量挺庞大的，所以耗用一些篇幅～基本上，从 iw list 可以看到这个 phy0 的设备，里面有提到 rsn 机制，以及支持的加密机制，另外，也支持建置 AP 模式～同时具有 2.4GHz 与 5GHz 的频段～频段的工作性能，5GHz 可以达到 80MHz 的时脉！不过，通常缺省都只有激活在 20MHz 而已，因此性能可能没有办法达到上述的情境！再来，看看目前支持的信道情境如何！

[root@cloud ~]# iw phy phy0 channels
Band 1:
        * 2412 MHz [1]
          Maximum TX power: 16.0 dBm
          Channel widths: 20MHz HT40+
        * 2417 MHz [2]
          Maximum TX power: 16.0 dBm
          Channel widths: 20MHz HT40+
        .....
Band 2:
        * 5180 MHz [36]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        .....
        * 5745 MHz [149]
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        .....

看起来两个频段的信道号码不同，支持的时脉也不一样～通常 2.4GHz 缺省信道会选择 1，而 5GHz 信道缺省选择 149，所以鸟哥拿上面两段的结果来展示而已！接下来，让我们扫描一下整体区网内的 AP 状态吧！

[root@cloud ~]# iw dev wlp0s20f0u5 scan
BSS e8:cc:18:f1:bf:fa(on wlp0s20f0u5)
        last seen: 563019.016s [boottime]
        TSF: 2653006257348 usec (30d, 16:56:46)
        freq: 5745
        beacon interval: 100 TUs
        capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
        signal: -55.00 dBm
        last seen: 351 ms ago
        Information elements from Probe Response frame:
        SSID: vbird-5G
        Supported rates: 6.0* 9.0* 12.0* 18.0* 24.0* 36.0* 48.0* 54.0*
        HT capabilities:
                Capabilities: 0x186e
                        HT20/HT40
                        SM Power Save disabled
                        RX HT20 SGI
                        RX HT40 SGI
                        ....
        HT operation:
                 * primary channel: 149
                 * secondary channel offset: above
                 ....
        VHT capabilities:
                VHT Capabilities (0x03c12021):
                        Max MPDU length: 7991
                        Supported Channel Width: neither 160 nor 80+80
                        short GI (80 MHz)
                        ....
                VHT TX highest supported: 390 Mbps
        VHT operation:
                 * channel width: 1 (80 MHz)
                 * center freq segment 1: 155
                 * center freq segment 2: 0
                 * VHT basic MCS set: 0xfffc
        RSN:     * Version: 1
                 * Group cipher: CCMP
                 * Pairwise ciphers: CCMP
                 * Authentication suites: PSK
                 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
                 ....

不要拿别人家的数据来解释，所以拿鸟哥办公室内一部小 AP 来解释。一开始会展示该 AP 开机的时间与最近一次被本设备看到的时间。然后是使用的频段 (5745MHz)，还有信号强度 (-55dBm)，以及 SSID 名称与支持的速度。再来则是使用到的信道 (primary channel)，以及支持的信道宽度，以及可达到的最高速度 (390Mbps)。至于底下的 RSN 则是说明该机制的加解密与认证的方式等，数据相当丰富！这样看起来，这个硬件应该是没啥大问题了！可以拿来进行 AP 之用！

需要的设置项目

还记得你怎么连上无线网络 AP 的嘛？很简单啊！就是一个 AP 的名称，一个该名称的密码，如此而已。其实， AP 与你的设备之间，还需要其他机制的！包括使用的加密机制、操作的频率、使用的信道 (channel)、传输的速度 (802.11ac/802.11n/802.11ag 等)。这些基本上 NetworkManager 都自动帮你处理妥当了！你几乎不需要额外加工！有时候为了方便起见，NetworkManager 也建议你保留空值，让 AP 与 client 之间可以拥有比较大的连接机制选择空间。但是，如果你需要比较严格的加密机制保护时，那就得要自行选择适当的机制了。相关的机制意义，可以参考文末 GNOME 的说明文档，挺简单易查的。不过，因为 NetworkManager 的代码关系，目前似乎没有可以选择传输标准 (802.11??) 的参数就是了！所以，连接速度上面可能无法达到优化！

我们现在要设置的 WiFi AP 大致需要的参数有：

SSID，设为 runap：就是无线 AP 的名称
Password，设为 myrockylinux9：连接到这个 AP 的密码
加密机制，设为 wpa-psk： AP 支持的加密机制，还有类似 wpa-eap, wpa-eap-suite-b-192 等
操作频率，设为 5GHz：主要是 2.4/5 GHz 两种机制
连接信道，设为 40 或 149：这是 5GHz 的信道，也可以让系统自由设置
自动分配网络参数，设为分享 (share)：要不要让 NetworkManager 自动分配网络参数的意思。
分享的 IP 网段： 192.168.33.0/24

# 关闭 WiFi 用户端连接后，开始以上面说明的参数设计 runap 的连接
[root@cloud ~]# nmcli connection down vbird-5G
[root@cloud ~]# nmcli connection add type wifi mode ap con-name runap ifname wlp0s20f0u5 \
>  ssid runap 802-11-wireless-security.psk myrockylinux9 802-11-wireless.band a \
>  802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.proto rsn \
>  802-11-wireless-security.group ccmp 802-11-wireless-security.pairwise ccmp \
>  ipv4.method shared ipv4.addresses 192.168.33.254/24

[root@cloud ~]# nmcli connection up runap
[root@cloud ~]# nmcli connection
NAME        UUID                                  TYPE      DEVICE
runap       9f04c229-9098-4d52-aa6a-19558f1dbde8  wifi      wlp0s20f0u5
eno1        24199355-b3a4-3f4d-bd6e-65be1085a499  ethernet  eno1
lo          08244c39-77bc-412e-a6dd-a632a2d7688d  loopback  lo
....
[root@cloud ~]# iw dev
phy#0
   Interface wlp0s20f0u5
       ifindex 11
       wdev 0x1
       addr c8:7f:54:8d:98:68
       ssid runap
       type AP
       channel 149 (5745 MHz), width: 20 MHz, center1: 5745 MHz
       txpower 19.00 dBm
       multicast TXQ:
           qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
           0       0       37      0       0       0       0       6004            39

你看看，我们很快就创建好一个 AP 了！而且这个 AP 是真的可以用！你可以拿出笔电、手机开始连接到这个 AP 看看！可以实际上网喔！我们的 host 实体机器也不需要额外进行防火墙设计，WiFi 用户端可以直接上网没问题！当你使用你的手机连上之后，查看一下相关的数据：

[root@cloud ~]# iw dev wlp0s20f0u5 station dump
Station 32:56:85:13:2a:8c (on wlp0s20f0u5)
        signal:         -50 [-50] dBm
        signal avg:     -52 [-52] dBm
        tx bitrate:     6.5 MBit/s MCS 0
        tx duration:    28675 us
        rx bitrate:     6.0 MBit/s
        rx duration:    9165 us
        airtime weight: 256
        ....

这速度真的是有点惨...从手机上面看起来速度大致上也只有 86Mbps 而已～看起来应该就是前面提到的，信道的 width 时脉有关！刚刚 USB 当用户端时，width 可以到 80MHz，当 AP 时，缺省仅有 20MHz，差了 4 倍！速度也从 390Mbps 降低到 86Mbps 左右，也差大概 4 倍，看起来就是这个问题！不过，查找了不少数据之后，发现到似乎这颗 WiFi 芯片没办法自动切换高时脉的情境，所以，搭建成为 AP 之后，整体性能其实不是这么好！不过，拿来作为简单的连接，其实还是 OK 的！

另一个可改时脉的案例介绍

后来，鸟哥找到另一台主机具有内置 Intel 6 AX200，驱动程序为 iwlwifi 模块的芯片，使用相同的方式创建好 runap 之后，查找到的信道时脉也是只有 20MHz 而已，但是这颗芯片就比较好一点，可以通过 iw 调整频道的时脉！调整的方式如下：

# 在 Intel 6 AX200 芯片的主机上面，调整信道时脉
[root@host5 ~]# iw dev
phy#0
        Interface wlp71s0
                ifindex 4
                wdev 0x1
                addr 50:e0:85:f5:08:e8
                ssid runap
                type AP
                channel 149 (5745 MHz), width: 20 MHz, center1: 5745 MHz
                txpower 22.00 dBm

# 1. 第一种修改方式，经过计算自行找到平均信道频率的方式：
[root@host5 ~]# iw dev [设备名称] set freq [原始信道的频率] [新时脉] [平均信道频率]
[root@host5 ~]# iw dev wlp71s0 set freq 5745 80 5775

[root@host5 ~]# iw dev
....
                channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz
....

# 2. 第二种修改方式，提供新的时脉，让 iw 自动找到正确的平均信道频率
[root@host5 ~]# iw dev [设备名称] set freq [信道的频率] [新时脉]
[root@host5 ~]# iw dev wlp71s0 set freq 5745 80MHz

基本上，我们缺省使用 5GHz 的 149 信道，这个信道的频率缺省为 5745MHz，因为信道的时脉不足，所以，高时脉通常是结合多个信道运作而来！根据 wiki 的说明，在信道 149 的情境下，要用到 80MHz 的时脉，就得要结合 149, 153, 157, 161 四个信道，而平均时脉会在 155 信道上！经过 153 与 157 信道频率的平均计算，就可以得到 155 信道的频率是 5775MHz 了！详细的数据可以查找底下的说明：

https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(802.11a/h/j/n/ac)

除了自行计算得到平均时脉之外，也可以通过上表当中的第二种方式，直接指定时脉来让 iw 自动调整～经过这个计算的结果，确实可以发现 iw dev 指令可以修改信道的时脉，但是可能需要设备有支持才可以使用了！另外，RHEL 系列的系统，似乎不太能支持 USB 的设备，所以，可能得要类似主板插卡式的 WiFi 设备，比较有机会可以直接驱动！

6.2、产生新的 switch (bridge 桥接器)

前面的章节，我们花这么多的时间建置虚拟机的 KVM 母机器 (host)，重点就是要创建在整个云端环境下的整体小机房的环境！目前我们这个小机器定位在一般小型企业的环境下，用户假设在 50 人以下吧～然后有许多信息设备，保留一个对外的互联网连接信道。那么如何通过目前这个唯一的系统建置、仿真好所需要的环境呢？那就需要使用在第零章里面讲到的使用 bridge (图0.1.7) 来提供虚拟网卡的连接啦！设置方式很简单，但是逻辑方面有点难！我们先用绘图的方式来说明一下，目前需要的局域网路环境好了：

如上图所示，最重要的那一部系统应该就是骨干系统 (简称 Master)，该系统应该会拥有 4 个网络界面，并且分别链接到 WAN 设备 (无论是电话线、光纤、 ADSL 拨接调制解调器等，都算可以连接到互联网的设备)、两个物理隔开的网段、还有一个无线 AP 的连接。鸟哥这里假设 WAN 设备为光纤调制解调器，因此需要通过 PPPoE 的方式来连接，所以需要一张真的可以对外的网络卡！另外两个 switch 就可以在 KVM host 系统内仿真出两个桥接器，提供给不同功能的系统使用。最后再使用 pci passthrough 的功能，将 KVM host 的 USB 芯片组分享给 Master 系统使用，这样，这一部超级重要的系统，就拥有 USB 的控制权，也就能够抓到 USB 的 WiFi 设备了。

诡异的网络卡代号变更问题

那么 KVM host 需要什么呢？鸟哥自己希望，KVM host 自己的网络可以存在，也就是原本的 192.168.201.249 可以保留给 host 自己使用。因此，上图的 Master 所需要对外的网络卡，就得要额外取得另一张独立网卡才行～既然要额外购买外置式网卡，鸟哥选择 Asus 的便宜 10G 网络卡，额外安装了 XG-C100C 这张小片的网卡。另外，因为想要使用小型 USB WiFi 设备测试一下自建的 AP 的功能，因此，鸟哥也额外拿了一片 USB 扩充卡安插在系统上！安插完毕重新开机后，在实体机器上面登录系统的 PCI 总线变这样：

# 在实体机器上面，通过实体终端机环境，查看总线的结果：
[root@cloud ~]# lspci
00:00.0 Host bridge: Intel Corporation Comet Lake-S 6c Host Bridge/DRAM Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) (rev 03)
00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 03)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 03)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
00:14.0 USB controller: Intel Corporation Comet Lake PCH-V USB Controller
00:14.2 Signal processing controller: Intel Corporation Comet Lake PCH-V Thermal Subsystem
00:16.0 Communication controller: Intel Corporation Comet Lake PCH-V HECI Controller
00:17.0 RAID bus controller: Intel Corporation Device a386
00:1b.0 PCI bridge: Intel Corporation Device a3e9 (rev f0)
00:1c.0 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #08 (rev f0)
00:1f.0 ISA bridge: Intel Corporation B460 Chipset LPC/eSPI Controller
00:1f.2 Memory controller: Intel Corporation Cannon Lake PCH Power Management Controller
00:1f.3 Audio device: Intel Corporation Comet Lake PCH-V cAVS
00:1f.4 SMBus: Intel Corporation Comet Lake PCH-V SMBus Host Controller
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (12) I219-V
01:00.0 Ethernet controller: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 02)
02:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04)
04:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02)

根据总线的差异，内置/扩充的卡片相关性是这样：

00:1f.6：原本的主板内置的网络卡
01:00.0：外置的华硕那张 10G 网卡
00:14.0：主板内置的 USB 芯片组
04:00.0：外置的 USB 扩充卡！

我们在安装系统之后，第一个找到的网络卡就是 eno1 这一张卡，鸟哥一直以为这张卡的名称就是总线的名称，没想到并不是... 当我使用了 nmcli 去检查之后，发现变这样：

[root@cloud ~]# nmcli
enp0s31f6: connected to Wired connection 1
        "Intel I219-V"
        ethernet (e1000e), FC:34:97:3B:EB:86, hw, mtu 1500
....
eno1: unavailable
        "Aquantia AQC107 NBase-T/IEEE 802.3bz"
        ethernet (atlantic), 7C:10:C9:67:BA:B8, hw, mtu 1500
....

注意看上面的输出结果，原本的 e1000e 驱动程序的网络卡名称变成了 enp0s31f6，而外插的网卡名称反而抢了 eno1 ！可以明显的看到该网卡使用的是 atlantic 模块！这代表什么呢？这代表网络卡名称被错乱调换了...鸟哥在安装新网卡之后，想要直接使用 ssh 连接到 KVM host 系统去设置网络，结果一直无法顺利连上，以为是哪边坏掉了。以实体终端机查看之后，才发现有这个情况...真的很特别！以前都没有碰到过...

因为原本连接名称的 eno1 设置是正确的～所以，鸟哥的想法是，将 eno1 的连接名称与网络卡名称抽换掉，变成内置网卡的新名称，这样就不用删除重建了！轻松愉快多了！所以鸟哥的处理方式是这样的：

[root@cloud ~]# nmcli connection delete Wired\ connection\ 1
[root@cloud ~]# nmcli connection modify eno1 connection.id enp0s31f6 ifname enp0s31f6
[root@cloud ~]# nmcli connection up enp0s31f6

这样应该就可以得到正确的设置了！另外，在搞定 birdge 的设置之前，新网卡 (就是 eno1) 先不要安插网络线！否则如果外部区网有 IP 分享器的话，NetworkManager 可能又会自动产生一个连接设备！那就比较伤脑筋！

总之，如果你安插了新的网卡，最好还是在实体机器的终端机上面登录去查阅一下，如果 nmcli 有抓到网卡名称，但是可能名称跑掉了！这也没关系，你可以自行将所有的连接名称删除，然后再依据实际的新的网络卡名称对应去重新设计好网络参数即可喔！

创建 Linux bridge 搭配实体网卡

现在，让我们来创建一个名为 wanbr0 的桥接器在目前的系统上，创建桥接器的方法很简单，同样通过 nmcli 即可！另外，要注意的是，我们现在创建的桥接器角色有点像是 switch 的地位，既然是基础的 switch，基本上不用给 IP 地址也没关系！所以，等等我们不会给这个桥接任何 IP 地址的设置喔！

# 1. 创建桥接器
[root@cloud ~]# nmcli connection add type bridge con-name wanbr0 ifname wanbr0 \
>  ipv4.method disabled ipv6.method disabled
[vbird@cloud ~]# nmcli connection
enp0s31f6   24199355-b3a4-3f4d-bd6e-65be1085a499  ethernet  enp0s31f6
lo          590183b7-b778-4148-835f-bdd78dfc00a0  loopback  lo
wanbr0      7d3179d8-c811-439a-b14c-707e443be6b7  bridge    wanbr0
....

[root@cloud ~]# nmcli device
DEVICE            TYPE      STATE                   CONNECTION
enp0s31f6         ethernet  connected               enp0s31f6
lo                loopback  connected (externally)  lo
wanbr0            bridge    connected               wanbr0
....

这时系统会自动创建一个 wanbr0 的桥接器，网卡名称就是 wanbr0 ！现在，让我们的这块外置式网卡 (就是 eno1) 加入到 wanbr0 的运作实体层，最简单的想法就是，让 eno1 作为 wanbr0 的实体，所以，任何使用 wanbr0 的连接，其实都是通过 eno1 沟通的意思。设计的方法也很简单：

# 2. 让 eno1 实际加入 wanbr0 的运作实体
[root@cloud ~]# nmcli connection add type bridge-slave con-name eno1 ifname eno1 master wanbr0
[root@cloud ~]# nmcli connection up eno1
[root@cloud ~]# nmcli connection up wanbr0

这样就搞定啰！现在你可以将你的网络线安插到这张扩充的网络卡上面了！然后测试一下你的连接速度：

[root@cloud ~]# ethtool wanbr0
Settings for wanbr0:
        Supported ports: [  ]
        ....
        Speed: 1000Mb/s
        Duplex: Unknown! (255)
        Auto-negotiation: off
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Link detected: yes

[root@cloud ~]# ethtool eno1
Settings for eno1:
        Supported ports: [ TP ]
        Supported link modes:   100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
                                2500baseT/Full
                                5000baseT/Full
        ....
        Speed: 1000Mb/s
        ....
        Link detected: yes

这样就能确定 eno1 理论上确实可以支持到 10G 的网络速度，但是由于鸟哥所在的局域网路实体 switch 的速度仅达 1G 而已，所以上面的 speed 当然也只能是 1Gbps 而已啰！

创建单纯给 VM 内部使用的 Linux bridge

如同上面图 6.2-1 所示，整个虚拟的环境当中，我们还需要内部的 switch LAN 与 switch DMZ 才行！给用户端使用的 switch LAN 我们假设为 lanbr0 这个接口与网卡 (桥接的网卡名称可以自订)，而给服务器服务专用的 switch DMZ 则假设为 serverbr0 这个接口与网卡！设置就非常简单！因为不需要搭配实体网卡的缘故！

# 1. 创建 lanbr0 这个桥接器，不用给 IP 地址：
[root@cloud ~]# nmcli connection add type bridge con-name lanbr0 ifname lanbr0 \
>  ipv4.method disabled ipv6.method disabled
# 2. 创建 serverbr0 这个桥接器，不用给 IP 地址：
[root@cloud ~]# nmcli connection add type bridge con-name serverbr0 ifname serverbr0 \
>  ipv4.method disabled ipv6.method disabled

很简单的将三个需要的桥接设备搞定！

6.3、设计 Master 服务器硬件系统

将基础硬件设计完毕之后，再来就是要处理虚拟机的相关硬件设置！以上面图 6.2-1 所示，最麻烦的应该是那个 Master 骨干服务器系统了！它需要三张有线网卡，以及一个 AP 接线，其中 AP 我们预计使用 USB 无线网卡来仿真。问题是，我们在虚拟机里面，所有的设备几乎都是仿真的，那么我们就无法将实体的 USB 无线网卡分配给虚拟机啊～那怎办？我们在上一小节不是有加入一张 USB 的扩充卡嘛？现在，我们先将这个扩充卡的控制权移交给 Master 骨干服务器，本机上面的系统将无法控制这个 USB 扩充卡！然后将 USB 无线网卡插到这张扩充卡上，这样 Master 骨干服务器这部虚拟机，就可以使用实体无线网卡啰！

6.3.1、进行 PCI passthrough 设置

所谓的 PCI passthrough 的意思是，将实体机器 (host) 上面的某个硬件控制权移交给某个虚拟机控制的意思，所以，当这部取得硬件控制权的虚拟机启动后，host 母机器将不能操控该硬件的意思。

IOMMU 与 host 母机器的功能查找

母机器要达成这个功能，除了 KVM 本身之外，内核本身还得要支持激活 IOMMU 这个机制比较好！IOMMU 可以通过内核本身的功能控制，将一些硬件进行分群，这样在进行刚刚谈到的硬件控制权转移时，比较好处理！那我如何检查内核有没有设计启动 IOMMU 的功能呢？libvirtd 有提供一个 virt-host-validate 的检查指令，简单查找一下就知道了：

[root@cloud ~]# virt-host-validate
  QEMU: Checking for hardware virtualization              : PASS
  QEMU: Checking if device /dev/kvm exists                : PASS
  QEMU: Checking if device /dev/kvm is accessible         : PASS
  QEMU: Checking if device /dev/vhost-net exists          : PASS
  QEMU: Checking if device /dev/net/tun exists            : PASS
  QEMU: Checking for cgroup 'cpu' controller support      : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support  : PASS
  QEMU: Checking for cgroup 'cpuset' controller support   : PASS
  QEMU: Checking for cgroup 'memory' controller support   : PASS
  QEMU: Checking for cgroup 'devices' controller support  : PASS
  QEMU: Checking for cgroup 'blkio' controller support    : PASS
  QEMU: Checking for device assignment IOMMU support      : PASS
  QEMU: Checking if IOMMU is enabled by kernel            : WARN (IOMMU appears to be disabled in kernel. Add intel_iommu=on to kernel cmdline arguments)
  QEMU: Checking for secure guest support                 : WARN (Unknown if this platform has Secure Guest support)

因为我们没有在内核参数里面加入 IOMMU 的数据，但是这个参数并不会影响到其他虚拟化的功能 (一般虚拟机不会用到 PCI passthrough 啦！)，所以这边的参数只写 WARN (警告) 通知而已，并不是什么错误！那如果要启动，就得要加入到内核参数去！我们可以通过底下的方式来加入内核参数：

# 1. 编辑 grub 参数指定文件：
[root@cloud ~]# vim /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=UUID=2cf30cd3-13ea-4a8d-b651-8239aabc2a61 rd.md.uuid=2925d33f:4403eff2:64ede82a:3e2b8a68 
  rd.md.uuid=585291ed:cc38a802:ff454b5e:0d950ee7 intel_iommu=on"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

# 2. 重建 grub 设置档
[root@cloud ~]# grub2-mkconfig -o /boot/grub2/grub.cfg

# 3. 重新开机
[root@cloud ~]# reboot

以前的版本设计中，EFI 与 BIOS 的 grub 设置档放置到不同的位置上，不过目前 EFI 的设置档其实有指向 /boot/grub2/grub.cfg 了！另外， /etc/grub2.cfg 也指向同一个设置档～因此，上述的第 2 个步骤 grub.cfg 的文件名不用改变！直接建置即可！假设你的系统里面，相关的 VM 以及 qemu 仿真的网络都没有自动激活，那么重新开机后，系统大致上就恢复成相对干净的环境了！重新开机之后，请再次进入 host 系统，并且检查一下 IOMMU 功能是否启动了！

# 1. 再次确认 IOMMU 有没有顺利启动
[root@cloud ~]# virt-host-validate
  QEMU: Checking for hardware virtualization                 : PASS
  QEMU: Checking if device /dev/kvm exists                   : PASS
  QEMU: Checking if device /dev/kvm is accessible            : PASS
  QEMU: Checking if device /dev/vhost-net exists             : PASS
  QEMU: Checking if device /dev/net/tun exists               : PASS
  QEMU: Checking for cgroup 'cpu' controller support         : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support     : PASS
  QEMU: Checking for cgroup 'cpuset' controller support      : PASS
  QEMU: Checking for cgroup 'memory' controller support      : PASS
  QEMU: Checking for cgroup 'devices' controller support     : PASS
  QEMU: Checking for cgroup 'blkio' controller support       : PASS
  QEMU: Checking for device assignment IOMMU support         : PASS
  QEMU: Checking if IOMMU is enabled by kernel               : PASS
  QEMU: Checking for secure guest support                    : WARN (Unknown if this platform has Secure Guest support)

# 2. 确认之后，再来看看分类的结果
[root@cloud ~]# ll /sys/kernel/iommu_groups/
drwxr-xr-x. 3 root root 0 Sep 13 15:49 0
drwxr-xr-x. 3 root root 0 Sep 13 15:49 1
drwxr-xr-x. 3 root root 0 Sep 13 15:49 10
drwxr-xr-x. 3 root root 0 Sep 13 15:49 2
drwxr-xr-x. 3 root root 0 Sep 13 15:49 3
drwxr-xr-x. 3 root root 0 Sep 13 15:49 4
drwxr-xr-x. 3 root root 0 Sep 13 15:49 5
drwxr-xr-x. 3 root root 0 Sep 13 15:49 6
drwxr-xr-x. 3 root root 0 Sep 13 15:49 7
drwxr-xr-x. 3 root root 0 Sep 13 15:49 8
drwxr-xr-x. 3 root root 0 Sep 13 15:49 9
# 看起来共分为 0~10 种类型

# 3. 再次查看 USB 的 PCI 总线信息：
[root@cloud ~]# lspci | grep -i usb
00:14.0 USB controller: Intel Corporation Comet Lake PCH-V USB Controller
04:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02)

# 4. 将总线信息与 IOMMU 的分类结合看看：
[root@cloud ~]# ll /sys/bus/pci/devices/0000\:04\:00.0/iommu_group/devices/
lrwxrwxrwx. 1 root root 0 Sep 13 16:05 0000:00:1c.0 -> ../../../../devices/pci0000:00/0000:00:1c.0
lrwxrwxrwx. 1 root root 0 Sep 13 16:05 0000:04:00.0 -> ../../../../devices/pci0000:00/0000:00:1c.0/0000:04:00.0

[root@cloud ~]# lspci | grep 1c.0
00:1c.0 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #08 (rev f0)
# 可以看出来，我们这张 USB 扩充卡，其实是安插在主板上的 PCI-E 插槽上！

# 5. 确认 libvirtd 有抓到这些本机设备
[root@cloud ~]# virsh nodedev-list --cap pci
pci_0000_00_00_0
pci_0000_00_01_0
pci_0000_00_02_0
pci_0000_00_04_0
pci_0000_00_08_0
pci_0000_00_14_0
pci_0000_00_14_2
pci_0000_00_16_0
pci_0000_00_17_0
pci_0000_00_1b_0
pci_0000_00_1c_0
pci_0000_00_1f_0
pci_0000_00_1f_2
pci_0000_00_1f_3
pci_0000_00_1f_4
pci_0000_00_1f_6
pci_0000_01_00_0
pci_0000_02_00_0
pci_0000_04_00_0

# 6. 找出上述 pci_0000_04_00_0 的硬件详细总线信息：
[root@cloud ~]# virsh nodedev-dumpxml pci_0000_04_00_0
<device>
  <name>pci_0000_04_00_0</name>
  <path>/sys/devices/pci0000:00/0000:00:1c.0/0000:04:00.0</path>
  <parent>pci_0000_00_1c_0</parent>
  <driver>
    <name>xhci_hcd</name>
  </driver>
  <capability type='pci'>
    <class>0x0c0330</class>
    <domain>0</domain>
    <bus>4</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x0015'>uPD720202 USB 3.0 Host Controller</product>
    <vendor id='0x1912'>Renesas Technology Corp.</vendor>
    <iommuGroup number='9'>
      <address domain='0x0000' bus='0x00' slot='0x1c' function='0x0'/>
      <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </iommuGroup>
    <pci-express>
      <link validity='cap' port='0' speed='5' width='1'/>
      <link validity='sta' speed='5' width='1'/>
    </pci-express>
  </capability>
</device>

从上述的分析当中，我们大概知道这张 USB 扩充卡在 libvirtd 的认知里面，比较重要的信息是这样：

domain: 0
bus: 4
slot: 0
function: 0

现在，请创建一个名为 master.xml 的新的 VM 设置档，并依据如下的方式来修改看看：

# 1. 创建新的 XML 文件
[root@cloud ~]# cd /kvm/xml
[root@cloud xml]# cp demo1.xml master.xml
[root@cloud xml]# vim master.xml
# 要修改的项目请自行找到底下的三行来处理：
  <name>master</name>
    <nvram>/kvm/xml/master.uefi.fd</nvram>
      <source file="/kvm/img/master.img"/>

# 在 </devices> 这一行的上方，添加这个项目：
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
         <address domain='0' bus='4' slot='0' function='0'/>
      </source>
    </hostdev>
  </devices>

上面的 hostdev 就是本机的实体硬件的意思，可以直接分配给 VM 虚拟机喔！相当有趣！接下来，只要将网络卡对应，以及拷贝硬盘，应该就可以处理好我们需要的防火墙环境了！

6.3.2、处理网卡与 birdge 的对应等任务

接下来，我们得要变更网络的对应，毕竟如同 6.2 节的处理，我们已经没有 qemu 管理的桥接器，仅有 Linux 自己的桥接器而已！因此，这里我们得要处理好虚拟机的网络卡对应喔！如同之前章节提到的， Master 骨干系统需要三张有线网卡，一个 USB 无线实体网卡， USB 扩充卡的支持在上一小节完成，现在让我们来完成三张实体网卡吧！

# 1. 再次编辑 master.xml 文件，找到 interface 修改成为如下模样：
[root@cloud xml]# vim master.xml
    <interface type="bridge">
      <source bridge="wanbr0"/>
      <mac address="52:54:00:00:00:f1"/>
      <model type="virtio"/>
    </interface>
    <interface type="bridge">
      <source bridge="lanbr0"/>
      <mac address="52:54:00:00:00:f2"/>
      <model type="virtio"/>
    </interface>
    <interface type="bridge">
      <source bridge="serverbr0"/>
      <mac address="52:54:00:00:00:f3"/>
      <model type="virtio"/>
    </interface>
    ....
    <graphics type="vnc" port="5909" listen="0.0.0.0" passwd="rocky9">
# 特别记得网络卡硬件地址要修改！连接端口口也改一下！

# 2. 拷贝新的 master 硬盘，要与前一小节的硬盘名称搭配！
[root@cloud xml]# cd ../img/
[root@cloud img]# cp demo1.img master.img
[root@cloud img]# qemu-img info master.img
image: master.img
file format: qcow2
virtual size: 30 GiB (32212254720 bytes)
disk size: 2.37 GiB
cluster_size: 2097152
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
...

# 3. 尝试启动一下 master 这个虚拟机测试看看有没有设置错误！
[root@cloud img]# virsh create /kvm/xml/master.xml
Domain 'master' created from /kvm/xml/master.xml

在 NetworkManager 的处理方案中，当你启动了一张虚拟网卡，NetworkManager 会自己产生一块实体机器看得到的网卡！你可以先观察看看！虽然不常发生，但是，鸟哥确实发生过底下的 host 母机器里面的网卡脱机 (disconnection) 的状态，害鸟哥在 VM 里面疯狂测试的时候，一切都失败...后来才发现是 host 母机器的对应网卡脱机而已～启动就好了！

# 1. 在实体机器上面检查所有网卡的数据：
[root@cloud ~]# nmcli device
DEVICE     TYPE      STATE                   CONNECTION
enp0s31f6  ethernet  connected               enp0s31f6
lo         loopback  connected (externally)  lo
lanbr0     bridge    connected               lanbr0
serverbr0  bridge    connected               serverbr0
wanbr0     bridge    connected               wanbr0
eno1       ethernet  connected               eno1
vnet1      tun       connected               vnet1
vnet2      tun       connected               vnet2
vnet0      tun       disconnected            --
# 上面这三张就是 NetworkManager 自动产生的对应网卡！对应到 VM 里面去喔！

[root@cloud ~]# nmcli
....
vnet1: connected to vnet1
        "vnet1"
        tun, FE:54:00:00:00:F2, sw, mtu 1500
        master lanbr0

vnet2: connected to vnet2
        "vnet2"
        tun, FE:54:00:00:00:F3, sw, mtu 1500
        master serverbr0

vnet0: disconnected
        "vnet0"
        1 connection available
        tun, FE:54:00:00:00:F1, sw, mtu 1500
....

[root@cloud ~]# nmcli connection
NAME        UUID                                  TYPE      DEVICE
....
vnet1       37f10360-815e-4c1d-bc99-6bd0093fc5cd  tun       vnet1
vnet2       8cfc61e7-1a5a-4a47-b787-9ef81d423a4e  tun       vnet2
vnet0       ae16568c-57b8-41cb-99cf-720d4102399f  tun       --
# 同样可以发现 vnet0 其实脱机了！那怎办？

[root@cloud ~]# nmcli connection up vnet0

[vbird@cloud ~]# nmcli device
DEVICE     TYPE      STATE                   CONNECTION
....
vnet0      tun       connected               vnet0
vnet1      tun       connected               vnet1
vnet2      tun       connected               vnet2
# 确认所有对应的三张网卡有顺利连接 (connected) 就 OK 啦！

现在，让我们使用 VNC 的方式连接到本机的 5909 来实际登录这部虚拟机，并且查阅一下该机器内部的网络对应！如果一切顺利的话，当你登录虚拟机系统，该系统目前应该不会有网络，不过你可以发现如下的设备对应才对： (注意喔！底下的环境是在 Master 那部虚拟机里面喔！所以你看主机名称会是 localhost)

# 1. 使用 nmcli 检查一下 NetworkManager 找到的网络设备：
[root@localhost ~]# nmcli
....
enp1s0: connecting (getting IP configuration) to enp1s0
        "Red Hat Virtio"
        ethernet (virtio_net), 52:54:00:00:00:F1, hw, mtu 1500

enp2s0: connecting (getting IP configuration) to Wired connection 1
        "Red Hat Virtio"
        ethernet (virtio_net), 52:54:00:00:00:F2, hw, mtu 1500

enp3s0: connecting (getting IP configuration) to Wired connection 2
        "Red Hat Virtio"
        ethernet (virtio_net), 52:54:00:00:00:F3, hw, mtu 1500

wlp7s0u1: unmanaged
        "ASUSTek Computer AC51 802.11a/b/g/n/ac"
        wifi (mt76x0u), C8:7F:54:8D:98:68, plugin missing, hw, mtu 1500
....
# 注意看每个网络的网络地址喔～另外，我们确实可以抓到 USB 无线网卡！

[root@localhost ~]# nmcli connection
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  5fb71d7d-b9c7-3262-9e34-8ed1d24ef77d  ethernet  enp2s0
Wired connection 2  ccbb41fc-de77-3cf6-9b5a-84bbac325865  ethernet  enp3s0
enp1s0              0b413fa2-5192-3674-a542-323759ec20bc  ethernet  enp1s0
lo                  c0c6eb58-dbb5-4150-8669-dd137942c8ff  loopback  lo
# 由于之前的网络设备名称同样是 enp1s0，因此这里会保留名称。其他的会用『Wired connection』为名

更多高端的设置，我们在下个章节慢慢讲～这个 Master 虚拟系统先留着！我们会慢慢仔细的来讲讲这个系统的！

6.4、设计用户端/服务器端环境硬件系统

由于防火墙系统在建置的时候，需要测试其网络分享 (IP 分享器，或称为 NAT 技术) 的功能，因此，我们需要增加创建几个测试用的系统，分别是位于 lanbr0 桥接器上面的用户端系统，以及接在 serverbr0 桥接器上面的预计作为单一服务器的伺服系统。这两个系统都需要通过 Master 骨干服务器才能够连外！这两个新系统设计的方法很单纯，需要一个新的硬盘，以及修改网卡的界面链接桥接器而已。我们就来处理一下。

创建用户端/服务器端的 demo 磁盘

由于用户端的系统未来可能会安装图形界面软件，服务器端则可能会保持的更干净！因此，不建议直接 backing 到缺省的磁盘系统上，而是创建新的磁盘文件，分别给用户端/服务器端作为 backing file 的样板较佳！

[root@cloud ~]# cd /kvm/img
[root@cloud img]# cp demo1.img client_raw.img
[root@cloud img]# cp demo1.img server_raw.img

处理 XML 文件内容

修改 xml 文件，修改的内容也很简单，注意到如下的环境即可：

[root@cloud img]# cd /kvm/xml/
[root@cloud xml]# cp demo1.xml client_raw.xml
[root@cloud xml]# vim client_raw.xml
# 主要必须修改的，就是底下这三行～基本上，搜索 demo1 去更改即可
  <name>client_raw</name>
    <nvram>/kvm/xml/client_raw.uefi.fd</nvram>
      <source file="/kvm/img/client_raw.img"/>

# 将网卡 interface 的部份，修改成为底下这样即可：
    <interface type="bridge">
      <source bridge="lanbr0"/>
      <mac address="52:54:00:00:20:01"/>
      <model type="virtio"/>
    </interface>

    <graphics type="vnc" port="5920" listen="0.0.0.0" passwd="rocky9">

[root@cloud xml]# cp demo1.xml server_raw.xml
[root@cloud xml]# vim server_raw.xml
# 主要必须修改的，就是底下这三行～基本上，搜索 demo1 去更改即可
  <name>server_raw</name>
    <nvram>/kvm/xml/server_raw.uefi.fd</nvram>
      <source file="/kvm/img/server_raw.img"/>

# 将网卡 interface 的部份，修改成为底下这样即可：
    <interface type="bridge">
      <source bridge="serverbr0"/>
      <mac address="52:54:00:00:30:01"/>
      <model type="virtio"/>
    </interface>

    <graphics type="vnc" port="5930" listen="0.0.0.0" passwd="rocky9">

[root@cloud xml]# virsh create client_raw.xml
[root@cloud xml]# virsh create server_raw.xml

[root@cloud xml]# virsh list
 Id   Name         State
----------------------------
 1    master       running
 2    client_raw   running
 3    server_raw   running

[root@cloud xml]# netstat -tlunp | egrep '^Pro|qemu'
Proto Recv-Q Send-Q Local Address   Foreign Address  State    PID/Program name
tcp        0      0 0.0.0.0:5909    0.0.0.0:*        LISTEN   786802/qemu-kvm
tcp        0      0 0.0.0.0:5920    0.0.0.0:*        LISTEN   786920/qemu-kvm
tcp        0      0 0.0.0.0:5930    0.0.0.0:*        LISTEN   787017/qemu-kvm

这样就搞定了！最后会有三个 VM 系统存在于目前的环境中～同时可以发现 VNC 链接的端口口号码分别是 5909, 5920, 5930。要注意的是，目前这两个 client_raw/server_raw 环境应该是没有对外网络的，所以只能通过 5920, 5930 连接到此 VM 的终端画面啰！要连网得要下个章节的防火墙系统 (Master server) 设置完成后，才有办法进行接续的工作了！

6.5、参考数据

GNOME 针对 802-11-wireless 说明文档：
https://developer-old.gnome.org/NetworkManager/stable/settings-802-11-wireless.html,
https://developer-old.gnome.org/NetworkManager/stable/settings-802-11-wireless-security.html
关于无线 AP 设置的简易 blog：
https://woshub.com/create-wi-fi-access-point-hotspot-linux/,
http://junyelee.blogspot.com/2020/02/linux-wireless.html
关于 iw 指令的一些简易应用：
https://wireless.wiki.kernel.org/en/users/documentation/iw
关于 wifi 带宽 20MHz 与 80MHz 的说明：
https://unix.stackexchange.com/questions/381298/how-to-calculate-parameters-to-iw-set-freq,
https://bbs.archlinux.org/viewtopic.php?id=230231,
https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(802.11a/h/j/n/ac),
https://superuser.com/questions/1646095/clients-cant-use-80mhz-channel,
https://netbeez.net/blog/linux-channel-hopping-wifi-packet-capturing/,
Google: linux iw wifi mode ap change channel width to 80MHz
host 在 PCI passthrough 应该要留意的检查事项：
https://access.redhat.com/documentation/zh-tw/red_hat_enterprise_linux/9/html/configuring_and_managing_virtualization/assembly_enabling-virtualization-in-rhel-9_configuring-and-managing-virtualization,
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_virtualization/managing-virtual-devices_configuring-and-managing-virtualization,
https://www.goglides.dev/bkpandey/what-is-iommu-how-to-check-iommu-is-enabled-1p7c

修改历史：

2023/09/15：将 Host 母系统的虚拟架构做的更仔细，然后创建一个 firewall 虚拟机！测试看看能否成功啰！
2023/09/27：要设计防火墙系统时，这才发现 NAT 没办法测试！所以，赶紧增加 6.4 小节，添加一个用户端测试机器！
2023/11/05：下一章节的 DNAT 发现到没有 WWW 系统...所以将 6.4 增加另一个环境系统来处理！
2023/11/09：讲到防火墙，发现一堆 firewall 关键字～若使用 firewall 当主机名称，看起来会容易搞混～所以改成 master 骨干系统！

2023/09/15以来统计人数
计数器