Gluon mit L2TP für Düsseldorf gibts jetzt als experimental Version
Diese Version hat keinen Autoupdater also müssen diese Nodes manuell geupdated werden, ich empfehle beim flashen die Einstellungen zu löschen.
Die Images gibt es hier: http://images.freifunk-rheinland.net/images/gluon/duesseldorf/experimental/
L2TP ist unverschlüsselt. Allerdings kommt Fastd niemals an die Datenrate von L2TP heran.
Dies liegt daran das Fastd im Userspace läuft und alle Daten erst vom Kernel in den Userspace wandern um vom Daemon verarbeitet zu werden und erst dann geht es zurück in den Kernelspace um z.b. über das Wan Interface die VPN Pakete zu verschicken.
L2TP ist auch wenn Fastd ohne Verschlüsselung läuft bis zu 10x schneller
Edit: Ergo kann L2TP die Offloader in den meisten Fällen unnötig machen
Speed ist nicht alles. Für den einen oder anderen Knotenaufsteller ist es essentiell das die Daten welche von seinem Freifunk Knoten übertragen werden bis zum Gateway/Supernode verschlüsselt sind. Auch die meisten unserer Erklärungen und Grafiken die zeigen wie Freifunk funktioniert, sind genau so angelegt.
Die Verschlüsselung bietet auch bei Fastd kaum Anonymität da das Mesh selbst unverschlüsselt ist, die Störerhaftung ist mit L2TP-VPN genau so auf Seiten des FFRL als Provider wie es bei Fastd der Fall ist.
Nach außen hin ist man nach wie vor aus dem FFRL Netz unterwegs. Der Payload ist weiterhin enkapsuliert.
Außerdem kann ein Angreifer der Daten abgreifen möchte dies über L2TP genau wie bei Fastd ziemlich einfach erreichen.
Man in the Middle Angriffe sind z.b. jederzeit möglich indem der Angreifer MAC oder IP-Adressen der Gateways spoofed. Oder er betreibt selbst einen Fake-Gateway um Clients abzufischen. Freifunk ist kein sicheres Medium, egal ob die Uplinks verschlüsselt sind.
Was du sicher meinst sind Firewalls die die Daten auf Layer 7 analysieren, dies ist aber äußerst kostspielig für Provider und wenn der Elan schon da ist dies zu tun dann kann man auch einfach den Betreiber hinter einem Fastd VPN herausfinden. Anhand der Remote-Adresse lässt sich z.b. herausfinden zu welchem Supernode die Fastd Daten fließen. Zu dem Zeitpunkt weiß der Angreifer schon das es sich um einen Freifunk Node handelt und von welchem DSL-Anschluss diese Daten kommen.
Dies ist aber ein Szenario welches nur angewendet werden würde wenn der DSL-Anschluss schon identifiziert wurde. Irgendwoher muss man ja wissen das genau von diesem Anschluss illegale Downloads initiiert wurden.
Dies wird aber dadurch unterbunden das der Traffic über das FFRL Backbone ins Internet gelangt, dies macht das Szenario also noch unwahrscheinlicher
Die Sicherheit ist in beiden Fällen relativ dazu wie viel Aufwand ein Provider / Geheimdienst / Whatever betreibt.
Und wie gesagt, dann muss man selbst schon irgendwie mit seinem Surfverhalten (ohne Freifunk) irgendwie ins Fadenkreuz einer Ermittlung geraten sein. Solche Pakete analysiert man zumindest bei Providern nicht einfach so.
Die technischen Gegebenheiten kenne ich. Trotzdem wird in vielen Communitys damit geworben das zwischen Freifunk Knoten und dem Gateway/Supernode die Verbindung verschlüsselt ist. Es wird schwer zu erklären wieso der Verzicht auf Verschlüsselung auf einmal besser sein soll. Einerseits wird seit Snowden verlangt das so viel wie möglich verschlüsselt sein soll und gerade der Freifunk Düsseldorf macht die Rolle Rückwärts.
Der Vorteil vom FastD ist ja auch das ich das Gateway mit dem sich der Knoten verbindet authentifziere. Denn mal eben ein anderes Gateway hinzustellen funktioniert nur, wenn in meinem Knoten dessen Public Key hinterlegt ist. Über welches Gateway dann letztendlich nach BATMAN Metrik die Daten wirklich raus gehen ist erstmal unerheblich.
Bei den Knotenaufstellern haben wir mit dem VPN zwischen Knoten und Gateway durch den FastD ein gewisses Sicherheitsgefühl kommuniziert und aufgebaut. Dieses sollte man nicht leichtfertig für etwas mehr Performance opfern. Ein Angreifer der zwischen meinem Anschluss und dem Supernode und Gateway sitzt, sieht beim FastD VPN halt nur Datenmüll. Aus L2TP kann er jedoch mit weniger Aufwand Dinge abgreifen.
bei uns macht das durchaus sinn. wir betreiben extra DSL Ports nur fuer den Freifunk und gerade da ist durchsatz sehr wichtig. Erste Tests haben fast 50Mbit ergeben auf einen 3600er.
Der Vorteil vom FastD ist ja auch das ich das Gateway mit dem sich der Knoten verbindet authentifziere. Denn mal eben ein anderes Gateway hinzustellen funktioniert nur, wenn in meinem Knoten dessen Public Key hinterlegt ist. Über welches Gateway dann letztendlich nach BATMAN Metrik die Daten wirklich raus gehen ist erstmal unerheblich.
Nicht ganz, jeder kann mit einer VM auf das Fastd Netzwerk zugreifen und im Mesh die Mac-Adresse spoofen.
Nach dem Aufbau der Verbindung findet keinerlei Authentifizierung des Gateways statt. Solange also der Rest des Meshes offen ist, ist auch die authentifizierte Verbindung nicht viel wert.
Bei den Knotenaufstellern haben wir mit dem VPN zwischen Knoten und Gateway durch den FastD ein gewisses Sicherheitsgefühl kommuniziert und aufgebaut. Dieses sollte man nicht leichtfertig für etwas mehr Performance opfern. Ein Angreifer der zwischen meinem Anschluss und dem Supernode und Gateway sitzt, sieht beim FastD VPN halt nur Datenmüll. Aus L2TP kann er jedoch mit weniger Aufwand Dinge abgreifen.
Dieses Argument ist ziemlich gefährlich da man so ein falsches Sicherheitsgefühl vermittelt, lieber sollte man die Betreiber aufklären.
Falls ein Angreifer zwischen dir und dem Supernode sitzt dann bekommt er die selben Daten die er auch im Mesh via spoofing abfangen könnte. Was daran jetzt so viel gefährlicher ist musst du mir erst erklären
Klar lässt sich damit die Verbindung schaffen das ein gewisser Traffic über deine Freifunk Node lief, aber was dies einem Angreifer (Ich rede hier nicht von Vorratsdatenspeicherung oder ähnlichem) in dem Moment bringen soll ist mir schleierhaft. Zudem die Position der meisten Router auf der Karte ist, dadurch erübrigt sich dies auch.
Davon ab möchte ich dich bitten dieses Thema wo anders weiterzuführen Hier gehts darum die Version zu testen.
Also das Image was nachher rausfällt ist etwa genau so groß da man noch zusätzlich 3 kernel module braucht.
Der Load auf der Serverseite ist wesentlich geringer da der Server natürlich auch keine Context-Switches mehr benötigt.
Dies trifft auch uaf die Nodes zu, wo Fastd vorher je nach Modell bis zu 15% CPU durchgehend zieht, sind es mit L2TP maximal 1-2%.
Diese Werte sind natürlich immer relativ zur Anzahl der Nodes in der Domäne etc.
Jedoch lässt sich sagen dass das Netz nicht nur mehr Durchsatz hat sondern auch weniger CPU-Resourcen benötigt.
Außerdem lässt sich jeder VPN Link als eigenes Interface konfigurieren, so können wir auf beiden Seiten des Links Splithorizon aktivieren (No_rebroadcast bei Batman) da wir ja nicht mehr nur ein virtuell großes Interface haben worüber wir die Batman OGM’s quasi noch mal „zurück“ schicken müssen damit sie beim Rest der Nodes ankommen.
Dadurch sollten wir das Grundrauschen noch etwas reduzieren können sobald wir einen großteil mit L2TP versorgen.
Gibt’s schon ein HowTo für die serverseitige Konfiguration auf Seiten der Supernodes?
Weitere Frage:
Wie würde sich denn die Performance von IPsec verhalten, wenn man zwingend Verschlüsselung haben möchte?
Sollte ja auch im Kernelspace stattfinden und vll. wird sogar Hardware-Crypto verwendet, falls vorhanden.
#!/bin/bash
# {{ ansible_managed }}
INTERFACE="$3"
ip link set dev $INTERFACE up mtu {{ tunneldigger.mtu }}
/usr/sbin/batctl if add $INTERFACE
echo "enabled" > /sys/devices/virtual/net/$INTERFACE/batman_adv/no_rebroadcast
Die MTU die wir verwenden ist statisch, dafür haben wir die Path-MTU discovery abgeschaltet die der Tunnelbroker bietet. Leider kommt Batman wohl nicht damit klar wenn sich die MTU der Interfaces ändert wenn diese schon im bat0 Interface sitzen. Zwar gibt es einen session.mtu_changed hook aber leider müssten wir dafür das Interface aus bat0 entfernen und neu hinzufügen. Dann gehen jedes mal alle Pfade über das VPN verloren.
Wir nutzen hier 1312 als MTU: 1280 (Ipv6 Minimum) + 32 (Bat15 Overhead)
Hier das session.down script:
#!/bin/bash
# {{ ansible_managed }}
INTERFACE="$3"
/usr/sbin/batctl if del $INTERFACE
Was IPSec angeht:
Tunneldigger verwendet L2TPv3 Pseudowire welche per definition unmanaged sind. Daher wird IPsec hier wohl nicht nutzbar sein. Für Düsseldorf werden wir aber weiterhin zumindest eine Fastd-Instanz betreiben.
Habe die Installation entsprechen einmal druchgearbeitet.
Das Session up / down Script liegt nun bei mir im /srv/tunneldigger/session.up / session.down
Wenn ich die MTU statisch setzen möchte, einfach { tunneldigger.mtu } damit ersetzen oder?
To Last: Wie starte ich das teil überhaupt
