Netzwerk-Konfiguration

Arbeitsfassung - bitte nicht ändern. Falls nötig: fork erstellen. Danke!

Netzlayout Freifunk

Diese Artikel fasst die Überlegungen zur Netzkonfiguration 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. Es betrifft die OSI-Schichten 1-3 (Überlegungen zur NAPT auch OSI-4).

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 Berlink, Jena (usw. existieren). In diesen Netzen Operieren Nodes typischer Weise im ad-hoc Modus. Ohne zu Grunde liegende Struktur kann jeder Node Datenpakete an alle anderen Nodes senden, zu denen er direkten Funkkontakt hat. Die folgende Abbildung zeigt ein solches Netz mit Nodes A,B,C. Die Sende- und Empfangsreichtweite der Nodes ist als Kreis dargestellt. A und B sowie C und B haben Funkkontakt. Pakete können entsprechend der Pfeile zugestellt werden.

Um die Kommunikation zwischen A und C zu ermöglichen, wird ein Mesh-Protokoll verwendet, dass einerseits B anweisend, 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) und IP-Pakete oder Frames zustellen [2]. Populäre Vertreter sind unter u.a.:

• OSI-3: Batman (http://www.open-mesh.org/), OLSR (http://www.olsr.org/)
• OSI-2: Batman-advanced (Batman-adv - http://www.open-mesh.org/) , IEEE 802.11s / AODV (http://de.wikipedia.org/wiki/IEEE_802.11s)

Ansatz KBU

Idee

Als Teil der Freifunk-Initiative soll ein freies Wireless-Lan Mesh-Netz in Köln, Bonn und Umgebung betrieben werden. Architektur (http://freepad.erdgeist.org/ep/pad/view/freifunk-restart/vblu5I1rQ9): \begin{itemize} \item Batman-Adv als Routing-Protokoll \item Public IPv6-Adressen für alle Teilnehmer \item Private IPv4-Adressen für alle Klienten \end{itemize}

Als Besonderheit verfügt das Netz über ein (oder mehrere) zentrale Server, die als Router zum Internet betrieben werden und IPv4-Verkehr via NAPT (Network address and port translation http://tools.ietf.org/html/rfc2663) abwickeln. Der Verkehr dorthin wird durch OpenVPN getunnelt. 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 folgende Abbildung zeigt den Schematischen Aufbau des Netzes:

Die Abbildung 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

\begin{enumerate} \item Nicht alle Geräte können Wireless-Lan im ad-hoc Modus nutzen. \item Bei vielen potentiellen Klienten ist Batman-Adv nicht installiert. \end{enumerate} Darüber hinaus treten weitere Probleme auf, die die Teilnahme am Netz zwar nicht verhindern, aber einschränken: \begin{itemize} \item 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 kann nur beschränkt skalieren. \item Der Wireless-Lan Kanal wird fest gewählt. Lokale Störungen können nicht berücksichtig werden. \end{itemize} 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. Die Konsequenz aus den Einschränkungen 1 und 2 ist, dass Nodes nach Möglichkeit Netze im Infrastruktur-Modus betreiben müssen, um alle Klienten versorgen zu können. Falls ein Gerät nicht in der Lage ist, sowohl ein Ad-Hoc als auch ein Infrastruktur-Netz zu betrieben (z.B. WRT 54GL) ist es naheliegend ein Infrastruktur Netz zu betreiben: Einerseits können hierbei alle Klienten bedient werden, andererseits können entsprechend leistungsfähige Nodes diese Zellen als Uplink zum Freifunk-Netz nutzen. Hierzu müssen sie gleichzeitig im Client, Accesspoint und ggf. im Ad-Noc Modus arbeiten können. Die folgenden Abbildung zeigt eine solche Konfiguration.

Node A verfügt über eine direkte Verbindung zum Gateway, kann jedoch nur ein Wireless-Lan im Infrastruktur-Modus (durch die Antenne symbolisiert) betrieben werden. Node B verfügt über keine Internet-Verbindung, kann jedoch im Infrastruktur, Client und Ad-Hoc Modus gleichzeitig operieren. Er nutzt die Nodes A und C um eine Verbindung zum Freifunk-Netz herzustellen. Node C verfügt über eine Verbindung zum Gateway. Er operiert im Infrastruktur und Ad-Hoc Modus. Eine solche Netz-Konfiguration geht davon aus, dass es sinnvoll ist, auch Nodes, die nicht im Ad-Hoc Modus betrieben werden können als Uplink zum Freifunk-Netz zu benutzen. Ein Verzicht darauf verringert jedoch die Komplexität.

Problemstellung

Bei der Konfiguration des KBU-Netzes müssen dabei mehre Fragestellungen berücksichtigt werden: \begin{enumerate} \item Welche IPv4 und IPv6 Adressierungs-Strategie wird gewählt? \item Wie werden diese Strategien implementiert? \item In welche Bereiche muss das Netz aufgeteilt werden, um skalieren zu können? Wie findet Routing dazwischen statt? \item Mit welchen Maßnahmen kann die Integrität des Gesamt-Netzes sicher gestellt werden, wenn in einer Zelle ein Angriff stattfindet? \end{enumerate} 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 \emph{Bridging-Stategie} Werden alle Interfaces (VPN, Infrastruktur, Ad-Hoc) zu einer Batman-adv Bridge (vgl. http://www.open-mesh.org/wiki/batman-adv/Quick-start-guide) zusammen gefasst. Zur Adressierung wird ein /64-IPv6- und ein /16-IPv4-Prefix verwendet. Im Netz werden mehrere

Routing zwischen Infrastruktur- und Mesh-Netz

Option: Babel statt Batman-adv

-> Wäre dann die Überleitung zur anderen Konfiguration.