VLANs und der Freifunk-Knoten: Bitte um Review (Achtung: Lang und Chaotisch!)

Technik Gluon
1

Eins vorneweg: Ja, ich weiß, dass das alles viel komplizierter ist als es eigentlich™ sein müsste™. Aber es geht hierbei auch zu einem nicht unerheblichen Teil um den Lerneffekt.

Ich trenne den Netzwerkverkehr im Hause in verschiedene VLANs auf. Hieraus ergibt sich beispielsweise, dass die Freifunk-Nodes nicht in demselben VLAN sind, in dem sich meine “normalen” Clients befinden.

Ich möchte das Radio des Freifunk-Knotens benutzen, um kabellose Clients in diese VLANs verbinden zu können, ohne dabei irgendeine Sicherheitslücke zu generieren, sprich Clients nicht zu ermöglichen, mithilfe des FFRN-Routers die VLAN-Grenzen zu überwinden.

Eigentlich™ brauche ich nur Layer-2-Brücken. IP-Forwarding wird nicht benutzt.

Problemformulierung

Konfiguriere einen FFRN-Node so, dass er

  1. am WAN-Port ausschließlich 802.1Q-VLAN-Tagged “spricht”
  2. auf Wireless-Seite verschiedene SSIDs ausspielt, die auf die jeweiligen VLANs gebrückt werden, ohne dass der Node selbst Traffic auf diesen VLANs generiert oder annimmt
  3. Mesh-On-VLAN auf dem WAN-Port durchführt
  4. Es nicht möglich ist, den FFRN-Node als Relay zu benutzen (Ein Client, der WLAN-Zugriff auf VLAN 123 oder freifunk-rhein-neckar.de hat, darf nicht in der Lage sein, Pakete an VLAN 234 zu senden)

Damit ich nicht versehentlich beim Herauskopieren der Konfigurationen eine Nummer beim Umschreiben vergesse, benutze ich hier die tatsächlichen VLAN Nummern.

Folgende VLANs existieren im Umfeld der FFRN Nodes:

  • 201 mein normales Clientnetz
  • 269 spezielles restricted Clientnetz
  • 301 FFRN-Uplink: Internetzugriff und DHCP-Server
  • 302 B.A.T.M.A.N. der FFRN-Nodes untereinander
  • 303 FFRN-Clientnetzwerk

Es benutzen nicht alle Nodes alle VLANs, so verbindet z.B. nur der Offloader das VLAN 303.

Natürlich soll es keine Möglichkeit geben für einen Client, die VLAN-Grenzen zu überschreiten. Hierum dreht sich auch das “Ich hätte gerne ein weiteres paar Augen”.

Ideal wäre natürlich, wenn es eine Möglichkeit gäbe, die Bridge so zu konfigurieren, dass der Node selbst keinen Port hat, analog zu vielen Managed Switches, bei denen man definieren kann, an welche VLANs die CPU angehängt wird – wenn man die CPU nicht anhängt, sieht Linux die Pakete nie und kann daher auch nicht mit dem VLAN interagieren oder irgendwelche Sicherheitslücken aufmachen.

Wenn hierzu jemand eine Lösung hat, die unter LEDE funktioniert, bitte direkt senden und den Rest des Beitrags ignorieren.

(Das Programm /sbin/bridge aus iproute2 kann sowas wohl, ist aber nicht im ffrn-Image vorhanden)

Was ich bisher gemacht habe

Anpassungen an die Stock-Konfiguration

Damit die Nodes auf der WAN-Seite VLAN sprechen, habe ich nur ein Suffix an das Ethernet-Interface angehängt (aus eth1 mach eth1.301):

uci set network.wan.ifname=eth1.301
uci set network.mesh_wan.ifname=eth1.302
uci commit network
/etc/init.d/network restart

FIXME: Ist das Upgrade-sicher?

Um Broadcast-Wahnsinn zu vermeiden, habe ich manuell den mesh_no_rebroadcast Parameter gesetzt, bevor ich das Mesh-On-VLAN aktiviert habe:

uci set network.mesh_wan.mesh_no_rebroadcast=1
uci set network.mesh_wan.auto=1
uci commit network
/etc/init.d/network restart

FIXME: Ist das in der aktuellen Firmware noch nötig, oder erkennt LEDE, dass hier auf Ethernet gemesht wird? [ist das “korrektes” Denglisch?]

Erstellung eigene Bridge

Ich habe mit uci eine weitere Bridge erstellt, die mit dem VLAN brückt. Allerdings sendet der Node dann im privaten VLAN.

Danke an @hax404 für den Tipp, IPv6 einfach abzuschalten. Danach hatte der Node immer noch Pakete ausgesendet, mit IPv4 IGMP. Aus der OpenWRT-Doku habe ich den Parameter igmp_snooping, den ich deakviert habe.

uci show network.private:

network.private=interface
network.private.type='bridge'
network.private.ifname='eth1.201'
network.private.ipv6='0'
network.private.igmp_snooping='0'

Zunächst habe ich einfach das bereits vorkonfigurierte wireless.wan_radio0 auf die neue Bridge umbenannt:

uci set wireless.wan_radio0.network=private
uci commit wireless
wifi

Für das zweite WLAN, das auf VLAN 269 gebrückt werden soll, habe ich ein komplett neues Interface angelegt und entsprechend konfiguriert:

uci show network.res269
network.res269=interface
network.res269.type='bridge'
network.res269.ifname='eth1.269'
network.res269.ipv6='0'
network.res269.igmp_snooping='0'

uci show wireless.res269_radio0
wireless.res269_radio0=wifi-iface
wireless.res269_radio0.device='radio0'
wireless.res269_radio0.encryption='psk2'
wireless.res269_radio0.mode='ap'
wireless.res269_radio0.network='res269'
wireless.res269_radio0.key='<zensiert>'
wireless.res269_radio0.ssid='WLAN-269'

Eins vorneweg: “Funktionieren” tut es. Es geht mir hier mehr um die Frage, ob es einem Streßtest bzw. Angriff standhalten könnte oder wie ich diesen selbst gestalten könnte.

An alle, die den Mut hatten, bis hierhin weiterzulesen und sich ein wenig mit OpenWrt/LEDE’s Konfiguration auskennen:

  • Seht ihr offensichtliche Sicherheitsprobleme?
  • Muss ich IP-Firewall-Regeln erstellen?
  • Kann ich IP-Forwarding komplett deaktivieren? (der Node soll ja nur Layer 2 weiterleiten) [wenn ja, wie?]

Falls hier ein Konsens entsteht, wie ein FFRN-Node korrekt in eine 801.1Q-VLAN-Infrastruktur integriert wird, würde ich versuchen, eine Wiki-Seite daraus zu basteln. Die Grundidee ist nämlich auch für einen Offloader sehr praktisch, da physikalisch nur ein externes Interface benötigt wird, sowie insbesondere bei VMs keine Vertauschungsmöglichkeit der Interfaces besteht.

Schonmal vielen Dank für eure Einsichten im Voraus,

Danny

1 „Gefällt mir“