Freifunk Rheinland Net 2.0

Dieses Dokument soll unsere Bemühungen zusammenbringen, eine neue Struktur in unserem Netzwerk aufzubauen. Status: Konsensfindung. Bitte anschauen und Verbesserungsvorschläge einbringen. Autoren: takt, nomaster.

Argumente gegen bisherige Struktur

Die bisherige Struktur ist in mehreren Punkten hinreichend widerlegt:

• N2N zwischen den Nodes wird wegen NAT fast ausschließlich über Supernodes geleitet. Zuviel Traffic-Verbrauch dort und Ausfälle.
• N2N skaliert nicht, weil für jede weitere Node mit Internet-Anschluss (Queen) zu jeder vorhandenen Node eine eigene Verbindung aufgebaut wird.
• OpenVPN von den Queens zum Aggregator ist Single Point of Failure
• OpenVPN auf den Nodes ist ein zu großes Software-Paket
• OpenVPN bietet wenig Bandbreite wegen schwacher CPU in den Plastik-Routern
• OpenVPN-Accounts händisch anlegen und auf den Nodes konfigurieren ist aufwändig
• DHCP, NAT, DNS-Relaying belasten Queens übermäßig
• Rouge (unrechtmäßige) Router Advertisements und DHCP-Server verhindern Konnektivität
• Single Point of Failure beim VPN-Aggregator (DS9)
• Tote Verbindungen zum Tunnel-Broker werden nicht immer erkannt

Möglich ist, dass wir die Zustands-Automaten auf den Nodes (die zwischen Queen, Drohne und Robinson wechseln), gänzlich abschaffen. Clients sollen sich selber Link-Local-Adressen generieren. Wenn Internet dran ist, machen das einfach die Gateways.

Möglich ist, dass wir das Captive Portal abschalten oder zumindest auf HTTP-Verbindungen beschränken, da in diesem Entwurf Betreiber von Internet-Zugängen vor Ort nicht mehr als Störer haftbar zu machen sind, auch wenn sie keine Tunnel-Verbindung manuell eingerichtet haben; eine Automatische Registrierung der Nodes ermöglicht dies.

Neue Funktionalitäten

Broadcasts

Freifunk Communities können nicht beliebig groß werden. Das liegt daran, dass ein Teil des Netzwerk-Traffics ins gesamte Netzwerk einer Community verbreitet werden muss. Dieser Broadcast-Traffic erreicht alle Endgeräte im Netzwerk. Das Netzwerk nennt man daher "Broadcast-Domäne".

Accounting:

Die Broadcast-Pakete sollen pro Knoten accountet (gezählt) werden. Das Limit ist (spätestens) dann erreicht, wenn die Downstream-Verbindung einer Node (DSL-Anschluss oder ähnliches) mit Broadcast-Paketen verstopft ist. Phänomen: Abgeschnittene Spitzen auf dem Graphen des Broadcast Traffics einer Node. Collectd soll in default Konfiguration die entsprechenden Informationen sammeln.

Rate-Limiting:

Politische Fragestellung: Sollen Broadcasts limitiert/unterdrückt werden, um das oben genannte Problem zu vermeiden? Angreifer könnten beliebig viel Broadcast-Traffic verschicken, um das Netzwerk zu verstopfen (Flooding). Zumindest sollen Nodes also den Broadcast-Traffic limitieren, um einen solchen Denial-of-Service-Angriff zu unterbinden.

Filtering:

Es soll innerhalb des Subnetzes jeder Community jeweils ein Subnetz für Gateways definiert werden. DHCP-Adressvergaben (DHCPOFFER) und IPv6 Router Advertisements (RA) sollen nur von diesem Subnetz ausgehen. Alle sonstigen DHCPOFFER und RA werden auf den Nodes gefiltert. Hierdurch sollen nicht nur Angriffe verhindert, sondern auch Konfigurationsfehler abgefangen werden.

Gateway High Availability:

Gateways sollen ein First Hop Redundancy Protocol (FHRP) verwenden, um Verfügbarkeit zu erhöhen. Dabei kann die IP-Adresse des Default-Gateways den Host wechseln. Eine Implementierung erfolgt entweder per VRRP oder CARP. Da für IPv4 NAPT (Network-Adress-Translation mit Port-Mapping wie üblich) verwendet wird, ist anzudenken die Verbindungstabellen der Gateways zu synchronisieren. Für IPv6 soll dynamisches Routing verwendet werden.

Backbone:

Die Gateways der Communities sollen per dezentralem VPN (N2N oder Tinc) miteinander verbunden werden. Auf diesem Schicht-2 Netz soll ein Interior-Gateway-Protocol (IGP) verwendet werden, um Routing-Tabellen auszutauschen.

IPv6-Konnektivität:

Diese soll vorerst über einen oder mehrere Tunnel-Broker (z.B. SIXXS, HE.net) hergestellt werden. Tunnel-Broker weisen uns jeweils ein IP-Subnetz /48 mit 80 Bit Adressraum zu. Die Tunnel terminieren auf zusätzlichen Knoten, die am Backbone angeschlossen sind. Ihre Routen verteilen sie per IGP.

Außerdem ist anzudenken diese Knoten mit Netzen anderer Freifunk-Communitys peeren zu lassen (BGP). Dort werden Autonome Systeme (AS) mit Nummern aus dem Privatbereich verwendet. Mittelfristig möchten wir öffentliches Peering mit einem offiziellen AS.

IPv4 Konnektivität:

Analog zur IPv6-Konnektivität verwenden wir hier Tunnel-Broker. Weil wir dort jeweils nur eine einzige geroutete Adresse erhalten, machen wir NAPT. Der Traffic wird über mehrere Tunnel-Broker verteilt. Die Gateways überprüfen die Qualität der Verbindung und melden sich bei Ausfällen selber ab.

Das jetzige IPv4-Netz 10.78.0.0/16 soll als einziger Adressbereich für Freifunk Rheinland verwendet werden. Dieses Netz soll in 32 Subnetze zu je 2048 IP-Adressen (/21) unterteilt werden. Jede Community erhält dann ein /21 Subnetz.