throw732849
Goto Top

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!

Content-ID: 6730708456

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

Printed on: December 14, 2024 at 17:12 o'clock

commodity
commodity Dec 13, 2023 updated at 16:07:03 (UTC)
Goto Top
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? face-smile

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

Viele Grüße, commodity
aqui
aqui Dec 13, 2023 updated at 16:58:53 (UTC)
Goto Top
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? face-sad
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.
commodity
commodity Dec 13, 2023 at 18:39:35 (UTC)
Goto Top
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
throw732849
throw732849 Dec 13, 2023 at 19:07:23 (UTC)
Goto Top
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?
commodity
commodity Dec 13, 2023 at 19:18:41 (UTC)
Goto Top
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
throw732849
throw732849 Dec 13, 2023 at 19:47:21 (UTC)
Goto Top
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..
commodity
commodity Dec 13, 2023 at 20:40:06 (UTC)
Goto Top
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
throw732849
Solution throw732849 Dec 14, 2023 at 10:13:40 (UTC)
Goto Top
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
aqui
aqui Dec 14, 2023 updated at 10:17:54 (UTC)
Goto Top
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!
throw732849
throw732849 Dec 14, 2023 at 10:24:13 (UTC)
Goto Top
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.
commodity
commodity Dec 14, 2023 at 13:09:32 (UTC)
Goto Top
gern geschehen face-wink

Viele Grüße, commodity
throw732849
throw732849 Jan 18, 2024 at 12:10:18 (UTC)
Goto Top
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?
aqui
aqui Jan 18, 2024 at 12:16:05 (UTC)
Goto Top
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!
throw732849
throw732849 Jan 18, 2024 at 12:31:07 (UTC)
Goto Top
Ja, PPPoE. Ich hab am Debian auch TCP Offloading deaktiviert, aber das hat nichts gebracht?
aqui
aqui Jan 18, 2024 at 13:09:59 (UTC)
Goto Top
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 ...
throw732849
throw732849 Jan 19, 2024 at 07:04:53 (UTC)
Goto Top
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.
aqui
aqui Jan 19, 2024 at 08:34:05 (UTC)
Goto Top
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
throw732849
throw732849 Jan 23, 2024 at 09:08:52 (UTC)
Goto Top
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?
unbenannt
throw732849
Solution throw732849 Jan 29, 2024 at 10:26:56 (UTC)
Goto Top
Lösung hier war es an den USB Ethernet Adaptern Jumbo Frames zu aktivieren.