web-dev-qa-db-ja.com

KVM静的IPの緩いネットワーク接続を備えたQEMUVM

私はKVM/QEMUホストとゲスト（VM）の両方を実行してセットアップUbuntu 18.04 LTS with bridged networking。 VMは、静的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を持つVMは一種のアイドル状態になります。そのため、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を備えたVMには問題はありません。それはいつでもうまく接続します、

$ 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 statevirshをクエリすると。

networkinglinux-networkingkvm-virtualizationubuntu-18.04
1
jaks

私が見ているかなり基本的な問題の1つは、br0のゲートウェイがアドレススコープ内にないことです。/23ではなく/ 24を定義します。

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

/ 24を/ 2に変更するだけです。

10.2.0.92/23は、VM内のホストと同様に、10.2.0.0から10.2.1.255を含みます。問題はスペースの重複ではありませんが、/ 24を使用すると、ホストがホストゲートウェイに到達できなくなります。

ゲストからpingを実行する場合->ホスト...ホストが現在の[〜＃〜] netmask [〜＃〜]内にあるため、パケットはゲストを離れ、ブロードキャストされます。ゲストのネットワーク。ホストはパケットを受信します。ホストは返信を送信します。 x.x.1.xの宛先はx.x.0.xの現在のネットワーク上にないため、パケットは通常、ゲートウェイにルーティングされます。待ってください、ゲートウェイもx.x.0.x上にありません。パケットはどこにも行きません。

パケットはスマートではないことを忘れないでください。彼らはあなたが彼らに言うところに正確に行くだけです。

私が上でカバーしなかったこれの一部はARPです。上記の@Gerritのコメントは、それにも対応しています。パケットがコリジョンドメイン内で送信される場合、パケットはIPではなくMACアドレスで送信されます。 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テーブルに追加します。

ただし、ホストの場合、ゲストは/ 24の衝突ドメインの外側にあるため、ホストは応答時にゲストのMACアドレスを持ちません。通常はゲートウェイに移動してルーティングされますが、ホストゲートウェイもローカルネットワークにないため、ルーティングできません。ルーターであるゲートウェイは、着信したネットワークにパケットをルーティングして戻すことはできません。パケットはデバイスを通過する必要があります。ゲートウェイに到達できたとしたら、おそらくドロップされるでしょう。

私がもっと面白いと思うのは、それが時々機能するということです。ネットマスク、ブロードキャスト、および衝突ドメインはすべて、パケットの受信者ではなく、パケットの送信者にのみ影響します。おそらく、ゲストはホスト上の仮想的なものであり、一部のパケットが仮想スイッチを通過して表示されているためです。

0
Rowan Hawkins