☰

El unikernel invitado en KVM no puede comunicarse con el host, pero el host puede comunicarse con el invitado

tag-icon • tag-icon networking virtual-machine linux-kvm
El unikernel invitado en KVM no puede comunicarse con el host, pero el host puede comunicarse con el invitado

Estoy tratando de hacer un rumpkernel (https://github.com/rumpkernel) se ejecuta en KVM, se conecta a un socket en el host y envía algunos datos.

Puedo hacer que el anfitrión acceda al invitado usando el ejemplo de nginx aquí: https://github.com/rumpkernel/wiki/wiki/Tutorial%3A-Serve-a-static-website-as-a-Unikernel

Básicamente lo que hago es:

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

Luego inicie rumprun con los parámetros:

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>

Donde el script de Python abre un socket (0.0.0.0:2010) y escucha. Luego en el host puedo hacer:

nc 10.0.0.11 2010

Y puedo verlo conectándose. El problema es que no puedo hacer al revés. Ahora tengo al invitado kvm abriendo un socket e intentando conectarse:

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

Y ejecutando el mismo script que escucha como antes, vinculando 10.0.0.10:9999. El invitado simplemente se queda atascado al intentar conectarse y finalmente se agota el tiempo de espera.

Probé casi todo lo que pude encontrar en línea, terminé con un puente con IP 10.0.0.10 y le agregué tap0. Luego espié a br0 y obtuve lo siguiente (eliminé algunas líneas):

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

Lo que me hace pensar que hay una ruta, pero de alguna manera el paquete no llega. Intenté deshabilitar el filtrado dentro de sys.d

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

Y todavía nada.

¿Alguna idea sobre cómo hacer que esto funcione? No quiero conectar mi eth0 porque es un servidor remoto y el invitado no necesita conexiones externas en este momento.

Respuesta1

Bueno, he estado tratando de resolver esto durante un día y, después de publicar una pregunta aquí, encuentro la respuesta.

La pista estaba en esto:Configure FirewallD para permitir el acceso a la red de máquinas virtuales en puente

Revisé iptables y logs y encontré esto en /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 VENTANA=32768 RES=0x00 SYN URGP=0

Resulta que hay un firewall ejecutándose y estaba bloqueando la conexión. Agregué una nueva regla como se especifica aquí: https://help.ubuntu.com/community/UFW y está funcionando ahora. Aparentemente.

información relacionada