Networking

具有靜態 IP 的 KVM QEMU 虛擬機鬆散的網路連接

  • April 2, 2020

我有一個KVM/QEMU主機和來賓(VM)執行Ubuntu 18.04 LTS的設置bridged networking。虛擬機隨機配置靜態 IP 鬆散網路連接(沒有模式)。使用 DHCP 配置的 VM 可以正常工作。

這是我的主機網路配置,

network:
   version: 2
   ethernets:
       eno1:
           dhcp4: no
           dhcp6: no
       eno4:
           dhcp4: true
       eno5np0:
           dhcp4: true
       eno6np1:
           dhcp4: true
       ens2f0np0:
           dhcp4: true
       ens2f1np1:
           dhcp4: true
   bridges:
       br0:
           interfaces: [eno1]
           dhcp4: no
           addresses:
           - 10.2.0.92/24
           gateway4: 10.2.1.252
           nameservers:
               addresses:
               - 8.8.8.8

這是我的帶有靜態 IP 的 vm(訪客)網路配置,

network:
   version: 2
   ethernets:
           ens3:
                   dhcp4: no
                   addresses:
                   - 10.2.0.210/23
                   gateway4: 10.2.1.252
                   nameservers:
                       addresses:
                       - 8.8.8.8

這是我使用 DHCP 的 vm(訪客)網路配置,

network:
   version: 2
   ethernets:
           ens3:
                   dhcp4: true

具有靜態 IP 的虛擬機進入某種空閒狀態。因此,當嘗試 SSH 或訪問其中的服務時,連接需要時間,

$ nc -z -v -w5 10.2.0.210 22
nc: connect to 10.2.0.210 port 22 (tcp) timed out: Operation now in progress

再試一次,它會工作,因為VM因為第一次嘗試而從空閒狀態轉移到工作狀態,

$nc -z -v -w5 10.2.0.210 22
Connection to 10.2.0.210 22 port [tcp/ssh] succeeded!

具有 DHCP 的虛擬機沒有問題。隨時都能正常連接,

$ nc -z -v -w5 10.2.0.184 22
Connection to 10.2.0.184 22 port [tcp/ssh] succeeded!

我檢查了以下連結,

但這沒有幫助。

KVM 配置有問題嗎?不僅 SSH,而且在 VM 中公開的任何服務也無法訪問。我已經驗證了VMs are in running state當我查詢virsh.

我看到的一個相當基本的問題是您在 br0 上的網關不在地址範圍內。您定義 /24 而不是 /23。

 br0:
           interfaces: [eno1]
           dhcp4: no
           addresses:
           - 10.2.0.92/**24**
           gateway4: 10.2.1.252
           nameservers:
               addresses:
               - 8.8.8.8

您只需將**/24**更改為 /23

10.2.0.92/23 將包含 10.2.0.0 到 10.2.1.255,就像您的 VM 中的主機一樣。問題不在於重疊空間,而是主機無法訪問 /24 的主機網關。

如果您要從來賓 -> 主機 ping… 數據包將離開來賓並獲得廣播,因為主機位於來賓目前網路的*NETMASK內。*主機將收到數據包。主人會發送回复。因為 xx1.x 的目的地不在 xx0.x 的目前網路上,所以數據包通常會被路由到網關。哦等等,網關也不在 xx0.x 上。數據包將無處可去。

請記住,數據包並不聰明。他們只會去你告訴他們的地方。

我上面沒有提到的一部分是 ARP。@Gerrit 上面的評論也解決了這個問題。當數據包在衝突域內發送時,它們通過 MAC 地址而不是 IP 傳輸。當 10.2.0.210/23 向 10.2.0.92 發送數據包時,10.2.0.210/23 發送廣播數據包詢問誰是 10.2.0.92 後,出站數據包直接發送到 10.2.0.92。我不確定客人是否會得到答复。它可能會因為 ARP 在其中回復請求者 MAC。來賓會將該資訊添加到它自己的 ARP 表中。

雖然回復中的主機不會有來賓的 MAC 地址,因為對於主機來說,來賓位於 /24 的衝突域之外。它通常會去網關進行路由,但它也不能這樣做,因為 HOST 網關也不在本地網路中。作為路由器的網關無法將數據包路由回它們進入的線路。數據包需要遍歷設備。如果它可以到達網關,它可能會被丟棄。

我發現更有趣的是它有時會起作用。網路遮罩、廣播和衝突域都只影響數據包的發送者,而不影響它們的接收者。可能是因為來賓是主機上的虛擬事物,一些數據包正在通過虛擬交換機並被看到。

引用自:https://serverfault.com/questions/1008011