Fail2ban kann nur "etwas tun", wenn es von einer Bedrohung (unklare Definition!) Kenntnis erhalten kann. Die Log-Dateien der Dienste, die in einer VM laufen, liegen... in der VM (meist in /var/log/* bzw. im Journal).
Auf dieser Grundlage muss Fail2ban in der VM laufen, der Host kann ja nicht auf die Log-Dateien zugreifen, um sie auszuwerten.
Meine Empfehlung: bleib erstmal bei dieser Konstruktion, auch wenn es nach doppelter Arbeit aussieht.
Dass dies suboptimal ist, ist keine neue Erkenntnis. Und es gibt etliche Ansätze, diese Aufgabe zu zentralisieren. Angefangen von einem zentralen Syslog plus iptables bis zu richtig umfangreichen Funktionen in den eingesetzten Routern wie OpnSense. Jede dieser Lösungen treibt die Komplexität massiv nach oben und ist nicht wartungsfrei - man kann/sollte/muss sich quasi kontinuierlich damit beschäftigen. (Sicherheit ist ein Prozess; kein Produkt, welches man einfach installiert und dann vergessen kann.)
Für ein Homelab sollte man unbedingt die Angriffsfläche so klein wie möglich halten --> so wenig offene Ports wie es geht. Und ja, man kann sich auch komplett unsichtbar machen! Mit einigen, sehr unterschiedlichen Tools (Wireguard vs. Port Knocking vs. xyz) ist das denkbar - zumindest für "private Dienste", die nur von sehr wenigen Nutzern verwendet werden sollen. Diese Idee versagt natürlich zwangsweise für bewusst öffentlich verfügbare Dienste...
