Firewall-Eingabeaufforderung – Add-Forward-Port funktioniert nicht

Question

DAS WIRKLICHE PROBLEM:

Der Befehl...

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

... beschrieben in „UPDATE II“, funktioniert genauso gut wie Firewalld (wird von CentOS 7 verwendet).

Das Problem liegt in der KVM (libvirt), die beim Starten des „Netzwerks“ virbr0 Regeln einfügt (wahrscheinlich über Firewalld), die (First-Match-Prinzip) jeden Versuch der Portweiterleitung auf herkömmliche Weise unterbinden firewall-cmd. Die von der KVM eingefügten (libvirt) Regeln stehen am Anfang von FORWARD und POSTROUTING, vor dem regulären Firewalld-Regelsatz. Da der Netfilter nach dem First-Match-Prinzip arbeitet, gelten diese Regeln.

LÖSUNG:

Aufgrund der Probleme, die durch die von KVM (libvirt) in die Firewall eingefügten Regeln verursacht werden, besteht die Lösung darin, einen Hack/Workaround namens libvirt-hook-qemu zu verwenden, wie wir unten erläutern …

Laden Sie libvirt-hook-qemu herunter und installieren Sie es …

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

Listen Sie Ihre virtuellen Maschinen (Gäste) auf …

virsh list --all

… und kopieren Sie den Namen der Ziel-VM.

Schalten Sie die virtuelle Maschine aus ...

virsh shutdown "<VM_NAME>" --mode acpi

Öffnen Sie die Datei „hooks.json“, löschen Sie ihren Inhalt …

vi /etc/libvirt/hooks/hooks.json

... und geben Sie Ihre Regeln als Vorlage unten ein (andere Einrichtungsmöglichkeiten sind möglich)...

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

Starten Sie libvirtd neu …

systemctl restart libvirtd.service

... und starten Sie die virtuelle Maschine...

virsh start "<VM_NAME>"

Fertig! =D

WEITER:

Dieses KVM-Verhalten (libvirt) – fügt Regeln ein, die alle Versuche der Portweiterleitung verhindern – ist UNWIRKSAM, INVASIV UND UNNÖTIG … Erstens, weil keine virtuelle Maschine im Standardnetzwerk (virbr0) erreichbar ist, da auf dem Host keine Portweiterleitung vorhanden ist, und zweitens, weil es uns zwingt, einen Hack/Workaround (oder „gato“/„gambiarra“, wie wir es in Brasilien nennen =D) zu verwenden.

Unserer Ansicht nach macht es keinen Sinn, dem Benutzer vorzuschreiben, wie er seine Infrastruktur aufbauen soll oder nicht... Das macht keinen Sinn! Um es ganz deutlich zu sagen: Wir denken, es wäre am besten, wenn diese Einstellungen optional wären (Regeln einfügen...), wie es bei anderen führenden Hypervisoren der Fall ist. Und wir gehen noch weiter... Wenn KVM (libvirt) diese Art von Dingen steuert, sollte es auch Möglichkeiten bieten, Ports virtuellen Maschinen zuzuordnen.

Der KVM (libvirt) ist einGROSSARTIGTool, aber nicht alle Benutzer sind – aus verschiedenen Gründen – bereit, ihre Maschinen direkt in das Netzwerk der Hostmaschine einzubinden, genauso wie nicht alle Benutzer bereit sind, auf die gesamte Flexibilität/Zugänglichkeit zu verzichten, die das Standardnetzwerk (virbr0) bietet.

Danke!

[Schiedsrichter.: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/]

AKTUALISIEREN:

fügt Regeln ein, die jeden Versuch der Portweiterleitung verhindern

-> Der aktuelle Upstream von KVM (libvirt) hat das Problem gelöst!

Sieh dir das an: ...Der aktuelle Upstream von KVM (libvirt) hat das Problem behoben...

Answer 1