[gelöst] bridge (WLAN-LAN) und iptables, hostapd, dnsmasq

[smutbert]

Hi,

hab da mal ein kleines Bündel Verständnisfragen, weil ich mir nicht auf Anhieb durch Herumprobieren meine Netzwerkverbindungen zerschießen will


Wenn ich eine Bridge erstelle, habe ich erst einmal nur ein virtuelles Netzwerkinterface, das ich beliebig mit IP-Adresse, DNS-Server, Gateway konfigurieren kann?

Eine normale Ethernetschnittstelle kann ich dann direkt zu dieser Bridge hinzufügen?
Ein WLAN-Interface muss ich zuerst mit wpa_supplicant „versorgen“ und kann es dann genauso hinzufügen?
dnsmasq würde ich dann auf dem bridge-Interface lauschen lassen, hostapd aber auf dem WLAN-Interface?
Das müsste dann schon genügen, dass WLAN-Clients mit über Ethernet angeschlossenen Systemen miteinander reden können?

Stimmt es bis hierher oder stelle ich mir das schon zu einfach vor?

lg smutbert

[BenutzerGa4gooPh]

Eine normale Ethernetschnittstelle kann ich dann direkt zu dieser Bridge hinzufügen?
Ein WLAN-Interface muss ich zuerst mit wpa_supplicant „versorgen“ und kann es dann genauso hinzufügen?
...
Das müsste dann schon genügen, dass WLAN-Clients mit über Ethernet angeschlossenen Systemen miteinander reden können?

Zur Linux-Bridge kann ich dir keine Auskunft geben, rate nur, dies nicht zu tun, geroutet (unterschiedliche IP-Subnetze für LAN und WLAN) hättest du Vorteile:
- bei Bedarf Regeln/Iptables auf OSI-Layer3/IP möglich
(Die Firewall-Distribution ipfire "steckt" WLAN extra in Sicherheitszone "Blau", um bei Bedarf Traffic einschränken zu können.)
- Broadcasts "schwappen" nicht vom Gigabit-Ethernetsegment in's bandbreitenarme WLAN. (Im Heimnetz eher halb so wild.)

[MSfree]

Wenn ich eine Bridge erstelle, habe ich erst einmal nur ein virtuelles Netzwerkinterface, das ich beliebig mit IP-Adresse, DNS-Server, Gateway konfigurieren kann?

Ja, die kann man statisch oder per DHCP mit den nötigen Daten versorgen.

Eine normale Ethernetschnittstelle kann ich dann direkt zu dieser Bridge hinzufügen?

Ja. Eine Bridge muß aber, so weit ich weiß, immer mindestens eine Netzwerkschnittstelle haben, eine leere Bridge, der man erst später Schnittstellen zufügt, funktioniert nicht.

Ein WLAN-Interface muss ich zuerst mit wpa_supplicant „versorgen“ und kann es dann genauso hinzufügen?

Jein. wpa_supplicant und hostapd auf der selben Schnittstelle schließen sich gegenseitig aus. Entweder, du konfigurierst das WLAN als Master (hostapd) und fügst es zur Bridge hinzu, oder du konfigurierst es als Client (wpa_supplicant).

dnsmasq würde ich dann auf dem bridge-Interface lauschen lassen

Ja.

hostapd aber auf dem WLAN-Interface?

Im Prinzip ja, aber beachte bitte den Hinweis bezüglich hoastapd und wpa_supplicant oben.

Das müsste dann schon genügen, dass WLAN-Clients mit über Ethernet angeschlossenen Systemen miteinander reden können?

Ja.

[smutbert]

Danke!
Es hat auf Anhieb funktioniert (wenn man vom vergessenen Netzwerkkabel absieht ).

@Jana
Als Dauerlösung war es eh nicht gedacht – allerdings habe ich gelesen, dass der Netzwerkverkehr der Brücke per default auch die IP-Filter passieren muss.
Eigentlich wäre nämlich meine nächste Frage gewesen, wie genau das mit iptables funktioniert, vor allem ob ich mich da um alle drei Interfaces kümmern müsste (die beiden physischen und die Bridge) oder nur um die Bridge...

[BenutzerGa4gooPh]

Als Dauerlösung war es eh nicht gedacht – allerdings habe ich gelesen, dass der Netzwerkverkehr der Brücke per default auch die IP-Filter passieren muss.

Eigentlich nur der Traffic, der die Brücke verlässt/verlassen muss (Broadcasts + Traffic zu unbekannten/remote MAC-Adressen). Zwischen den gebridgten IFs wird's Regeln deshalb problematisch, man kann vielleicht auf MAC-Adress-Ebene was machen. Wenn irgendwelches Broadcast-Geraffel (DLNA) vorhanden und zwischen LAN <-> WLAN gebridget wird, ein Vorteil - für "Nicht-Aluhüte".

... vor allem ob ich mich da um alle drei Interfaces kümmern müsste (die beiden physischen und die Bridge) oder nur um die Bridge...

Theroretisch wäre der "Bridge-Uplink" zum System (mit beliebig vielen physischen, bridged Interfaces) von OSI-Layer-3/IP gesehen, ein Netzwerk, ein Interface. So wie der Uplink eines dummen Switch zum Router (hier wohl Kernel) eben. Per iptables müsstest du dich also um den "Sammelanschluss/Uplink" der Bridge und in der Bridge nicht enthaltene (geroutete) Interfaces kümmern. Oder so: Kümmere dich (zumindest erst mal) um alles, was unterschiedliche IP-Subnets besitzt. (Sollte innerhalb einer Bridge nicht der Fall sein. Von irgendwelchen Tricksereien mal abgesehen.) MAC-Filter sind eh unbeliebt, Doku?!

... wie genau das mit iptables funktioniert ...

Ich verweise wiederum auf andere, ich schreibe aus allgemeiner Netzwerksicht.
Ein Switch ist auch "nur" eine Multiport-Bridge: https://de.wikipedia.org/wiki/Switch_(Netzwerktechnik) Wie Linux Bridging genau/intern handhabt, weiß ich nicht. Bin mehr für per Kabel getrennte Büchsen, demzufolge standardisierte Schnittstellen. Linux als Router ist recht eindeutig, verbreitet.

[MSfree]

allerdings habe ich gelesen, dass der Netzwerkverkehr der Brücke per default auch die IP-Filter passieren muss.
Eigentlich wäre nämlich meine nächste Frage gewesen, wie genau das mit iptables funktioniert, vor allem ob ich mich da um alle drei Interfaces kümmern müsste (die beiden physischen und die Bridge) oder nur um die Bridge...

Du kannst mit iptables auch zwischen LAN und WLAN filtern, siehe hier:
http://www.linux-magazin.de/ausgaben/20 ... bruecke/2/#
Der Trick ist, die eigentlichen Schnittstellen zu matchen, z.B.

Code: Alles auswählen

-m physdev --physdev-in eth0 --physdev-out eth1

liefert die nötigen Zutaten.

[smutbert]

[BenutzerGa4gooPh]

Du kannst mit iptables auch zwischen LAN und WLAN filtern, siehe hier:
http://www.linux-magazin.de/ausgaben/20 ... bruecke/2/#
Der Trick ist, die eigentlichen Schnittstellen zu matchen ...

Ein schöner Beitrag, Frau hat dazugelernt. Bridge Walling = Transparente Firewall.

Im Beitrag wird diese als Notlösung für gewachsene Netzwerke oder Heimnetze mit 1 Subnetz dargestellt. Der eigentliche Einsatz dürfte wohl in Firmennetzwerken mit mehreren internen Routern bzw. Layer-3-Switches erfolgen, die internen Verkehr routen und mittels Paketfiltern diesen regeln, und die transparente FW kümmert sich "nur" um den Verkehr von/zum Internet - mit 2 Ports im Uplink. Site-to-site-VPNs müssten dann mit anderer, zusätzlicher Technik bereitgestellt werden.

[ingo2]

Du kannst mit iptables auch zwischen LAN und WLAN filtern, siehe hier:
http://www.linux-magazin.de/ausgaben/20 ... bruecke/2/#
Der Trick ist, die eigentlichen Schnittstellen zu matchen, z.B.

Code: Alles auswählen

-m physdev --physdev-in eth0 --physdev-out eth1

liefert die nötigen Zutaten.

Das ist eigentlich genau das, was ich gerne auf meinem APU.2 mit 3 Ethernet-Interfaces einrichten würde.
Entspricht wohl dem, was z.B. Zyxel bei meinem WLAN-AP als "Layer 2 isolation" bezeichnet: ein "routing" auf Basis von MAC-Adressen.
Gibt es dafür auch eine "Bauanleitung" oder auch ein einfach zu handhabendes (Web)-Interface, oder gar eine dezidierte Distribution. Das ganze ist ja dann wohl per Definition auch unabhängig von IPv4 und IPv6 (ebtables, arptables) und nutzt nur die Interfaces als Merkmal. Mit iptables könnte man dann gezielt IPv4-Löcher in die Firewall bohren und mit ip6tables das gleiche für IPv6?
Oder verstehe ich das falsch ???

Gruß,
Ingo