Portal:Netz/Konzept:L3Richtfunk

Layer 3 Netz über Richtfunk verbreiten.

Bisher gibt es das L3 Netz nur über Internet Tunnel. Dort werden Gateways angeschlossen, die dann mit fastd die "FF VPN nodes" anschließen. Durch ein oder mehrere Gateways wird dann auch das Subnetz definiert.

Wenn zwei Hoods / Subnetze über z.B. Richtfunk verbunden werden sollen, müssen Routing Informationen ausgetauscht werden. Die OLSR Routing Information soll aber nicht direkt in die BATMAN Wolke gesendet werden, weil dann jeder diese Informationen manipulieren kann. Dadurch wäre eine leichte und unschöne Störung des L3-Backbones möglich. Es stand die Überlegung im Raum, ob die OLSR Verbindung durch einen Tunnel über das BATMAN Netz gesendet werden. Tunnel sind dabei aber natürlich overhead und sollten für die gerouteten Nutzdaten nicht verwendet werden.

sOLSR bietet die Möglichkeit die OLSR Daten kryptographisch zu sichern. Ziel soll es sein, dass die Routinginformationen nicht manipuliert werden können. Das Mitlesen oder unterbinden/löschen der Daten ist irrelevant, da olsr dadurch vom Prinzip nicht gestört ist und hierbei nur ein Segment betroffen wäre.

Aktuell scheint sOLSR allerdings jeglichen OLSR Traffic mit einem shared-key zu sichern. Damit es auf unseren Zweck passt, müssten wir dieses erweitern, so dass man neben einer generellen Verschlüsselung auch nur auf einzelnen Interfaces verschlüsselt. Ein weiterer Schritt wäre die sOLSR auch mit einem public-key Mechanismus verwenden zu können.

Wir sollten uns vorher auf jeden Fall olsrdv2 angucken.

Erweiterung von ChristianD

Neben den Problem mit dem Olsr sehe ich ein 2. Problem. In den meisten Fällen wird die Richtfunkverbindung nicht wirklich genutzt:

Der rote Client rechts, hat als Gatewayserver im Normalfall einen Gateway in einem Rechenzentrum in diesem Fall Gateway 1. Selbst wenn Client 1 und mit Client 2 Daten austauschen will, wird vermutlich meist die schnelle Rechenzentrum - Rechenzentrum Verbindung von Olsr bevorzugt bevor die Route erst wieder durch das "langsame" DSL zum obigen Olsr Router aufgebaut wird. Von einer Internetverbindung von Client 1 über Richtfunk zu Gateway 2 brauchen wir hier vermutlich erst gar nicht nachdenken.

Meine Idee sieht nun folgenden Umbau sowie Vereinfachung des Systems vor:

wichtig ist hier zuerst einmal zu wissen, auf dem Olsr Router läuft Olsr und ein DHCP Server der ein paar wenige IPs in eine oder beide Hoods (jeweils aus der richtigem Hood im richtigen Interface) verteilen kann. Olsr announced beide Hoods aber kein 0.0.0.0/0 (Olsr sucht sich dafür also die beste Route selbst wobei man hier dann noch ein wenig am Gatewayflackern drehen muss, sind aber Olsr Einstellungen die relativ leicht sein sollten, sozusagen Feintuning). Batman und fastd ist nicht unbedingt nötig, man kann ihn an Client Ports von Freifunkroutern stöpseln oder einfach über Wlan verbinden. Die Menge an IPs muss je nach erwartete Clients selbstständig entschieden werden. Der Bereich kann u.U. auch relativ klein gehalten werden (wenn z.b. in der Client 2 Seite mit max. 5 Clients gerechnet wird, macht es wenig Sinn dort 255 IPs zu reservieren in so einem Fall 8 IPs reservieren und gut, sollten doch mehr Clients dazu kommen, bekommen sie eben vom Gateway 1 eine IP und nutzen die Richtfunkbrücke dann warscheinlich nicht), sollten alle IPs verbraucht sein, antwortet der DHCP vermutlich einfach nicht mehr und der normale Gatewayserver übernimmt wieder. Bei der Vergabe der IP wird als Standartgateway die IP des Olsr Routers am entsprechenden Interface angegeben. Dadurch entsteht nun der Vorteil das alle Clients die eine IP vom Olsr Router bekommen haben, als ersten Hop am Olsr Router raus kommen. Der Olsr Router kennt nun den besten Weg für das gewünschte Ziel des Client (über die sOlsr Verbindung). Weiterhin entsteht eine Ausfallsicherheit. Sollte die fastd Verbindung ganz rechts unten (-> z.b. sehr langsame DSL Leitung oder eine Leitung die immer wieder ausfällt oder oder...) ausfallen oder extrem langsam werden, kann Client 2 immer noch über die Richtfunkstrecke und die darüber laufende Olsr Verbindung das Freifunknetz und Internet problemlos nutzen da in diesem Fall der Olsr Router die Route entsprechend umbauen sollte.

Allgemein heißt das:

• Client 1 wird (höchstwarscheinlich? Immer?) weiterhin IPs vom Gateway 1 bekommen
• Client 2 wird durch die (meist deutlich schnellere interne) Verbindung zum Olsr Router warscheinlich eine IP vom ihm bekommen bevor Gateway 1 überhaupt antwortet.
• Client 3 wird es wie Client 2 ergehen und vermutlich auch eine IP vom Olsr Router bekommen, je nach Leistung der Richtfunkverbindung kann der Olsr Router aber auch auf dieser Seite keine oder nur sehr wenig IPs vergeben, Client 3 würde dann ganz normal vom Gateway 2 seine IP beziehen.

Das ganze ist sehr flexibel aufsetzbar und muss nach den äußeren Gegebenheiten angepasst werden.

Als Olsr Router setze ich aktuell im Wohnzimmertest ein Raspberry Pi mit 2. USB Netzwerkkarte ein.

Dieses kann aber problemlos durch Routerboards oder gar x86 Rechner ersetzt werden, je nachdem welche Leistung nötig wird. Es müssen nur 2 Netzwerkkarten (oder Wlan) vorhanden sein und Linux drauf laufen.

Aktuelle Probleme:

• sOlsr kann wirklich nur auf alle Interfaces aktiviert werden womit keine Verbindung mehr zu unserem Olsr Netz möglich ist. Das Plugin ist in C geschrieben und in meinen Augen ganz verständlich und nicht zu überfrachtet. Dennoch reichen meine C Kenntnisse dafür nicht aus das anzupassen. Wer sich dazu in der Lage fühlt bitte bei mir melden dann können wir das gerne zusammen angehen. Meine aktuelle (Test)lösung ist ein GRE Tunnel durch das Freifunknetz (Update: Funktioniert leider auch nicht, da überschneiden sich irgendwelche Routinggeschichten sobald Olsr läuft und sich die Routingdaten holt, ist das Pi nicht mehr erreichbar... Wird noch viel mehr Arbeit als gedacht).
• Noch gibt es nach meinen Informationen keinen Standort wo man das ganze in der Praxis umsetzen kann. Ich arbeite daran im Wohnzimmer mit der Aux Firmware (da muss ich wegen versehentlichten meshen nicht aufpassen)
• Die neue 0.5.1 Firmware blockt DHCP Server auf dem Clientport (Wlan seitig auch? Mir unbekannt muss noch geprüft werden). Es muss an dem Router wo der DHCP Server angeschlossen wird, u.U. der Broadcastfilter deaktiviert oder zumindest der Abschnitt mit dem DHCP blocken entfernt werden

Nächste Erweiterung von ChristianD in Zusammenarbeit mit mayosemmel (Jan)

[AKTUELL IN BEARBEITUNG!] Unser Testaufbau sah folgendermaßen aus: Das PI (Olsr Router) hatte dabei folgende IP Konfiguration:

eth0: 10.50.40.201

eth1: 10.50.240.200

als Gateway war 10.50.40.10 eingestellt, damit Jan auf seinen Gateway eventuellen "Fehltraffic" mitschneiden konnte und die Hänger auffindbar waren. Der Laptop "Jan" war auf DHCP gestellt, Laptop Chris für den Anfang auf 10.50.240.202 mit Gateway 10.50.240.200.

Es hat sich herausgestellt, das der GRE Tunnel durch das Freifunknetz in dem moment zusammen bricht, wo Olsr sich die Routingdaten vom Internetgateway durch den GRE Tunnel holt. AUch Zugriff von beiden Seiten auf das Pi war nicht mehr möglich.

Jans Vorschlag waren folgende Einträge in der main Routingtabelle:

ip route add from 10.50.32.4 table main ip route add to 10.50.32.4 table main

wobei die IP Adresse der Gateway ist zu dem der Tunnel aufgebaut wird. Das Tunnelinterface wurde folgendermaßen auf dem Olsr Router (Test Raspberry pi) konfiguriert:

folgt...

Die Gegenseite auf dem Internetgateway ergibt sich dabei von selbst. Somit bricht der Tunnel nach holen der Olsr Routen nicht mehr zusammen.

wird fortgesetzt...