firewall-cmd: agregar puerto de reenvío no funciona

Question

EL VERDADERO PROBLEMA:

El comando...

firewall-cmd --permanent --zone=public --direct --add-rule ipv4 filter FORWARD 0 -d 0.0.0.0/0 -j ACCEPT
firewall-cmd --permanent --zone=public --add-forward-port=port=222:proto=tcp:toport=22:toaddr=10.1.0.9
firewall-cmd --reload

... descrito en "ACTUALIZACIÓN II" funciona tan bien como firewalld (utilizado por CentOS 7).

El problema está en el KVM (libvirt) que al iniciar la "red" virbr0 inyecta reglas (probablemente a través de firewalld) que impide (principio de primera coincidencia) cualquier intento de reenvío de puertos por medios convencionales utilizando firewall-cmd. Las reglas inyectadas de KVM (libvirt) se encuentran en la parte superior de FORWARD y POSTROUTING, antes del conjunto de reglas de firewalld normal. Dado que Netfilter funciona según el principio de primera coincidencia, estas reglas.

SOLUCIÓN:

Debido a los problemas generados por las reglas inyectadas por KVM (libvirt) en el firewall, la solución es usar un truco/solución alternativa llamado libvirt-hook-qemu como explicamos a continuación...

Descargue e instale libvirt-hook-qemu...

yum -y install git-core
cd /usr/local/src
git clone https://github.com/saschpe/libvirt-hook-qemu.git
cd libvirt-hook-qemu
make install
cd ..
rm -rf libvirt-hook-qemu

Enumere sus máquinas virtuales (invitadas)...

virsh list --all

... y copie el nombre de la máquina virtual de destino.

Apague la máquina virtual...

virsh shutdown "<VM_NAME>" --mode acpi

Abra el archivo "hooks.json", elimine su contenido...

vi /etc/libvirt/hooks/hooks.json

... e ingresa tus reglas como la plantilla a continuación (son posibles otras formas de configuración)...

{
    "<VM_NAME>": {
        "interface": "virbr0",
        "private_ip": "<VM_IP>",
        "port_map": {
            "tcp": [[<PORT_ON_HOST>, <PORT_ON_GUEST>]]
        }
    }
}

Reinicie libvirtd...

systemctl restart libvirtd.service

... e iniciar la máquina virtual...

virsh start "<VM_NAME>"

¡Hecho! =D

MÁS:

Este comportamiento de KVM (libvirt) - inyecta reglas que impiden cualquier intento de reenvío de puertos - es IMPOSITIVO, INVASIVO E INNECESARIO... Primero, porque como no hay reenvío de puertos en el host, no se podrá acceder a ninguna máquina virtual en la red predeterminada (virbr0). y segundo porque nos obliga a usar un truco/solución alternativa (o "gato"/"gambiarra" como lo llamamos en Brasil =D).

En nuestra opinión no tiene sentido imponer al usuario cómo debe construir su infraestructura o no... ¡Esto no tiene sentido! Para decirlo sin rodeos, creemos que sería mejor si estas configuraciones fueran opcionales (inyecta reglas...) como lo hacen otros hipervisores líderes. Y vamos más allá... Si KVM (libvirt) controla este tipo de cosas, entonces también debería ofrecer formas de asignar puertos a máquinas virtuales.

El KVM (libvirt) es unEXCELENTEherramienta, pero no todos los usuarios están dispuestos, por diversas razones, a colocar sus máquinas directamente en la red de la máquina host, así como no todos los usuarios están dispuestos a renunciar a toda la flexibilidad/accesibilidad que ofrece la red predeterminada (virbr0).

¡Gracias!

[Árbitros.:https://bugzilla.redhat.com/show_bug.cgi?id=846810, https://libvirt.org/firewall.html, https://libvirt.org/formatnetwork.html#examplesRoute, https://saschpe.wordpress.com/2014/03/06/dynamic-iptables-port-forwarding-for-nat-ed-libvirt-networks/, https://serverfault.com/q/170079/276753, https://serverfault.com/q/915257/276753, https://wiki.libvirt.org/page/VirtualNetworking#Routed_mode, https://www.centos.org/forums/viewtopic.php?f=50&t=71454&sid=7f5190a29eebbf755235ec3dc404a47f, https://www.cyberciti.biz/faq/kvm-forward-ports-to-guests-vm-with-ufw-on-linux/]

ACTUALIZAR:

inyecta reglas que impiden cualquier intento de reenvío de puertos

-> ¡El flujo ascendente actual de KVM (libvirt) ha resuelto el problema!

Mira esto: ...La corriente ascendente actual de KVM (libvirt) ha resuelto el problema....

Answer 1