☰

KVM上のゲストユニカーネルはホストに到達できないが、ホストはゲストに到達できる

tag-icon • tag-icon networking virtual-machine linux-kvm
KVM上のゲストユニカーネルはホストに到達できないが、ホストはゲストに到達できる

私はランプカーネルを作ろうとしています（https://github.com/rumpkernel) は KVM 上で実行され、ホスト上のソケットに接続してデータを送信します。

ここで、nginx の例を使用して、ホストがゲストにアクセスできるようにします。 https://github.com/rumpkernel/wiki/wiki/Tutorial%3A-Serve-a-static-website-as-a-Unikernel

私がやっていることはだいたい次のとおりです:

ip tuntap add tap0 mode tap
ip addr add 10.0.0.10/24 dev tap0
ip link set dev tap0 up

次に、次のパラメータを指定して rumprun を起動します。

rumprun kvm -i -M 128 \
        -I if,vioif,'-net tap,script=no,ifname=tap0'\
        -W if,inet,static,10.0.0.11/24 \
        -b images/data.iso,/data \
        -- <my python script>

Python スクリプトがソケット (0.0.0.0:2010) を開いてリッスンします。次に、ホストで次の操作を実行できます。

nc 10.0.0.11 2010

そして、接続しているのがわかります。問題は、逆のことができないことです。今、kvm ゲストがソケットを開いて接続しようとしています:

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:                                                                                       
   ip = "10.0.0.10"
   try:
       s.connect( (ip, 9999) )
       #send some data

そして、以前と同じようにリッスンする同じスクリプトを実行し、10.0.0.10:9999 にバインドします。ゲストは接続を試行中に停止し、最終的にタイムアウトします。

オンラインで見つけられるほぼすべての方法を試した結果、IP 10.0.0.10 のブリッジを作成し、そこに tap0 を追加しました。次に、br0 をスヌープして次の結果を得ました (いくつかの行を削除しました)。

15:38:46.173914 ARP, Request who-has 10.0.0.11 tell 10.0.0.11, length 28
...
15:38:46.500262 ARP, Request who-has 10.0.0.10 tell 10.0.0.11, length 28
15:38:46.500288 ARP, Reply 10.0.0.10 is-at 0e:ec:XX:XX:XX:XX (oui Unknown), length 28
15:38:46.500440 IP 10.0.0.11.52886 > 10.0.0.10.9999: Flags [S], seq 20858086, win 32768, options [mss 1460,nop,wscale 3,sackOK,nop,nop,nop,nop,TS val 1 ecr 0], length 0

ルートはあると思うのですが、どういうわけかパケットが届きません。sys.d内でフィルタリングを無効にしてみました。

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

そしてまだ何もない。

これを機能させる方法について何かアイデアはありますか? これはリモート サーバーであり、ゲストは現時点では外部接続を必要としないため、eth0 をブリッジしたくありません。

答え1

えっと、これを解決しようと1日試みましたが、もちろんここに質問を投稿した後、答えを見つけました。

ヒントはこれです:ブリッジされた仮想マシンのネットワークアクセスを許可するようにFirewallDを構成する

iptablesとログをチェックしたところ、/var/log/ufw.logに次の内容が見つかりました。

Dec  5 15:38:46 xxxx kernel: [516010.193395] [UFW BLOCK] IN=br0 OUT= MAC=... SRC=10.0.0.11 DST=10.0.0.10 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=

0 DF PROTO=TCP SPT=52886 DPT=9999 WINDOW=32768 RES=0x00 SYN URGP=0

ファイアウォールが動作しており、それが接続をブロックしていたことが判明しました。ここで指定されているように、新しいルールを追加しました: https://help.ubuntu.com/community/UFW そして、今は機能しているようです。

関連情報