Warum Ihre iptables-Regel gebrückten VPN-Verkehr nie sieht

Zwei virtuelle Maschinen auf demselben Host erreichen das LAN über eine Brücke, und eine Regel in der ip-forward-Kette zeigt einen Zähler, der sich nie bewegt. Die Frames sind echt, der Verkehr fließt, und die Regel liegt einfach nicht auf seinem Weg. Der Vergleich der beiden Arten, wie Linux gebrückten Verkehr sichtbar macht, erklärt diese Stille, und er erklärt auch, warum das Laden eines alten Moduls eine schlechtere Antwort ist, als es aussieht.

Zwei Wege durch einen Host

Ein Paket kann diesen Host auf zwei sehr unterschiedliche Arten verlassen, und der Unterschied entscheidet, welche Hooks es sehen. Liegt das Ziel hinter einem physischen Port und wird der Frame zwischen zwei Brückenports vermittelt, leitet der Host einen Ethernet-Frame weiter; der Routing-Code wird nicht befragt, und es findet kein gerouteter Hop statt. Ist das Ziel der Host selbst oder ein Netz, das über eine Tunnel-Schnittstelle erreicht wird, wird das Paket geroutet, und die Hooks der IP-Schicht greifen tatsächlich. Behalten Sie diese Gabelung im Kopf, denn jede spätere Frage zu Ketten und Familien folgt daraus, welchen der beiden Wege ein Frame nimmt.

Diese Unterscheidung ist die ganze Geschichte hinter einer Regel, die nichts zählt. Ein gebrückter Frame von veth9a1 nach enp3s0 überquert die Brücke, nicht den IP-Stack, daher sieht eine ip forward-Kette nichts zum Abgleichen. Schnittstellennamen in einem älteren Beispiel entscheiden nicht, welchen Weg Sie haben, und deshalb besteht der erste Schritt darin, die Topologie zu betrachten statt das Regelset.

Ein Tunnel fügt einen dritten Fall hinzu, der einen Namen verdient. Ein TUN-Gerät liefert IP-Pakete an den Host, daher werden sie geroutet und durchlaufen tatsächlich IP-Ketten, während ein an eine Brücke angeschlossenes TAP-Gerät Frames liefert und sich wie der gebrückte Fall verhält. Der Gerätetyp, nicht der Produktname, entscheidet.

Vergleichen Sie die beiden Familien, die einen gebrückten Frame sehen können

Linux unterstützt natives Brücken-Filtering über die bridge-Familie von nftables, und es braucht kein Legacy-Modul, um Frames im Flug zu prüfen und zu verwerfen. Die eigene Brückendokumentation des Kernels gibt diese Empfehlung direkt, was man wissen sollte, bevor ein Suchergebnis Ihnen sagt, ein Modul zu laden.

Der nft-Befehl statt iptables platziert für sich genommen keine Regel in der richtigen Familie. Eine in der bridge-Familie deklarierte Kette sieht Frames; eine in ip, ip6 oder inet deklarierte Kette sieht sie nicht, egal welches Binärprogramm sie erzeugt hat. Die Familie ist eine Eigenschaft der Kette, nicht des Werkzeugs, das sie getippt hat.

Der Legacy-Weg funktioniert anders, und deshalb sollte man vergleichen, statt aus Gewohnheit eine Seite zu wählen. Das Laden von br_netfilter und das Aktivieren der bridge-nf-call-Einstellungen macht gebrückten IPv4- und IPv6-Verkehr wieder über die Hooks der IP-Schicht sichtbar, sodass eine gewöhnliche iptables-Regel ihn endlich abgleichen kann. Die Frames ändern sich nicht; die Menge der Hooks, die sie durchlaufen, ändert sich, was bedeutet, dass jede bestehende Host-Regel jetzt ein neues Publikum hat.

Lesen Sie den wirksamen Weg, bevor Sie eine Regel hinzufügen

Drei Befehle stellen fest, wo Sie stehen: woran die Brücke angeschlossen ist, ob das Legacy-Modul aktiv ist und welche Ketten in der bridge-Familie bereits existieren. Führen Sie sie aus, bevor Sie etwas schreiben, denn die Antwort entscheidet, welches der beiden Designs Sie erweitern. Diesen Schritt zu überspringen ist der Weg, auf dem eine korrekte Regel in einer Kette landet, die nichts durchläuft.

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

Die Ausgabe trennt die Fälle sauber. Unter der Brücke gelistete Ports sagen Ihnen, welche Schnittstellen vermittelt werden; ein leeres lsmod-Ergebnis bedeutet gar keine Sichtbarkeit gebrückter Frames auf der IP-Schicht; eine bereits vorhandene forward-Kette der bridge-Familie bedeutet, dass es schon einen Richtlinieneigner gibt und Ihre Regel dorthin gehört statt in eine eigene neue Kette.

Fügen Sie dann eine Regel hinzu, die sich leicht zurücklesen lässt, mit einem Zähler und ohne Änderung des Urteils, und schicken Sie einen einzigen repräsentativen Fluss durch die Brücke. Ein Zähler, der sich bewegt, beweist, dass der Frame die Regel erreicht hat. Mehr beweist er nicht, also folgen Sie ihm auch mit dem verweigerten Weg, denn eine Richtlinie, die alles akzeptiert, erzeugt ebenfalls einen laufenden Zähler.

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Wo das Legacy-Modul das Verhalten ändert

Den Legacy-Weg auf einer laufenden Brücke zu aktivieren ist kein neutraler Akt des Sichtbarmachens. Regeln, die für gebrückten Verkehr zuvor unerreichbar waren, werden erreichbar, einschließlich Host-Regeln, die für eine andere Schnittstelle geschrieben wurden, und eine Standard-Drop-Richtlinie in der ip-forward-Kette kann plötzlich auf Frames greifen, die bisher unberührt passierten. Auf einem Host, der über diese Brücke verwaltet wird, ist das Ergebnis eine Aussperrung ohne Konsole. Das ist kein hypothetischer Fehlerfall; es ist die gewöhnliche Folge davon, eine Hook-Menge auf einer Maschine zu erweitern, die Sie über den gerade erweiterten Weg erreichen.

Die sicherere Reihenfolge ist zu entscheiden, welche Familie die Richtlinie besitzt, die Regeln dort zu schreiben und einen unabhängigen Wiederherstellungsweg zu behalten, bevor irgendein sysctl geändert wird. Halten zwei Familien Regeln, dokumentieren Sie, welche maßgeblich ist; zwei überlappende Richtlinien sind der Weg, auf dem ein Paket an einer Stelle akzeptiert und an einer anderen verworfen wird, ohne eine einzige Datei zum Lesen.

Isolation braucht selbst noch ein vollständiges Design. Einer Quelle den Weg zu einem Ziel zu erlauben beweist nur, dass ein Fluss funktioniert, während die Anforderung meist darin besteht, dass eine VM ihre Nachbarn oder den Host nicht erreichen kann. Zähler auf den Verweigerungsregeln sind wichtiger als der Zähler auf der Akzeptanzregel, weil der Akzeptanzzähler der ist, von dem Sie ohnehin erwartet haben, dass er sich bewegt.

Schließlich halten Sie den Host-Input-Fall getrennt. Verkehr, der an die eigene IP der Brücke adressiert ist, kommt bei input an, nicht bei forward, und eine Regel in forward wird ihn nie sehen, egal welche Familie Sie wählen. Drei Fälle, zwei Familien, eine Lehre: Der Weg entscheidet über den Hook, und der Hook entscheidet, ob Ihre Regel überhaupt existiert.