public-wiki/netzstruktur.md

Netzstruktur

Stand April, 2019 Hier folgt der Versuch die Netzwerkstruktur des Reudnetzes zu beschreiben, Diese Beschreibung wird ergängt durch eine Beschreibung der Organisazionsstruktur.

Überblick

Das Reudnetz verteilt einen Anschluss über Richtfunkstrecken und Kabel zu vielen Nutzern die sich so eine gemeinsame Verbindung zum Internet teilen. Neue Nutzende werden manuell durch Personen des Reudnetzes ans Netzwerk angeschlossen.

Mögliche Verbesserungen:

Das Reudnetz peert mit mehreren Providern und stellt über mehrere Uplinks Verbindung zu Internet zur Verfügung. Das Reudnetz bietet Bandbreite im Freifunknetz an und unterstützt dessen Ausbau. Anschlüsse bestehen dann aus IPSec-Tunneln (wireguard) innerhalb des Freifunknetzes.

Uplink

Die Verbindung zum Internet besteht über eine Glasfaser der HLKomm, die im Keller der Wurze ankommt. Die HLKomm betreibt daran einen "µFalcon" Router, der Gigabit Ethernet ausspuckt. Von der HLKomm bekommen wir

IPv4 Subnet: 80.64.181.144/29 IPv4 Gateway: 80.64.181.158

IPv6 Prefix: '2a02:238:f04b::/48' IPv6 Gateway: '2a02:238:1:f04b::1'

geroutet.

Die Routing-Server

Hinter dem Uplink hängt ein unmanaged Netgear Gigabit Switch (4 ports), an dem Sol, Core1, Core2 und die meshgw-vm auf sol hängen.

Sol

Ursprünglich war Sol der einzige Server im Reudnetz. Auf Sol läuft Debian. Sol übernimmt das Routing und dient als vm-host für einige interne Dienste des Reudnetzes.

Sol als Router

Sol stellt den zentralen Knotenpunkt in der Verbindung zwischen den Kunden-Antennen und dem Internet dar. Sol ist Router, NAT, DHCP-Server DNS-Server, Firewall und traffik shaper. GeNATet wird zwischen 80.64.181.145 und den internen Addressen. Als DHCP-Server verteilt Sol Adressen, an alle Geräte, die ein static lease in der Konfiguration hinterlegt bekommen haben. Diese werden aus dem Ansible generiert. Ebenso werden die Routen zu den Antennen generiert. Das Traffik-shaping findet so statt, das bei Überschreiten eines Limits innerhalb der 95/5 Abrechnung eine Codel-Queue activiert. Dies erledigt das neunzehn-script.

Sol als vm-host

Auf Sol laufen auch sekundäre Dieste die für den Betrieb des Reudnetzes notwendig sind:

• git
• mattermost
• monitoring
• helpdesk
• proxy
• meshgw Das vm-setup ist auf der Basis von QEMU-KVM gebaut.

Mögliche Verbesserungen

Um eben nicht alles auf einem Gerät zu haben, wäre es Sinnvoll, vm-hosting und Routing zu trennen. Aus diesem Grund wurden Core1 und Core2 angeschafft. Auf ihnen sollte dann das Routing statt finden, sodass Sol nur noch die internen VM hostet.

Core 1 und 2

Die beiden Server sind zwei PCEngines APU Boards. Beide sind im selben Gehäuse untergebracht. Auf beiden ist OpenWRT installiert. Sie wurden angeschafft, um das Routing zu übernehmen und sind doppelt verfügbar um Redundanz bei Ausfall eines Boards zu haben. Tatsächlich werden sie aber aktuell ganz anders eingesetzt. Core1 macht aktuell das Routing für IPv6 und Core2 ist nicht in Verwendung und wird von Paul höchstens gelegentlich für Experimente benutzt.

meshgw-vm

Die meshgw-vm ist eine VM auf Sol. Sie wird hier gesondert erwähnt, weil sie den Zugang zum Internet für den libremesh-zweig darstellt und eine eigene public IP hat. Auf ihr läuft OpenWRT (bzw. libremesh).

Der Stern

An den Routing Servern hängen noch ein Paar Switches, aber ab da verteilt sich das Netz mehr oder weniger sternförmig. Die internen Port von Core1, Core2 und Sol gehen in eine managed 5port gigabit-switch. Von dort geht ein Kabel hoch zum Dach und eines in den "Wurze-Router"

Der Wurzerouter

Wurze2-1r ist ein Ubiquiti EdgeRouter auf dem OpenWRT läuft. An ihm hängen die Wurze, das Klaushaus und der Laden des Wasserschaden e.V. Dieser Router nimmt eine ähnliche Rolle ein wie die Antennen bei den anderen Kunden.

Das Dach

Unterm Dach wird der Link zu den Routing-Servern im Keller von einem Allnet switch an mehrere (aktuell ungefähr 12) Accesspoint auf dem Dach verteilt. Hier sind unterschiedliche Geräte im Einsatz, meiste jedoch "Ubiquiti Nanobeam M5" Router. Auf ihnen läuft die Stock-Firmware Diese sind als Bridges konfiguriert, greifen also nur auf Layer 2 in den Traffik ein. An jeden AP hängen 1 bis 6 Kundenantennen.

Kundenantennen

Die Kundenantennen sind als WLAN-Client mit einem der APs verbunden. Sie machen auf Kundenseite DHCP und verteilen das Kundennetz. Sie NATen jedoch nicht, sondern verteilen nur ein Netz weiter, zu Sol geroutet wird. Nur dort findet NAT statt. (Routet clients) Auf ihnen ist eine Firewall konfiguriert, die Zugriffe aufs interne Netz unterbindet. Von dort aus geht ein Ethernetkabel zu den Kunden, die Darauf per DHCP Adressen aus ihrem Netz bekommen.

Switched Client

In diesem Setup hängt hinter der Antenne noch ein managed switch, der VLANs der Antenne an seine Ports verteilt. Er dient somit als Port-Vervielfältiger der Antenne und wird überall dort verwendet, wo mehr als ein Anschluss von einer Antenne bedient wird. Die Switches bekommen aus Sicherheitsgründen keine IP im internen Netz und sind nur direkt von der Antenne aus zu erreichen.

Hop

Bei einem Hop, hängt hinter der Client-Antenne noch ein weiterer AP, an dem wiederrum weitere Clients hängen können. Dies kann notwendig sein, um Orte ohne Sichtkontakt zur Wurze zu erreichen. Da jeder Hop jedoch mit einem gewissen Latenz, Ausfallsicherheits und Bandbreiten Verlust einhergeht, sind gerade mehrere Hops hintereinander unbedingt zu vermeiden.

Mögliche Verbesserungen

• Der 5port gigabit switch hinter Sol und core* sollte ausgetauscht werden
• Alles auf OpenWRT umstellen. Das setzt aber vorraus, das OpenWRT entsprechend angepasst wird.
• Die Ganze Struktur könnte eher Ringförmig gebaut werden, mit einigen Super-Hops, die zuverlässig mit viel Bandbreite angebunden sind.