Firewall je Gast

Warum der Host tabu ist

Jede Firewall-Oberfläche, die die Regeln des Hosts bearbeiten kann, kann an einem schlechten Nachmittag auch den Port schließen, auf dem man gerade sitzt. Dann ist die Maschine in Ordnung, der Dienst ist in Ordnung, und niemand kommt hinein, um es zu richten.

Das Regelwerk des Hosts ist hier deshalb eine reine Ansicht. Zeigen lohnt sich — eine Regel weiter oben kann erklären, warum ein Gast nicht erreichbar ist —, bearbeiten aus einer Browsersitzung heraus, die dieselbe Regel beenden könnte, nicht.

Dieselben Regeln für beide Gastarten

Eine VM und ein Container bekommen dieselben Regeln. Der Weg zum Gerät unterscheidet sich: Bei einer VM steht der Filter in der Schnittstelle ihrer libvirt-Domain und greift beim Start; ein Container ist keine libvirt-Domain, also wird der Filter direkt an das veth-Gerät auf der Hostseite gebunden.

Eine solche Bindung lebt nur so lange wie das Gerät — sie verschwindet beim Stoppen, und der Start setzt sie neu. Darum kümmert sich Phillux, statt es dem Betrieb zu merken zu geben.

Was daraus darunter wird

libvirt macht aus den Filtern ebtables- und iptables-Regeln. Ein Filter, den ein laufender Gast benutzt und der neu definiert wird, wird sofort nachgezogen; nur das erste Anhängen braucht ein Geräte-Update oder eine neue Bindung.

Eine Auffangregel braucht ihren Verbindungszustand ausgeschrieben, und DHCP braucht seine beiden UDP-Ports ausdrücklich — ein Regelwerk, das nur „bestehende“ Verbindungen zulässt, lässt einen Gast laufen und nie eine Adresse bekommen.

Wo der Filter nicht dazwischensteht

Verkehr vom Host selbst zu einem Gast läuft nicht durch diesen Filter. Er verlässt den Netzwerkstapel des Hosts nie, es gibt also kein Gerät, auf dem die Regel sitzen könnte.

Das steht hier, statt später entdeckt zu werden: Eine Prüfung, die vom Host aus funktioniert, beweist nicht, dass irgendetwas sonst im Netz den Gast erreicht.