Portal:Netz/Konzept:L3Richtfunk

Grundidee von RedDog/Tim

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)

Unser Testaufbau im Fablab Nürnberg (Nürnberger Hood) sah folgendermaßen aus:

Das PI (Olsr Router) hatte dabei folgende IP Konfiguration:

• eth0: 10.50.40.201 (rechte Seite Nürnberger Hood)
• eth1: 10.50.240.200 (linke Seite aux Hood, mit nicht vorhandenen Internetuplink!)

(Kleine Info nebenbei durch die verdammt ähnlichen IPs kamen wir mal richtig durcheinander haben uns dann irgendwann gewundert warum 10.50.40.200 nicht erreichbar ist und solche Scherze, ich habe echt eine ungünstige Kombination gewählt)

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 (später wurde eine IP per DHCP vom Olsr Router geholt).

Für den Tunnel durch das Freifunknetz wurden folgende IPs verwendet:

• Internetgateway: 10.50.252.252
• Olsr Router (Pi): 10.50.252.253

Dummerweise endete der Tunnel auf meinem Gateway (fff-gw-cd1.fff.community) das hat die Sache etwas verkompliziert aber dennoch funktioniert. Im Produktiveinsatz ist es sehr empfehlenswert einen Gateway zu wählen der in der gleichen Hood steht und dort alles enden lassen damit unnötige Hops vermieden werden. In meiner weiteren Erklärung nehme ich das auch so an auch wenn es in unserem Aufbau nicht so war, es spielt aber bei der Funktion keine Rolle.

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 rule add from 10.50.32.4/32 table main
ip rule add to 10.50.32.4/32 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, dabei wurde die oben genannte ip rule schon direkt mit eingefügt.:

 
auto olsrrouter
iface olsrrouter inet static
 address 10.50.252.253
 pre-up ip -4 tunnel add $IFACE mode gre local 10.50.40.201 remote 10.50.32.4 ttl 255
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255

up ifconfig $IFACE multicast
 pointopoint 10.50.252.252
 post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu
 post-up ip rule add iif $IFACE table fff
 post-up ip rule add from 10.50.0.0/16 table fff
 post-up ip rule add to 10.50.0.0/16 table fff
 post-up ip rule add to 10.50.32.4/32 table main
 post-up ip rule add from 10.50.32.4/32 table main
 post-down ip rule del iif $IFACE table fff
 post-down ip rule del from 10.50.0.0/16 table fff
 post-down ip rule del to 10.50.0.0/16 table fff
 post-down ip rule del to 10.50.32.4/32 table main
 post-down ip rule del from 10.50.32.4/32 table main
 post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu
 post-down iptunnel del $IFACE 

Die Gegenseite auf dem Internetgateway ergibt sich dabei von selbst. Somit bricht der Tunnel nach holen der Olsr Routen nicht mehr zusammen. Allerdings war nach dem starten von Olsr das Pi ebenfalls nicht mehr erreichbar dies wurde durch folgende Routingeinträge gelöst:

 
ip rule add from 10.50.40.0/21 table main
ip rule add to 10.50.40.0/21 table main 
ip rule add from 10.50.240.0/21 table main
ip rule add to 10.50.240.0/21 table main 

(beim schreiben jetzt fällt mir gerade auf ob es richtig ist 10.50.240.0/21 zu nehmen, ich hab ja ohne Internetuplink keine Verbindung zu dem ganzen Netz, eventuell wäre 10.50.240.192/26 richtig, muss ich noch mal drüber nachdenken) auch dies wurde automatisch konfiguriert:

 
iface eth0 inet static
address 10.50.40.201
netmask 255.255.248.0
gateway 10.50.40.10
post-up ip rule add from 10.50.40.0/21 table main
post-up ip rule add to 10.50.40.0/21 table main
post-down ip rule del from 10.50.40.0/21 table main
post-down ip rule del to 10.50.40.0/21 table main

iface eth1 inet static
address 10.50.240.200
netmask 255.255.248.0
#gateway 10.50.248.2 (war von mir Unsinn, es darf natürlich nur einen GW geben!
post-up ip rule add from 10.50.240.0/21 table main
post-up ip rule add to 10.50.240.0/21 table main
post-down ip rule del from 10.50.240.0/21 table main
post-down ip rule del to 10.50.240.0/21 table main 

Zudem kamen wir zu der Erkenntnis, damit die Rückroute aus dem Freifunknetz funkioniert Olsr die linke Seite announcen muss. Somit haben wir uns den IP Bereich 10.50.240.192/26 reserviert und an Olsr announced. Als DHCP wurde nun der Bereich 10.50.240.210 bis 10.50.240.230 auf eth1 konfiguriert. Mit einer IP aus diesem Bereich wurde dann auch ein Internetzugang möglich. Wichtig ist hier, auf dem aux Router muss zwingend der Broadcastfilter angepasst werden da sonst DHCP Serverpakete eingehend auf den Clientport verworfen werden und man somit vom Olsr Router keine IP bekommt!

Der gesamte Weg des Traffics sieht nun so aus:

Die rot gestrichelte Linie ist der Weg vom Chris Laptop ins Internet oder Freifunknetz, die orange gestrichelte Linie ist der Weg zurück. Für Olsr Routinginformationen zwischen Gateway und Olsr Router wird natürlich der GRE Tunnel verwendet (hier nicht expliziet eingezeichnet).

Da auf dem Internetgateway rechts unten

• 10.50.240.192/26 erreichbar über 10.50.252.253

in der Routingtabelle existiert, läuft der Traffic leider über den GRE Tunnel zurück zum Client. Hier müsste eine Möglichkeit geschaffen werden Olsr zu überreden folgendes rauszusenden:

• 10.50.240.192/26 erreichbar über 10.50.40.200

Damit würde auch der Rücktraffic direkt über das Freifunknetz laufen und nicht in den Tunnel verpackt werden. Der Tunnel wird dann nur noch für den Austausch der Olsr Routen verwendet was akzeptiert werden kann.

Dieser Aufbau ist theoretisch schon verwendbar allerdings muss an dem zuletzt genannten Problem noch dringend gearbeitet werden.

Sinnvoll ist dieser Aufbau zum Beispiel bei folgender Konstellation:

Man hat ein Flüchtlingsheim mit 200 Bewohner und der AUX Hood laufen. Leider hat man dort nur eine sehr knappe Internetanbindung die immer überlastet ist. Daneben steht allerdings ein großer Freifunk Aufbau der allerdings die normale Hood verwendet. Nun würde man gerne "einige" Flüchtlinge diese Brücke ermöglichen und von der Aux Hood in die Nürnberger Hood meshen (man will hier also hauptsächlich Traffic von Aux nach normale Hood los werden). Man vergibt per DHCP als in diesem Beispiel 20 IPs an den Olsr Router welcher eine Route über das normale Freifunknetz aufbaut. Somit wird die Aux Hood und der langsame dort vorhandene Internetanschluss um diese 20 Clients entlastet, hat der Olsr Router dort vor Ort keine freien IPs mehr geht der Rest über das normale Aux Freifunkinternet da der dortige Gateway weiterhin IPs vergibt. In meiner Zeichnung oben hätte da also der Router von Client "Chris" einen Internetuplink.

Ich will mich hier nochmal bei Jan bedanken für die tolle Zusammenarbeit, ich habe hiermit sehr viel über Routingtabellen gelernt. Danke!

Nächste Erweiterung von ChristianD in Fürth

Habe die IP Adressen wieder auf Fürth geändert. Das Pi spricht nun auf 10.50.32.152 dementsprechend wurden die Routingeinträge bei dem Interface auf dem Pi und die IPs des GRE-Tunnels angepasst. Der Umbau auf Fürth klappte problemlos. Ich hab mich ein wenig mit Iptables beschäftigt und hab mir folgendes zusammengebaut:

iptables -t nat -A POSTROUTING -o olsrrouter -j SNAT --to-source 10.50.32.152

Ziel war es, alles was auf dem Interface olsrrouter gesendet wird, die Quellip auf 10.50.32.152 zu ändern. Damit sollte die Olsr Gegenseite eigentlich diese IP im Olsr und damit schlussendlich auch in die Routingtabelle eintragen. Dies ist so auch geschehen und 10.50.32.4 (mein Gateway wo der GRE Tunnel endet) hatte auch

• 10.50.240.192/26 erreichbar über 10.50.32.152

drinnen stehen.

Leider war dann von der aux Seite kein Internetzugang mehr möglich. Eventuell funktioniert das ganze auch nicht, weil Olsr noch das falsche Interface dort stehen hat. Ein kurzes traceroute zeigte auf, das der ausgehende Traffic nun durch den Tunnel geht und nicht mehr durchs Freifunkinterface (auch ohne der Iptables Regel!).

(Screenshot entstand ohne der iptables Regel da sonst kein traceroute möglich wäre)

Warum das so ist und in Nürnberg anders war muss analyisiert werden.

Was aber festgehalten werden kann, trotz das ich den durch den Tunnel (im Tunnel im Tunnel...) surfe, ist das ganze angenehm und schnell und bereitet augenscheinlich keine Probleme. Pingzeiten liegen bei ~80-120ms, Speedtest immer noch bei einigen Mbit/sec (immerhin Laptop Wlan -> Aux Router -> Raspberry Pi -> FFF-Router -> weiterer FFF-Router -> WAN -> Gateway -> Mullvad-VPN).