Netzwerk-Konfiguration
Diese Artikel fasst die Überlegungen zur Netzkonfiguration vom 5. Mai 2011 zusammen. Er dient als Diskussionsgrundlage und kann später als Grundlage für die Dokumentation des Netzes verwendet werden. Ziel des Netzlayouts ist es, die definierten Anforderungen einfach und stabil umzusetzen. Er betrifft insbesondere die OSI-Schichten 2 und 3.
Einleitung
In Köln, Bonn und Umgebung (KBU) soll freies, Wireless-Lan Netz entstehen. Vorlage sind andere Freifunk Mesh-Netze [1], wie sie Beispielsweise in Berlin, Jena (usw. existieren). In diesen Netzen operieren Nodes typischer Weise im ad-hoc Modus. Ohne zu Grunde liegende Sende-Management-Struktur kann jeder Node Datenpakete an alle Nodes senden, zu denen er direkten Funkkontakt hat.
Die Abbildung 1 zeigt ein solches Netz mit Nodes A,B,C. Die Sende- und Empfangsreichtweiten der Nodes sind als Kreise dargestellt. A und B sowie C und B haben Funkkontakt. Pakete können entsprechend der Pfeile zugestellt werden. Eine Kommunikation zwischen A und C ist ohne weiteres nicht möglich.
Um die Kommunikation zwischen A und C zu ermöglichen, wird ein Mesh-Protokoll verwendet, dass einerseits B anweist, Datenpakete zwischen A und C weiterzuleiten und andererseits A und C darüber informiert, dass B als Relais zwischen Ihnen zur Verfügung steht. A,B,C bilden hierbei ein Mesh
Mesh-Protokolle können entweder auf OSI-2 (Data-Link-Layer) oder OSI-3 (Network-Layer) arbeiten und Frames bzw. Pakete zustellen [2]. Populäre Vertreter sind unter u.a.:
- OSI-3: Batman [3], OLSR [4], Babel [5]
- OSI-2: Batman-advanced (Batman-adv) [6] , IEEE 802.11s / AODV [7]
Ansatz Freifunk-KBU
Idee
Als Teil der Freifunk-Initiative soll ein freies Wireless-Lan Mesh-Netz in Köln, Bonn und Umgebung betrieben werden, da die definierten Anforderungen umsetzt. Architektur: [8]:
- Batman-Adv als Routing-Protokoll
- Public IPv6-Adressen für alle Teilnehmer
- Private IPv4-Adressen für alle Klienten
Als Besonderheit verfügt das Netz über zentrale Server ( z.Zt. PAUL ), die als IPv4- /IPv6-Router zum Internet betrieben werden und IPv4-Verkehr via NA(P)T [9] abwickeln. Die Anbindung an das Netz erfolgt durch OpenVPN auf Data-Link-Layer. Lokale IPv4-Adressen sollen per DHCP vergeben, IPv6 soll ebenfalls automatisch konfiguriert werden.
Wir wollen Batman-adv als Routing Protokoll verwenden, um den Konfigurations-Aufwand der einzelnen Nodes gering zu halten: Wir wollen vermeiden, dass den Nodes eine feste IP zugewiesen werden muss, wie es beispielsweise bei OLSR erforderlich wäre. Darüber hinaus soll das Netz als Dual-Stack betrieben werden, da wir fest davon ausgehen, dass wir auf IPv6 nicht verzichten können:
Die Abbildung 2 zeigt exemplarisch ein Gatway und die Nodes A,B,C. Dabei können A und C das zentrale Gateway über das Internet direkt erreichen. Sie bauen daher eine VPN-Verbidung auf, über die Daten-Frames ausgetauscht werden. Node B ist lediglich per Funk mit dem Freifunk-Netz verbunden - er verfügt über keine VPN-Verbindung zum Gateway.
Batman-adv stellt hierbei sicher, dass das KBU-Netzwerk als zusammenhängendes Netz betrieben werden kann (die Topologie ist für höhere Schichten transparent) und Kreise (hier: Gateway, A, B, C, Gateway) erkannt und behandelt werden.
(Randnotiz / Vorgriff: Die Argumentation ist vereinfachend. Wenn wir zentrale Server haben, die Adressen und Prefixes via icmp6 und dhcp propagieren, dann können wir damit auch das ein OSI-3 Mesh-Protokoll nutzen, ohne Nodes per Hand zu konfigurieren)
Praktische Einschränkungen
Bei einem solchen Netz ergeben sich jedoch Einschränkungen
- Nicht alle Geräte können Wireless-Lan im ad-hoc Modus nutzen.
- Bei vielen potentiellen Klienten ist Batman-Adv nicht installiert.
Darüber hinaus treten weitere Probleme auf, die die Teilnahme am Netz zwar nicht verhindern, aber einschränken:
- Das komplette Netz bildet eine große Anycast / Broadcast Domäne. Entsprechende Pakete (insb. ICMPv6, ARP - aber auch Windows Broadcasts) müssen im kompletten Netz verteilt werden. Das Netz skaliert daher möglicherweise nur begrenzt.
- Der Wireless-Lan Kanal wird fest gewählt. Lokale Störungen können nicht berücksichtig werden.
Weitere Probleme treten auf, wenn beispielsweise Adressen doppelt vergeben werden, da Duplicate-Address-Detection Pakete verloren gehen oder durch einen gezielten Angriff die IPv4- und/oder IPv6 Auto-Konfiguration gestört wird.
Um die Einschränkungen 1 und 2 zu berücksichtigen können Nodes neben dem Ad-Hoc Netz ein weiteres Infrastrukt-Netz betreiben, damit sich entsprechende Klienten verbinden können. Kann ein Node nicht beide Netze gleichzeitig betreiben, so stellt er ein Ad-Hoc-Netz zur Verfügung, damit das Mesh darüber erweitert werden kann.
Darüber hinaus ist es denkbar, dass die Nodes den Funkkanal für das Infrastruktur-Netz und ggf. auch für das Mesh selbst wählen und lokale Besonderheiten (gestörte Kanäle, genutzte Kanäle anderer Freifunk-Nodes) berücksichtigen. Da eine solche Konfiguration jedoch komplex ist (beispielsweise müssen sich Nodes zweier Mesh-Clouds auf einen Kanal verständigen, wenn sie zusammen geführt werden), wird diese Funktion zunächst nicht verfolgt.
Problemstellung
Zur Berücksichtigung der aufgeführten Einschränkungen müssen bei der Implementierung des Freifunk-KBU-Ansatzes u.a. die folgenden Probleme berücksichtigt werden:
- Welche IPv4 und IPv6 Adressierungs-Strategie wird gewählt?
- Wie werden diese Strategien umgesetzt?
- In welche Bereiche muss das Netz aufgeteilt werden, um skalieren zu können? Wie findet Routing dazwischen statt?
- Mit welchen Maßnahmen kann die Integrität des Gesamt-Netzes sicher gestellt werden, wenn in einer Zelle ein Angriff stattfindet?
Im weiteren Verlauf dieses Textes werden verschiedene Konfigurations-Möglichkeiten vorgestellt, die anhand dieser Problemstellung bewertet werden. Jede Mögliche Konfiguration wird kurz vorgestellt - Vor- und Nachteile werden aufgeführt. Abschließend werden Optionen zur Modifikation erläutert.
Mögliche Netz-Konfigurationen
Komplettes Bridging
Beschreibung
Bei der Komplettes-Bridging-Stategie werden alle Interfaces (VPN, Infrastruktur, Ad-Hoc) zu einer Batman-adv Bridge [10] zusammen gefasst. Zur Adressierung wird ein /64-IPv6- und ein /16-IPv4-Prefix verwendet. Im Netz werden mehrere DHCP-Server / Router betrieben, die Adressen und Konfigurationsdaten zur Verfügung stellen.
Da das Netz nicht geteilt wird, muss innerhalb des Netzwerks kein Routing auf Network-Layer (OSI-3) betrieben werden.
Vorteile
- Die Probleme 1. und 2. werden gelöst.
- Der Konfigurationsaufwand bleibt gering.
- Zwischen den einzelnen Zellen ist Roaming möglich: Wechselt ein Klient vom Abeckungsbereich eines Nodes zum anderen (d.h. von einer Zelle zur anderen), kann er seine Adresse behalten. Offene Verbindungen reißen dabei nicht ab, da Pakete an die IP-Adresse des Klienten nach wie vor zugestellt werden können.
- Link-Local Dienste (z.B. Bonjour-Chat) sind im allen Teilen des Netzes möglich.
Nachteile
- Die Integrität des Netzes kann kaum sicherstellt werden. Bei einem Angriff sind alle Zellen betroffen.
- Das Netz skaliert schlecht, da broadcast (und ggf. auch anycast-Pakete) durch alle Teile des Netzes geleitet werden müssen.
Option: Trennung zwischen Köln, Bonn und Umland
Um die Skalierbarkeit des Netze zu verbessern, kann es in räumlich sich nicht überlappende Segmente (z.B. Köln, Bonn, Umgebung) eingeteilt werden, zwischen denen Routing stattfindet. Diese Überlegung geht davon aus, dass Roaming ohne Verbindungsabriss zwischen den Segment nicht möglich sein muss (die Orte liegen zuweit auseinander) - innerhalb der einzelnen Segmente ist Roaming ohne Verbindungsabriss aber nach wie vor möglich. Das Routing sollte so gestaltet werden, dass Site-Local Multicast möglich ist. In diesem Fall wird für jedes Segment ein /64- bzw. ein /16-Prefix verwendet. Dies verbessert die Integrität des Netzes jedoch nicht wesentlich, da bei einem Angriff große Bereiche betroffen sein können.
Routing zwischen Infrastruktur- und Mesh-Netz
Beschreibung
Bei diese Strategie wird zwischen einem Backbone und Infrastruktur-Netzen unterschieden.
- Das Backbone-Netz verbindet alle Nodes im Ad-Hoc Modus und ist mit dem VPN-Interface bridged
- Jeder Node, der im Infrastruktur-Modus betreibt ein Klienten Netz, in dem er IPv4 und IPv6-Adressen betreibt.
Jeder Node arbeitet als Router für sein Klienten-Netz. IPv4-Pakete, die der Node ins Backbone-Netz weiter leitet werden maskiert (NA(P)T). Hierbei muss jeder Node entweder eine eindeutige ESSID oder einen eindeutigen IPv4-DHCP-Bereich für sein Klienten-Netz vergeben: Nur so können wir verhindern, dass ein Klient, der in eine benachbarte Zelle wechselt, eine bereits vergebe IPv4-Adresse benutzt.
Das Backbone-Netz kann dabei entweder IPv6 oder IPv4 Dual-Stacked betrieben werden. Sinnvoll ist ein Dual-Stacked-Betrieb, damit Klienten, die sich dorthin verbinden unterstützt werden. Die Adressen hierfür werde automatisch konfiguriert. Es kann eine andere ESSID als das Klienten-Netz verwenden.
Vorteile
- Das Klienten-Netz wird in viele, kleine Zellen aufgeteilt, die eigene Broadcast / Anycast Domänen bilden. Das Netz skaliert somit gut.
Nachteile
- Das Backbone-Netz bildet nach wie vor eine große Broadcast/Anycast Domäne. Bei einem Angriff, können weite Teile des Netzes betroffen sein.
- Da IPv4-Verbindungen maskiert werden, ist keine direkte IPv4-Kommunikation zwischen Klienten in verschiedenen Zellen möglich.
- Nodes, die deren Uplink über ein Infrastruktur-Netz realsiert wird, müssen aufwending in das Backbone-Netz eingebunden werden (VPN o. L2TP zum Gateway-Server oder zum lokalen Uplink-Node).
- Nachteile ergeben sich vor allem für Klienten in Reichweite mehrer Zellen:
- Werden verschiedene ESSIDs für die Klient-Netze genutzt, kann ein Klient nicht automatisch auf das aktuell beste Netz umschalten
- Werden gleiche ESSIDs genutzt, so gilt: Wechselt ein Klient von einer Zelle in die nächste, so reißen seine IPv4 und IPv6 Verbindungen ab (er ist nur unter einer neuen Adresse erreichbar). Nutzt der Klient IPv6-auto-Konfiguration, so wird bei mehreren in Frage kommenden Absender-Adressen, die letzte Absender-Adresse bevorzugt. Wechselt ein Klient zwischen zwei Zellen kurzfristig hin- und her, so kann eine Zeit lang die falsche Abesnder-Adresse genutzt werden. Der Klient ist nicht erreichbar. Bei IPv4 tritt dieses Problem durch NA(P)T nicht auf.
Option: Routing statt Masquerading von IPv4
Der Node kann darauf verzichten, Pakete seines Klienten-Netzes zu maskieren. In diesem Fall kann er die genutzten Adressen über eine Routing-Protokoll (RIP, OSPF, etc.) annoncieren. Seine Klienten sind dann über IPv4 erreichbar.
Wechselt ein Klient in eine andere Zelle, so reißen in diesem Fall alle Verbindungen ab - es sei denn, er propagiert seine IP-Adressen über das genutzte Routing-Protokoll. Aber auch wenn er dies macht treten Probleme auf:
- Bei IPv6 können Probleme in Zusammenhang mit der Duplicate-Address-Detection auftreten: Der Klient verwendet eine IPv6-Adresse, die nicht auf dem, zum Prefix gehörenden Link erreichbar ist. Je nach Art und Weise Adress-Generierung (Privacy-Extensions vs feste Generierung aus EUI-64 - RFC 2373 vs. RFC 3041) unterscheidet sich die Auswirkung des Problems.
- Bei IPv4 kommt es zu einem Abriss aller Verbindungen, wenn das DHCP-Lease ausläuft. Dies kann jedoch erst nach einigen Tagen geschehen und somit vertretbar sein.
Option: Verzicht auf Batman-adv
Werden für die Klienten-Netze gleiche ESSIDs verwendet, so müssen Adressvergabe und Routing geregelt werden:
- Jeder Node muss IPv4- und IPv6-Prefixes für sein Klienten-Netz anfordern können. Ein Strategie zur Adressvergabe muss vorhanden sein.
- Die Nodes müssen ein Routing-Protokoll verwenden, um ihre Prefixes zu annoncieren.
Da Batman-Adv jedoch für das Routing-Protokoll transparent ist, können wlan-Metriken und die Link-Qualität jedoch nicht unmittelbar berücksicht werden. Gleichzeitig entfällt die Notwendigkeit Batman-Adv für das Backbone-Netz zu nutzen, da alle Nodes Routing auf Network-Layer aktiv betreiben, Prefixes anfordern und Pakete weiterleiten können.
In diesem Fall wird ein anderes Mesh-Protokoll (z.B. Babel - kann afair IPv4 und IPv6...???) verwendet, das Routing auf Network-Layer umsetzt.
Routing über das VPN, bridging zwischen batman-adv und Infrastruktur
Beschreibung
Bei dieser Strategie:
- Werden VPN und Wireless-Lan Interfaces nicht zu einer Bridge verbunden. Insbesondere spricht Paul kein Batman-adv
- Routed jeder Node zwischen wlan und VPN
- Verteilt jeder Node IP-Addressen (v6 und v4) auf seinen Wireless-Lan-Interfaces
- betreibt jeder Node mindestens ein ad-hoc-Interface und optional ein Infrastruktur-Netz. Alle wlan-Interfaces werden zu einer Bridge mit dem Batman-Interface (bat0) hinzugefügt.
Vorteile
- Robustheit gegenüber Angriffen: Ein Angreifer kann maximal eine Zelle stören.
- Robustheit gegenüber Angriffen: Ein Angreifer kann via wlan nicht das Backbone-Netz stören. Dies liegt ausschließlich im VPN auf.
- Roaming ist möglich:
- Sind benachbarte Router in Funkreichweite, so teilen sie sich eine Broadcast-Domain und können auch Pakete benachbarter Zellen zustellen.
- Sind sie nicht in Funkreichweite, so kann ein Freifunker einfach Roaming ermöglichen, indem er in der Mitte einen Node aufbaut und beide Zellen verbindet. Dann hat er überall Roaming
- Die Broadcast-Domänen entsprechen den Roaming-Bereichen und sind eher klein: Nur da wo Roaming möglich ist, gibt es auch eine gemeinsame Broadcast-Domäne.
Nachteile
- Falls größere Mesh-Wolken auftreten ergeben sich ähnliche Probleme wie bei der Alles-Bridging Strategie - hier bietet es sich ggf. nicht, nicht vom jedem Node aus einen eigenen IPv6-Prefix zu verteilen
- Es ist aber wohl realistisch anzunehmen, dass die so entstehenden Mesh-Wolken deutlich kleiner sind als bei der "komplettes-bridging Strategie" (u.a. da die Trennung zwischen Köln, Bonn und Umgebung automatisch umgesetzt wird)
- Link-Local Multicast funktioniert nicht über das gesamte Netz
- Für z.B. Avahi müsste zwischen VPN und Funk-Zellen mDNS reflectors installiert werden
- Für Multicast allgemein könnte noch nicht-link-local Multicast stattdessen benutzt werden, hier müssten aber Multicast Routing Daemons installiert werden.
Besonderheit
IPv4 und IPv6 verhalten sich in diesem Netz verschieden.
- Da jeder Klient nur eine IPv4-Adresse haben kann, wird IPv4 immer über seinen "Home-Node" - d.h. den Node von dem er das DHCP-Lease erhalten hat - routed.
- IPv6 unterstützt mehrere Adressen. Je nach Ziel-Adresse (und Tie-Breaking implementation) kann die Adresse eines anderen Nodes gewählt werden.
- Pro: Kein VPN-Traffic falls Clients in der gleichen Zelle stehen
- Kontra: Wahl sehr ungüstiger Gateways möglich (z.B. Node mit schlechtem Funkkontakt wird als Router gewählt.) Insb. berücksichtigt die IPv6-Adressahl wlan-Besonderheiten (Link-Qualität) nicht.
Diskussion 31c3 / 2.1.2015 @KBU
- Idee vom 31c3: Migration von "Komplettes Bridging" -> Routing über das VPN, bridging zwischen batman-adv und Infrastruktur, jedoch teilweise abweichend von der o.g. Konfiguration:
- IPv6
- Jeder Node erhält via VPN ein IPv6-Netz per DHCP-PD und announced es im WLAN.
- Hat ein Node keinen Range, so leitet er RAs seiner Nachbarn weiter (bat0 -> Infrastruktur). Hat er einen, dann blockiert er sie.
- Jeder Node hört auf RAs auf bat0 und setzt routes zu diesen networks passend (keine IP-Adressen!)
- IPv4
- Option 1: Verzicht. Nat64
- Option 2: DHCP-Requests der clients werden ins VPN relayed. Routing wie folgt
- Client -> Extern: Jeder Node ist Router mit gleicher mit Anycast-IPv4 Addresse für das Routing.
- Extern -> Client
- Variante a) Der Node maskiert Pakete über eine private IPv4 im LAN
- Variante b) Das Netz weiß, welche DHCP-Leases an welchem Node sind (Hostroutes propagieren)
Für mich (yanosz) klingt Variante a) sinnvoller - ich hab's aber noch nicht komplett durchdacht. Im Nat-Fall geht routing evtl. schnell kaputt, wenn sich die anycast-adresse ändert... Also dann kein anycast und jeder Node besorgt sich seine br-freifunk-IP per DHCP?
Dynamisches Bridging
Beschreibung
Dies ist eine Mischform aus der All-Bridging und der Layer 3 Routing über das VPN Variante. Im Vergleich zur All-Bridging Variante erstreckt sich die Layer 2 Broadcast Domäne hier nur über eine einzelne WLAN-Wolke und nicht über alle WLAN-Wolken - prinzipiell ähnlich wie bei der Layer 3 Routing über das VPN Variante. Wenn es jedoch mehrere Knoten mit einem VPN-Zugang in einer WLAN-Wolke gibt, dann strahlt nicht jeder dieser Knoten sein eigenes Subnetz aus, sondern diese Knoten detektieren dieses Szenario und wechseln untereinander auf ein Layer 2 statt Layer 3 VPN. Ähnlich wie im All-Bridging Szenario erhalten jene Knoten dann auch BATMAN-Adv. Pakete über jenes Layer 2 VPN.
Vorteile
- BATMAN-Adv. kann selbstständig entscheiden, ob es besser wäre über die WLAN-Wolke zu Routen oder eine Abkürzung durch das VPN zu benutzen - für den Netzwerklayer im Layer 3 VPN Szenario ging diese Möglichkeit durch die nicht mehr vorhandenen Metrik-Informationen leider verloren. Dies ist insbesondere von Vorteil, wenn zwei Knoten mit VPN Zugang sich in der selben WLAN-Wolke befinden, aber jeweils am anderen Rand der Wolke, der Pfad zwischen jenen beiden Knoten also sehr lang ist.
- Das Roaming ist genauso gut wie in der Komplett-Bridging Variante, ein mobiles Gerät kann sich frei in einer WLAN-Wolke bewegen, ohne den Layer 3 Gateway wechseln zu müssen.
Nachteile
- Es könnte in manchen Topologien schwierig sein, passende Schwellwerte für das Umschalten zwischen Layer 2 und Layer 3 VPN zu finden.
- Es muss erst ein Daemon entwickelt werden, der dieses Umschalten leistet - und darf möglichst nichts verkehrt machen, da sonst ganze Wolken bei jedem Wechsel Probleme bekommen könnten -> es ist also auch viel Testen und Monitoring jenes Daemons notwendig.
- Kein Link-Layer Multicast möglich.
- Avahi / nicht-link-layer Multicast benötigen extra Daemons (mDNS-replicator, Multicast Routing Daemon)
- Komplexität
Komplette Zellen per BATMAN-Adv's TT/HNAs bekannt machen
Beschreibung
Vorteile
- Der Overhead des Routing-Protokolls ist mit batman-adv 2011.3.0 ungefähr genauso groß wie in der "Routing über das VPN" Variante
- Siehe Vorteile von "Komplettes Bridging"
Nachteile
- Prinzipiell nur ab BATMAN-Adv. 2011.3.0 möglich, da alle älteren Versionen nicht mit so einer großen Anzahl an TT Nachrichten/HNAs effizient klar kamen.
- Es darf nur einen einzigen Knoten mit VPN Zugang pro WLAN-Wolke geben. Ansonsten bricht die komplette Wolke zusammen, da BATMAN-Adv. nicht mit den mehrfachen TT Nachrichten / HNAs für die gleiche MAC Adresse von verschiedenen Knoten umgehen kann. (Ausweg: Bridge Looop avoidance)
Zusammenfassung
Obwohl beide Ansätze sich auf den ersten Blick stark unterscheiden, liegen Unterschiede vor allem im Detail: Der wesentlich Unterschied ist, dass die "Bridging-Strategie" von wenigen Segmenten ausgeht, während die "Infrastruktur-Mesh-Routing-Strategie" für eine sehr feine Trennung der Netze sorgt. Letzteres führt vor allem in Bereichen, die von mehreren Nodes abgedeckt werden zu Problemen, da Roaming im Klienten-Netz stark erschwert wird. Ein weiterer Unterschied ist, dass die Option "Trennung zwischen Köln, Bonn und Umland" alle Netzbereiche betrifft (Nodes werden auf OSI-2 getrennt), während die IM-Strategie ein gemeinsames Backbone-Netz vorsieht. Ein DoS-Angriff auf das Backbone-Netz hätte bei dieser Stratgie gravierende Folgen.
Die Herausforderung liegt darin, eine Segmentierungs-Strategie umzusetzen, die einerseits Roaming in gut versorgten Bereichen ermöglicht (d.h. dort wie die Bridging-Strategie arbeitet),andererseits jedoch die Bereiche identifiziert, die keine Broadcast-/Anycast-Domäne bilden müssen. Einen Ansatz dafür liefert die letzte Strategie.
Optimal wäre ein Netzdeployment, das es ermöglicht, die Zuteilung zwischen Segmenten zur Laufzeit zu ändern und eine größere Anzahl verschiedener Segmente zentral zu verwalten.
Die Bridging-Strategie scheint auf den ersten Blick einfacher umsetzbar, da hier keine Prefix-Delegation Verfahren benötigt werden. Der nächste Schritt im Aufbau des Netzes ist jedenfalls alle Varianten zu testen und Probleme zu identifizieren. Theoretisch sind alle Konfigurationen umsetzbar, praktisch kann es jedoch Probleme in einzelnen Konstellationen geben.