Dec 13, 2023

1625

IPTables für eine Bridge

Hallo Zusammen,

ich habe folgendes Setup:

DSL --- DSL Modem --- Ethernet --- Debian mit Bridge --- Ethernet --- CPE

Auf dem Debian Client sind 3 Interfaces. enp0s3 als Management, enp0s8 als link zum DSL Modem, enp0s9 als link zum CPE.

enp0s8 und enp0s9 habe ich gebrückt.

auto enp0s3
iface enp0s3 inet dhcp

auto enp0s8
iface enp0s8 inet manual

auto enp0s9
iface enp0s9 inet manual

auto br0
iface br0 inet dhcp
        bridge_ports enp0s8 enp0s9

Nun wollte ich mit iptables filter auf br0 einbauen, bekomme es aber nicht hin, dass die Regeln angwendet werden.
Z.B.: iptables -A (INPUT od. FORWARD) -m physdev --physdev-(in oder out) enp0s8 -p udp --sport 53 -j DROP

Wie kann ich iptable Regel für eine Bridge anwenden?

Vielen Dank für eure Vorschläge!

Please also mark the comments that contributed to the solution of the article

Content-Key: 6730708456

Url: https://administrator.de/contentid/6730708456

Printed on: April 27, 2024 at 23:04 o'clock

19 Comments

Latest comment

Hallo,
ich denke, das sollte an sich schon so klappen. Die Regel ist aber falsch. Du filterst den Source-Port, willst doch aber die DNS-Anfrage zum Destination-Port filtern, oder?

Also mach aus dem --sport 53 ein --dport 53 und schau dann mal.

Viele Grüße, commodity

Ist mit "DSL Modem" wirklich ein reines NUR Modem ala Vigor 167 oder Zyxel VMG3006 gemeint oder wurde hier wieder laienhaft Modem und Router verwechselt?

Technisch ist es bekanntlich ein großer Unterschied ob nur Modem oder Router!

Das Interface auf das du dein Regelwerk gebunden hast ist ebenso falsch. Das sollte natürlich das "br0" Interface sein und nicht eines der physischen Memberinterfaces wie bei dir! 🧐
Zum Rest hat Kollege @commodity schon alles gesagt. Wenn man mal davon absieht das iptables ein totes Pferd ist und man besser nur noch nftables nutzen sollte.

Das sollte natürlich das "br0" Interface sein ...

Darüber bin ich auch gestolpert, aber ich habe ihn so verstanden, dass er nicht das gesamte Interface filtern wollte, sondern nur einzelne physische Devices, die auf der Bridge liegen. Das müsste doch im Prinzip gehen, ist aber wahrscheinlich nur in VLAN-Szenarien sinnvoll. Bei einer physischen Bridge wohl eher nicht. Ich habe aber auch schon gesehen, dass Leute mehrere Netze ungetrennt über eine Bridge laufen lassen. Vielleicht ist das so ein Fall.

Viele Grüße, commodity

Hi, danke erstmal für eure Antworten.

Ist mit "DSL Modem" wirklich ein reines NUR Modem ala Vigor 167 oder Zyxel VMG3006 gemeint

Ich nutze einen Speedport Smart 3 im Modem-Modus.

Das sollte natürlich das "br0" Interface sein

Das hatte ich ursprünglich versucht: iptables -I FORWARD -i br0 -p udp --sport 53 -j DROP
Hat leider auch nicht geklappt und googlen brachte mich dann zu -m physdev

Du filterst den Source-Port, willst doch aber die DNS-Anfrage zum Destination-Port filtern, oder?

Nein, tatsächlich will ich die DNS Query Response, also die Antwort filtern.

Eine weitere Frage: Muss ich denn dem br0 eine IP geben? Oder könnte ich hier auch manual konfigurieren?

Hat leider auch nicht geklappt

So oder so, wie gesagt, im --sport lag das Problem.

Muss ich denn dem br0 eine IP geben?

Wenn Du die Bridge als Interface nutzt: IMO ja, wie soll sie sonst kommunizieren?

Viele Grüße, commodity

So oder so, wie gesagt, im --sport lag das Problem.

Nein, ich möchte ja die Antwort vom DNS Server filtern, also Source Port 53.

Ich habe jetzt mal testweise alles droppen lassen:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere 

Und trotzdem fliegen munter die Queries und Responses über die Bridge..

Aus dieser Quelle ergeben sich folgende Ansätze:

1. Kernel-Version
2. br_netfilter aktiviert
3. net.bridge.bridge-nf-call-iptables in sysctl.conf gesetzt?

Viele Grüße, commodity

1. Kernel-Version

6.1.0-15-amd64

2. br_netfilter aktiviert

Ja - bridge 311296 1 br_netfilter

3. net.bridge.bridge-nf-call-iptables in sysctl.conf gesetzt?

Ja - net.bridge.bridge-nf-call-iptables = 1

Lösung war aber noch folgende sysctl Parameter zu setzen:

net.bridge.bridge-nf-filter-pppoe-tagged = 1
net.bridge.bridge-nf-filter-vlan-tagged = 1
net.bridge.bridge-nf-pass-vlan-input-dev = 1

Eine weitere Frage: Muss ich denn dem br0 eine IP geben?

Ja, natürlich! Wenn der Server selber im IP Netz des Bridge Interfaces kommunizieren soll oder muss dann liegt seine IP logischerweise immer auf dem Bridge Interface und niemals auf einem der physischen Member Interfaces der Bridge!

Danke für dein Rückmeldung aqui, aber in meinem Fall muss das der Server nicht, da er nur die Pakete welche über die Bridge gehen manipulieren soll. Und das geht auch, wenn ich der br0 keine IP gebe.

gern geschehen

Viele Grüße, commodity

Hi, ich habe noch mal eine Frage zu diesem Thema hier. Und zwar sehe ich, dass manchmal TCP Verbindungen nicht funktionieren. Wenn ich den Debian Client mit der Bridge herausnehme und das CPE direkt mit dem ext. Modem verbinde, funktioniert alles. Gibt es Einstellungen, die ich am Debian Client noch vornehmen muss, damit die Bridge nicht diesen Fehler erzeugt?

Machst du PPP oder PPPoE am CPE also irgendwas was einen größeren header Overhead hat und damit zu MTU Problematiken führt?
Das Fehlerbild ist klassisch für MTU Fehler mit zu großen MTU bzw. MSS Settings!

Ja, PPPoE. Ich hab am Debian auch TCP Offloading deaktiviert, aber das hat nichts gebracht?

TCP Offloading hat bekanntlich nichts mit MTU und MSS Settings zu tun! Ist also zu erwarten das das nix bringt.
Hier etwas zu den Basics:
https://www.cisco.com/c/de_de/support/docs/long-reach-ethernet-lre-digit ...

Das CPE ist ein Speedlink 5501, da kann ich keine MTU einstellen. An der Bridge habe ich die MTU runtergedreht, aber es hat nichts gebracht.

MTU ist nur die halbe Miete. Hast du ggf. auch mal die MSS auf dem lokalen Interface angepasst?
https://medium.com/@xpwang/how-to-change-tcp-mss-in-linux-272af59d34b8

Beides zusammen ausprobiert, leider funktioniert es immer noch nicht.
Also MTU via etc/network/interfaces gesetzt und MSS via iptables.

Anbei mal ein Bild vom Traceausschnitt.

Muss ich evtl. am Windows Host, auf dem die Debian VM läuft, etwas einstellen?
Hier habe ich an den USB Netzwerkadaptern alle Elemente bis auf VirtualBox Bridged Network Driver und Npcap Driver deaktivert. Vlt. noch irgendetwas in den erweiterten Eigenschaften?

Lösung hier war es an den USB Ethernet Adaptern Jumbo Frames zu aktivieren.

German solved Question Debian Monitoring Telecommunication

Hotly discussed

End of availability for classic Teams clientDani