Freifunk Rheinland Net 2.0-Korrektur

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.

Zielsetzung

Wir wollen folgende Anforderungen umsetzen:

• Konnektivität: Global geroutete IPv6-Adressen und im Freiunk-Netz geroutete IPv4-Adressen (plus Peering mit DN42 und andere)
• Dezentralität: Mehr redundante Anbidungen pro Wolke, Transfernetz mit redundanten Gateways
• Autonomie: Communitys erhalten eigene Teile der Infrastruktur, die untereinander verbindet
• Skalierbarkeit: Kleine Communities zusammenlegen, niedriger technischer Aufwand für neue Communitys

Es gab Forderungen nach internen Diensten im Freifunk. Das halten wir nur dann für sinnvoll, wenn diese internen Dienste auch extern verfügbar sind. Das heißt, dass jeder Mensch an seine Freifunk-Nodes einfach Geräte anschließen kann, die dann sofort im Internet sind und dort auch von außen erreichbar. Eigener Mailserver zu Hause? Kein Problem. E-Mails direkt zum Server des Nachbarn funken? Wie subversiv.

Wenn alles gut läuft, fügen wir der gesamten Freifunk-Community etwas hinzu: nämlich ein Modell für Skalierbarkeit in Richtung mehr Communities. Der Freifunk Rheinland e.V. hat die Möglichkeit, mehre Communities zu organisieren und für deren Verbindung zu sorgen.

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
• NAT belastet Queens übermäßig

Neue Funktionalitäten

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.

• Tinc ist nicht empfohlen, es meshed selber und sorgt damit für unnötig viele rebroadcasts! Das gleiche gilt für N2N Lcb01 (Diskussion)

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.

• Hier einfach NPT66 verwenden, ist mit iptables kein problem. So können wir ein /64 netz auf alle communities mappen. Intern werden ULA adressen verwendet. Lcb01 (Diskussion)
• Siehe: http://packetpushers.net/thank-goodness-for-nat66/ Lcb01 (Diskussion)

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.

• Dies zerstört die Funktionalität der FSM wie sie momentant implementiert ist und gefährdet die autonomie der Firmware: Zentrale Dinge wie VPN / IP-Listen wo man sich einträgt sind optional und dürfen bei Ausfall nicht den Betrieb der lokalen Wolke gefährden. Lcb01 (Diskussion)