鳥哥私房菜 - 第六章、區域網路整體環境規劃

最近更新時間： 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以來統計人數
計數器