Freifunk Rheinland Net 2.0: Unterschied zwischen den Versionen

Aus Freifunk Rheinland e.V.
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
(Diagramm)
 
(21 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Dieses Dokument soll unsere Bemühungen zusammenbringen, eine neue Struktur in unserem Netzwerk aufzubauen. Status: Konsensfindung. Bitte anschauen und Verbesserungsvorschläge einbringen. Autoren: [[Benutzer:Takt|takt]], [[Benutzer:Nomaster|nomaster]].
Dieses Dokument soll unsere Bemühungen zusammenbringen, eine neue Struktur in unserem Netzwerk aufzubauen. Status: Konsensfindung. Bitte anschauen und Verbesserungsvorschläge einbringen. Autoren: [[Benutzer:Takt|takt]], [[Benutzer:Nomaster|nomaster]].


=Zielsetzung=
=Zielsetzung=
Zeile 21: Zeile 22:
* OpenVPN bietet wenig Bandbreite wegen schwacher CPU in den Plastik-Routern
* OpenVPN bietet wenig Bandbreite wegen schwacher CPU in den Plastik-Routern
* OpenVPN-Accounts händisch anlegen und auf den Nodes konfigurieren ist aufwändig
* OpenVPN-Accounts händisch anlegen und auf den Nodes konfigurieren ist aufwändig
* DHCP, NAT, DNS-Relaying belasten Queens übermäßig
* NAT, DNS-Relaying belasten Queens übermäßig
** DHCP ist kein Problem, die DHCP Probleme aus der Vergangenheit kommen von uhttpd welcher in manchen situationen 100% CPU zieht und Dienste wie DHCP funktionieren dann nicht mehr richtig.
* Unzureichende Verbindungstests bei VPN nutzung führt zu "Rogue" Queens / Tote Verbindungen zum Tunnel-Broker werden nicht immer erkannt
** Außerdem sollte nicht zu viel DHCP-Traffic Fastd fließen, hier für gibt es den VPN-Hybrid Queen Mode in der neuen Firmware (DHCP verteilt nur den Exit-VPN als Gateway&DNS)
* Rouge (unrechtmäßige) Router Advertisements und DHCP-Server verhindern Konnektivität
** Die RA's kommen von eine Bug in der jetzigen radvd config [[Benutzer:Lcb01|Lcb01]] ([[Benutzer Diskussion:Lcb01|Diskussion]])
** Multiple DHCP-Server sind alternativlos, die Firmware muss auch ohne Fastd und zentrale Infrastruktur funktionieren. DHCP-Scopes werden per Batman-adv sowieso limitiert. Gateways ohne Verbindung müssen den Batman-Adv server mode automatisch abschalten [[Benutzer:Lcb01|Lcb01]] ([[Benutzer Diskussion:Lcb01|Diskussion]])
* Single Point of Failure beim VPN-Aggregator (DS9)
* Single Point of Failure beim VPN-Aggregator (DS9)
* Tote Verbindungen zum Tunnel-Broker werden nicht immer erkannt
** Neuer VPN-Routed Queenmode checkt mittels pings über die VPN-Verbindung ob diese noch funktioniert und wechselt notfalls in den ghost / robinson oder drone state ( je nach mesh umgebung) [[Benutzer:Lcb01|Lcb01]] ([[Benutzer Diskussion:Lcb01|Diskussion]])


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.
** Nein, dies ist nach wie vor priorität: Dies soll keine zweite Lübeck-Firmware werden! [[Benutzer:Lcb01|Lcb01]] ([[Benutzer Diskussion:Lcb01|Diskussion]])


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=
** Ist Abschaltbar in der neuen Version.


=Neue Funktionalitäten=
[[Datei:Freifunk-Rheinland-Net-2.0.png|thumb|600px|Diagramm des Entwurfs]]


==Broadcasts==
==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".
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".
** Wird ab der neuen version mittels ebtables gefiltert, Split horizon für den VPN-Link wird gerade eingebaut. [[Benutzer:Lcb01|Lcb01]] ([[Benutzer Diskussion:Lcb01|Diskussion]])
 
Broadcasts und dergleichen werden limitiert, nur gewisse Protokolle wie etwa ARP, IPv4, IPv6, ICMP, ICMP6 usw sind erlaubt über den VPN-Link zu fließen.


==Accounting:==
==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.
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.
** Wird ab der neuen version mittels ebtables gefiltert, außerdem haben die Nodes nciht genügend CPU-Leistung dafür jedes Paket zu zählen.  [[Benutzer:Lcb01|Lcb01]] ([[Benutzer Diskussion:Lcb01|Diskussion]])


==Rate-Limiting:==
Daten sollen zentral gespeichert werden für Logging (Keine User bezogenen Daten werden gespeichert)
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.
** Politik hat hier nix zu suchen: Ohne filterung ist ab etwa 30 Nodes/Queens schluss. [[Benutzer:Lcb01|Lcb01]] ([[Benutzer Diskussion:Lcb01|Diskussion]])


==Filtering:==
== Gateways ==
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.
** DHCP muss je nach Queenmode gefiltert werden: z.b. im VPN-Hybrid mode


==Gateway High Availability:==
Jede Domäne bekommt mindestens zwei [[Super Nodes]], die per B.A.T.M.A.N. im Netz erreichbar sind und sich als Gateways ankündigen. Clients werden durch diese Technik einem der Gateways zugewiesen und erhalten von diesem per DHCP Adressen. Per IPv6 kündigt jeder Gateway ein 64-Netz an. Clients nehmen sich aus diesem per Stateless Address Auto Configuration (SLAAC) eine oder meherere Adressen pro Netz.
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:==
=== High Availability ===
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
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.
 
== Backbone ==
 
Die Gateways der Communities sollen per dezentralem VPN (Tinc) miteinander verbunden werden. An das Backbone-VPN werden zwei [[Backbone Router]] angebunden, die das Intercity-VPN und andere Darknets anbinden. Außerdem routen sie den default Traffic für IPv6.


==IPv6-Konnektivität:==
==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.
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.
** Siehe: http://packetpushers.net/thank-goodness-for-nat66/


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.
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:==
==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.
Die Super-Nodes routen IPv4 traffic über ihre Adresse und übersetzen die sonst nicht zu routenden Adressen des Freifunk-Netzwerks per NAT. Die Gateways/Queens überprüfen die Qualität der Verbindung und melden sich bei Ausfällen selber ab.
** 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 Firmware gefährden.
 
In der Domäne werden Adressen von den Super-Nodes per DHCP verteilt. Hier sollte auf die geographische Nähe der Communities geachtet werden die in einer Domäne zusammen geführt werden. Es wird '''kein''' Subnetting angewendet, die Bereiche werden lediglich organisatorisch getrennt und bilden ein großes Layer 2 Mesh
 
Testfall: Merging von Neuss und Düsseldorf in eine Broadcast-Domäne.
* Freifunk Rheinland ist eine Meta-Community
* Freifunk Düsseldorf und Freifunk Neuss bilden jeweils eine Community
* die Communities Freifunk Düsseldorf und Neuss bilden die Domäne [[Rheinufer]].
* die Community Wuppertal und die umliegenden bilden die Domäne [[Wupper]]
* Andere Domänen benötigen ebenso ungenaue, aber abgrenzbare Namen.

Aktuelle Version vom 28. Januar 2014, 15:14 Uhr

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, DNS-Relaying belasten Queens übermäßig
  • Unzureichende Verbindungstests bei VPN nutzung führt zu "Rogue" Queens / Tote Verbindungen zum Tunnel-Broker werden nicht immer erkannt
  • Single Point of Failure beim VPN-Aggregator (DS9)


Neue Funktionalitäten

Diagramm des Entwurfs

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".

Broadcasts und dergleichen werden limitiert, nur gewisse Protokolle wie etwa ARP, IPv4, IPv6, ICMP, ICMP6 usw sind erlaubt über den VPN-Link zu fließen.

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.

Daten sollen zentral gespeichert werden für Logging (Keine User bezogenen Daten werden gespeichert)

Gateways

Jede Domäne bekommt mindestens zwei Super Nodes, die per B.A.T.M.A.N. im Netz erreichbar sind und sich als Gateways ankündigen. Clients werden durch diese Technik einem der Gateways zugewiesen und erhalten von diesem per DHCP Adressen. Per IPv6 kündigt jeder Gateway ein 64-Netz an. Clients nehmen sich aus diesem per Stateless Address Auto Configuration (SLAAC) eine oder meherere Adressen pro Netz.

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.

Backbone

Die Gateways der Communities sollen per dezentralem VPN (Tinc) miteinander verbunden werden. An das Backbone-VPN werden zwei Backbone Router angebunden, die das Intercity-VPN und andere Darknets anbinden. Außerdem routen sie den default Traffic für IPv6.

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:

Die Super-Nodes routen IPv4 traffic über ihre Adresse und übersetzen die sonst nicht zu routenden Adressen des Freifunk-Netzwerks per NAT. Die Gateways/Queens überprüfen die Qualität der Verbindung und melden sich bei Ausfällen selber ab.

In der Domäne werden Adressen von den Super-Nodes per DHCP verteilt. Hier sollte auf die geographische Nähe der Communities geachtet werden die in einer Domäne zusammen geführt werden. Es wird kein Subnetting angewendet, die Bereiche werden lediglich organisatorisch getrennt und bilden ein großes Layer 2 Mesh

Testfall: Merging von Neuss und Düsseldorf in eine Broadcast-Domäne.

  • Freifunk Rheinland ist eine Meta-Community
  • Freifunk Düsseldorf und Freifunk Neuss bilden jeweils eine Community
  • die Communities Freifunk Düsseldorf und Neuss bilden die Domäne Rheinufer.
  • die Community Wuppertal und die umliegenden bilden die Domäne Wupper
  • Andere Domänen benötigen ebenso ungenaue, aber abgrenzbare Namen.