Architektur-Babel

Hinweis: Dieser Artikel beschreibt nicht das aktuelle KBU-Netz aus konzeptioneller Sicht und erklärt viele, tiefe Details. Um einfach mitzumachen musst Du nicht alles davon verstehen - wenn Du Interesse hast, lese einfach weiter :-).

Dieser Artikel beschreibt eine vom KBU-Netze abweichende, mögliche Konfiguration. Sie ist ISP (d.h. VPN-Provider) unabhängig und verzichtet auf eine Node-Hierachie (Node, Supernode).

Hierbei schildert die Einleitung zunächst verschiedene Probleme des aktuellen KBU-Netzes und Ideen für eine Verbesserung. Aus diesen Punkten werden Ziele und Anforderungen hergeleitet, die zu denen Umsetzungen vorgeschlagen werden.

Im letzten Teil werden die technischen Details der Umsetzung erläutert.

Kurzzusammenfassung

• ISP / VPN-Provider unabhängig.
• Routing via Babel (Backbone + Adhoc)
• Roaming über batman-adv

Einleitung

Stand 04/2016 verwendet das KBU-Netz batman-adv auf allen links (auch VPN). Server erfüllen die Aufgabe der Supernodes. Broadcasts belasten das Netz dort.

Viele Teile hiervon sind in https://github.com/yanosz/node-config testweise umgesetzt. Alles ist work-in-progress.

Einschränkungen

Ein paar Dinge sind im batman-adv-Netz (Stand: Q1/2016) unschön

Hohe Last durch batman-adv über VPN-Links

batman-adv ist nicht dafür gedacht auch in VPNs verwendet zu werden. Algorithmus und Metrik ermitteln fortlaufend die Verbindungsqualität und belasten die VPN-Verbindung. Das Qualität ändert sich aber kaum (keine Funkstörung, VPN ist eingeschaltet oder aus), so dass viel Overhead entsteht. IP-Router (häufig Server in RZ) werden hierdurch enorm belastet

Viel broadcast-Traffic durch Roaming über Hoods

batman-adv-Metadaten werden im ganzen Stadtgebiet verteilt und erlauben ein Roaming innerhalb einer Hood. Der Aufwand ist aber unnnötig. Kaum jemand wird bspw. von Lindweiler nach Porz roamen. Es gibt noch nicht einmal eine durchgehende Funkverbindung. Dabei belegen die Metadaten viel Wifi-Kapazität (d.h. airtime).

Einstiegshürde

Neue Freifunk-Communities (bspw. Troisdorf, Hennef) müssen am Anfang recht viel Know-How ohne Freifunk-Bezug mitbringen (Konfiguration von Server, Supernodes). Besser wäre, die Einstiegshürde niedrig zu halten. Eine Hand voll OpenWRT-Router sollte ausreichen, um ein Freifunk-Netz aufzubauen.
Neue Freifunk-Communities sollten nicht vor der Herausforderung stehen, dass sie Server für den Betrieb auftreiben oder einen eigenen Verein gründen müssen. Werden wichtige Server von Einzelpersonen betrieben, besteht immer das Risiko, dass Sie weniger Zeit haben oder aussteigen und das gesamte Netz beeinträchtigt wird.

Neue Communities sind für die Dezentralität extrem wichtig. Um so mehr Communties sich finden und ihre Netze bauen, desto dezentraler wird Freifunk. Alle Netze existieren unabhängig voneinander.

Abhängigkeit von Servern, Personen, ISPs

Das Freifunk-Netz sollte von niemanden einfach abgeschaltet werden können:

• Aktuell betreiben 1-2 Personen fast alle Supernodes in den Hoods - mehrere hundert nodes sind von ihnen abhängig
• Das Netz sollte auch nicht einem einzelnen ISP- oder Verein abhängen, der den Abuse-Desk betreibt. Ein passender abuse-Desk, der über Freifunk aufklärt ist zwar hilfreich - andernfalls wird bei abuse der Node-Aufsteller als Übeltäter identifiziert - aber das Netz sollte nicht auf einen Provider festgelegt sein. Bspw. sollte ein Node hide.me und ein anderer den Freifunk Rheinland e.V. nutzen können.

Konzeptionelle Sicht

Es gibt bereits einige Ansätze wie lokale Supernodes auf Futro-Hardware, die einige Nachteile adressieren. Viele Einschränkungen und Kompromissen entstehen durch die Konzeptionierung des Freifunk-Netzes. Für die vorgestellten Einschränkungen sind u.a. folgende Punkte wichtig:

Verschiedene Nodes nacheinander nutzen (Roaming)

Es ist hilfreich in einem bestimmten Gebiet (z.B. ein Gebäude) roamen zu können. Dabei kann sich ein Client mit verschiedenen Nodes verbinden, ohne dass Netzwerkverbindungen abreißen. Damit ein Client roamen kann, müssen Daten zwischen in Frage kommenden Nodes ausgetauscht werden. Der Bereich sollte nicht zu groß gewählt werden, damit nicht unnötig viele Daten übertragen werden müssen.

Verschiedene IPv6-Adressen im Netz (Multihoming)

Wenn mehrere ISPs verwenden werden, gibt es viele IPv6-Netze die sich zum Teil dynamisch ändern.

Nutzt ein Client eine IPv6-Verbindung in das Internet, so benötigt er eine IPv6-Adresse. Weiterhin muss er einen Router verwenden, der diese Adresse routen kann. Hier ist offen, welche Art von Adresse der Client verwenden soll (Public oder ULA) und wie Router nur passende Absenderadressen routen. Ein Router kann nicht jede beliebige Absenderaddresse in einem VPN-Tunnel verwenden (IP-Spoofing). Damit muss er die Adressen entweder ersetzen (Nat66) oder an den Router mit passendem VPN-Tunnel weiterleiten (Source Sepecific Routing).

Freifunk-Routing

Clients und Nodes sollten direkte Ende-zu-Ende Verbindung aufbauen können. Jeder client soll seine eindeutige IP-Adresse haben können. Direkte Verbindungen in andere Communities sollen auch möglich sein. Das Intercity-VPN ist eine Verbindung aller Freifunk-Communities. Wie kommunizieren Clients im Freifunk-Netz untereinander? Welche Adressen verwenden genutzt und direkte Verbindungen aufbauen zu können? Wo werden Verbindungen zum ICVPN aufgebaut und wie wird DNS verwendet?

Ziele und Anforderungen

Designziele

Das Netz soll die folgenden Eigenschaften bieten:

1. ISP-Unabhängigkeit: Es können verschiedene VPN-Provider verwendet werden. Das Netz ist nicht abhängig von einem ISP (bspw. Freifunk-Rheinland).
2. Roaming: Zwischen Nodes, die direkten Funkontakt haben, soll Roaming möglich sein.
3. Skalierbarkeit: Das Netz einer Community soll bis zu einer Größe von 65000 Nodes (zzgl. clients) skalieren können.
4. IPv4 und IPv6: Beides wird verwendet
5. Dezentralität: Die Komponenten des Netzes werden nicht zentral verwaltet.
6. Geringe Hardware-Anforderungen: Auch Geräte mit wenig Ressourcen können verwendet werden.
7. Wiederverwendbarkeit: Andere Communities sollen analog Netze gestalten können. Die Netze existieren unabhängig.

Keine Designziele

Folgende Punkte werden nicht berücksichtigt. Technische gesehen sind sie aber grundsätzlich umsetzbar.

1. Internet-Performance: Ein hoch performanter Zugriff auf das Internet soll nicht sichergestellt sein.
2. Netzwerk-Management: Es muss nicht sichergestellt sein, dass eine einzelne Person möglichst viele Router effizient verwalten kann.
3. Stabilität: Die Verfügbarkeit einzelner Komponenten wird nicht sichergestellt.

Umsetzung

Modifizierte: Routing über das VPN, bridging zwischen batman-adv und Infrastruktur-Strategie

• Nodes verbinden zu einem ISP (z.B. FFRL e.V, hide.me) und erhalten Routbare IPs, sofern sie an das Internet angebunden sind.
• Jedem Node wird ein eindeutiges private IPv4 (/24) und ULA IPv6 Netz (/64) zugewiesen.
• Jeder Node betreibt einen DHCP und einen radvd auf dem Infrastruktur-Netz.
• Im ad-hoc-Netz werden babel und batman-adv verwendet.
  • batman-adv nur für Roaming. Broadcast wird komplett gefiltert. Jeder Node ist batman-adv Gateway
  • babel zur IP-Kommunikation zwischen den Nodes genutzt.
• Verfügt der Node über öffentliche IPv6-Prefixes, dann schaltet er DHCPv6-Prefix Delegation auf dem ad-hoc Interface (nicht batman-adv) ein. Benachbarte Nodes können darüber Prefixes erhalten.

Erreichte Anforderungen

• Das Netz ist Provider-Unabhängig, da jeder ISP genutzt werden kann. Traffic kann grundsätzlich auch ohne VPN in das Internet geleitet werden.
• Roaming ist über batman-adv möglich. Annahme: Clients benötigen nach einem Zellenwechsel keinen Broadcast: IPv6-ND ist nicht mehr nötig üb eine Layer-2 Adresse aufzulösen. ND-Table Einträge müssen langlebig sein.
• Das Netz skaliert bis theoretisch zu 65000 Knoten, da es ~ 65000 /24-Netze im Bereich 10.0.0.0/8 gibt. Annahme: Babel skaliert passend in zusammenhängenden Mesh-Segmenten.
• Dezentralität: Es gibt nicht notwendiger Weise Server in Rechenzentren.
• Geringe Hardware-Anforderungen: Auch TP-Link WR841n Geräte können verwendet werden.
• Wiederverwendbarkeit - Netze verschiedener Communities beeinflussen sich nicht, sofern sie nicht direkt mit Babel verbunden sind. Über das ICVPN können die ULA-Netze routed werden.

Node-Konfiguration - Technische Details

Abb. 1 - Interfaces eines Freifunk-Nodes

Prototyp: https://github.com/yanosz/node-config

Die Freifunk-Nodes werden wie folgt konfiguriert.

Netze & Interfaces

Abbildung 1 zeigt ein Beispiel für die Konfiguration der Interfaces auf einem Node. Links sind die Interface, rechts die zugewiesenen IP-Adressen dargestellt.
Dem Node sind hier die Netze 10.59.64.0/24 und fdd3:5d16:b5dd:f040::/64 zugewiesen.

• wlan0 betreibt das Infrastruktur-Netz für Clients. Es ist direkt in die Bridge br-freifunk eingebunden. BSSID und ESSID sind 42:42:42:42:42:42
• wlan1 ist die Schnittstelle zum wlan-Mesh. Es ist direkt in bat0 eingebunden, damit clients roamen können. wlan1 verfügt über eine IPv6 Link Local, und eine private IPv4-Adresse und ist damit auch in babel eingebunden.
• ethX steht für das WAN-Interface des Nodes
• ethY ist das LAN-Interface. Es bleibt bestehen, damit der Node administriert werden kann.
• bat0 ist das batman-adv-Interface. Ist ist analog zu gluon in die Bridge br-freifunk eingebunden, damit clients roamen können
• br-freifunk bridged Infrastruktur-Netz und bat0. Es hat die für Clients sichtbaren Adressen. Die zugewiesenen Netze Netze 10.59.64.0/24 und fdd3:5d16:b5dd:f040::/64 sind hierauf geschaltet.
• ppp0 ist der Endpunkt des VPNs (hide.me, CCC, etc.). Es verfügt über extern erreichbare Adressen.
• tap0..N, l2tpeth0..N stehen für beliebige viele fastd oder L2TP-Tunnel. Sie werden über andere Netze (LAN, WAN, Master) aufgebaut - z.B. für Richtfunkstrecke oder verbessertes Roaming.
  Bei direkten Ende-Zu-Ende Verbindungen erzielt l2tp die bessere Performance. fastd kann hingegen einfacher konfiguriert werden und erlaubt Verschlüsselung.
  L2TP und fastd-Links werden nur dann in bat0 eingebunden, wenn tatsächlich Roaming über die verbundene Endpunkte erfolgen soll.

IP-Adress- und -Subnet Zuweiseung

Dem Knoten werden verschiedene IP-Adressen und Subnetze zugewiesen:

• Der Benutzer weißt manuell ein eindeutiges /24 IPv4 und ein /64 ULA-Netz zu. Beispiel: 10.59.64.0/24 und fdd3:5d16:b5dd:f040::/64.
  Innerhalb einer Community wird der gleiche ULA-Prefix (/48) verwendet - verschiedene Communities verwenden verschiedene ULA-Prefixes. Die ULA-Adressen werden im ICVPN routed. Für IPv4 für ein privater Adressbereich aus 10.0.0.0/8 oder 172.16.0.0/12 genutzt. 192.168.0.0/16 wird nicht verwendet um Überschneidungen üblichen Adressbereichen auf SOHO-Routern zu vermeiden.
• Der Node erhält vom ISP (VPN-Provider!) ein größeren Range per DHCPv6-Prefix Delegation. (Beispiel /48). Ein /64 Netz daraus wird im Master-Netz verteilt - nicht aber im batman-adv-Mesh. Die restlichen Netze werden per DHCPv6 Prefix-Delegation auf dem ad-hoc Interface an Benachbarte Knoten weiter gegeben.
• Im Master-Netz verteilt der Knoten per radvd und DHCPv4 die manuell konfigurieren Netze und einen über ad-hoc oder VPN erhaltenen /64 Bereich. Alle IPv6-Prefixes werdrn per radv off-link als offlink angekündigt, damit kein ND-Discovery zwischen Clients nötig ist.

Batman Advanced und ebtables

Batman-Advvanced wird wie folgt konfiguriert.

• Der Gateway-Mode wird verwendet. Jeder Node ist Gateway. Der DHCP-Server verteilt Adressen aus dem zugwiesenen /24 Netz
• Distributed ARP-Tabels werden verwendet.
• Beacon-Interval ist 5s
• Nach bat0 gehender Broadcast und Multicast-Traffic wird per ebtables gefiltert. (TBD: Vom Node ausgehende Neighbor-Soliciation für's Roaming erlauben?).
• DHCP(v4) und ARP werden nicht gefilert, da sie innerhalb von batman-adv in unicast umgewandelt werden.

Routing

Da OpenWRT keine Network Namespace kann, wird Policy Routing verwendet.

• Alle Freifunk-Interfaces (blaue Interfaces in Abb. 1) und das VPN verwenden eine gemeinsame Routing Table 511 für incoming und outgoing traffic.
• babeld wird für das dynamische Routing verwendet. Ad-Hoc, sowie alle L2TP-Tunnel werden in Babel eingebunden.
• TBD:
  • Multicast-Routing
  • ICVPN-Routing

Firewalling

Firewalling wird verwendet, um bei einer Fehlkonfiguration den Node zu schützen und Interfaces im Routing zu trennen.

• Die Zonen freifunk und vpn werden eingeführt.
• Alle blauen Interfaces (vgl. Abb.1) werden freifunk zugeordnet - das VPN der vpn-Zone.
• Forwardings innerhalb der Freifunk-Zone werden erlaubt. Forwarding von Freifunk nach VPN. Nach bedarf können Forwardings von LAN nach Freifunk oder VPN erlaubt werden.
• Die vpn-Zone verwendet NAT und MSS-Clamping (TBD: Berliner VPN will kein NAT)
• Aus freifunk und vpn werden eingehende Verbindungen verboten. Ausgn: ICMP und DHCP. Bei Bedarf kann SSH freigegeben werden.
• In freifunk werden eigehende babeld-Verbindungen (6696/udp) erlaubt.
• Eingehende fastd Verbindungen werden aus dem WAN erlaubt. So können verschiedene Mesh-Inseln miteinander verbunden werden. der zugh. Link wird nicht in batman-adv eingebunden.

Fazit

• Die Architektur adressiert viele der identifizierten Probleme
• l3roamd könnte als Alternative zu batman-advanced interessant sein
• Die Architetkur ist nicht auf babel festgelegt - andere Protokolle sind denkbar. Anforderungen sind:
  • Wired und Wireless Metrik möglich (ggf. auch durch vers. Protokolle!)
  • Source Sepecific Routing (wg. DHCPv6-PD über ad-hoc)
• Die Teilnahme am Netz erfordert mehr Aufwand beim User - Adressen müssen konfiguriert werden.
• Aktuell gibt es keine schöne Karte oder Visualisierung für babel - Ortsangaben + IP-Netze Wiki gestützt verwalten?
• Das Netz sollte über fastd-Links dezentral verbunden werden können. Dieses P2P-Netz wäre zu organisieren - Liste mit dyndns-Namen im Wiki?