Hier nun ein ganz frischer Speedtest eines TP-Link 841v8 mit der Firmware „Auffangnetz Ruhrgebiet“, also der neuen l2tp Subdomäne, die das alte Hauptnetz ersetzt hat:
@duese war so nett diesen bei sich anzufertigen, nachdem er mal aus Spaß zum Testen einen alten 841er in das neue Hauptnetz geflasht hat.
Wie man eindrucksvoll erkennen kann sind auch die alten Schinken der ehemaligen 15 Euro Klasse durchaus brauchbar und gehören absolut noch nicht ins Regal - auch wenn sie niemand mehr leiden mag…
Genutzter Access Provider, wer hätte es gedacht, natürlich mal wieder Unitymedia, diesmal an einer 150/10er Leitung.
@DL3DCF Die VPN-Verschlüsselung ist bei Freifunk sowieso nur Fasade
Mit einem 741nd v4 habe ich in Düsseldorf etwa 25 mbit hinbekommen, wir stellen jetzt bald auch auf L2TP um und werden Fastd nur noch mit maximal 30-40 Clients bedienen.
60 MBit/s schön und gut. Aber wann braucht man so eine Bandbreite schon mal?
Ja, Flüchtlingsunterkünfte und Großveranstaltungen sind hier mal die Ausnahme.
Auf der anderen Seite sehe ich hier das erhöhte Traffic aufkommen, das dadurch entstehen kann und wird.
Dieses erzeugt im Anschluss nur ein Bottleneck auf Serverseite, wodurch erhöhte Kosten entstehen.
Bleibt nur das Marketingproblem „Verschlüsselter VPN Tunnel“
Zum Thema Vorratsdatenspeicherung besteht wohl erstmal kein Unterschied zum Cryptotunnel.
Das ist so nicht richtig, L2TP belastet die Supernodes wesentlich weniger. Alleine das der unsinnige Userspace overhead entfällt ist ein großes Plus.
Dazu kommt das die Latenz geringer ist, dies ist auch ein Qualitätsmerkmal einer Verbindung.
Außerdem handelt es sich gerade bei Bandbreiten immer um eine Mischkalkulation, das Telefonnetz wird z.b. auch auch nicht auf den Extremfall Neujahr geplant sondern für durchschnittliche Benutzung.
Fastd benötigt in den Fällen wo viel Bandbreite benötigt wird einen Offloader und belastet in diesem Fall die Supernode CPU so sehr das die durchschnittliche Bandbreite ebenfalls sinkt.
Fastd ist einfach unpassend für unser Konzept, Userspace VPN Daemons sind immer schlechter als Kernelspace Implementierungen und sollten gerade bei Embedded-Devices vermieden werden.
So ist es. Ich empfinde es auch als kritisch durch die „Verschlüsselung“, die maximal innerhalb der Kette kurzzeitig stattfindet, fortlaufend ein falsches Sicherheitsgefühl bei den Usern zu wecken - offenes Wlan und keine Verschlüsselung ab dem fastd Server sind die Realität, auf die viel zu wenig eingegangen wird.
Natürlich braucht man es nicht. Der interessante Punkt dabei ist eher die Tatsache, dass die Supernodes dadurch im Leerlauf sind und man keinen „Offloader“ mehr braucht, um Durchsatz zu machen. Das Wiederbeleben totgesagter Plasterouter, die plötzlich wieder genug Durchsatz schaffen, ist ein angenehmer Nebeneffekt.
Das ist zwar richtig aber auch dafür könnte man eine Software Lösung finden. Das Problem tritt ja nur auf weil FastD im Userspace läuft und L2TP im Kernel Space. Wenn L2TP im Userspace laufen würde, hättest die gleichen Probleme (- crypto) natürlich.
Das ist aktuell in einigen Subdomänen, die aufgrund der batman Probleme nur mit einer vCPU unterwegs sind, ein echtes Problem. Die CPU Zeit ist nur wegen der Switcherei hoffnungslos überbucht.
Wenn Fastd im Kernelspace läuft ja, jedes Userspace Program ist langsamer als Kernelspace. Prinzipbedingt
Warum Fastd verwenden wenn es performanter geht? Die Crypto ist völlig nebensächlich da die Nutzdaten frei über den Rest des Meshes sniffbar sind
Du hast recht Diskussion ghet auch per Chat, aber eine Kleinigkeit: Nein man muss nicht vor ort sein, ich kann jeden Meshpartner + Client im FF Netz ausspähen, von überall
Das kommt halt auf die Art des ausspähens an. Traffic mitlesen kannste defakto nur wenn er auch an dir vorbeifließt.
Aber wie du schon sagtest. Es gibt bessere Möglichkeiten darüber zu disktutieren.
Die Netzwerkkarten der Maschinen der Supernodes waren in der Vergangenheit der Flaschenhals und damit wird sich mit L2TP nichts ändern. Nur dass die CPUs dann beim Warten etwas weniger Strom vergeuden.
Das Ruhrgebiet ist wohl in -wie man es jetzt sieht- glücklichen Lage, nie die die Aachener Templates geforkt zu haben.
Denn wenn man da einmal die dort allenthalben „verschlüsselten VPN-Tunnel“ seinen Knotenaufstellenden versprochen hat, dann kann man zumindest nicht mehr oder minder stillschweigend per Autoupdate davon wieder weg ohne sich mit dem Vorwurf der Wortbrüchigkeit konfrontiert zu sehen.
Das sehen wir in der Regel auch eher als Augenwischerei an, da hierdurch, wie oben bereits beschrieben, ein falsches Sicherheitsgefühl geweckt wird. Der Transporttunnel ist für die gesamte Verbindung genau so sicher oder eben auch nicht, wie der bis zum fastd Server verschlüsselte Tunnel, der im fastd im Einsatz ist.
Es sei denn in Aachen ist das WLAN verschlüsselt und man hat eine Methode entwickelt um jeder Session eine Ende-zu-Ende Verschlüsselung aufzuzwingen. Ne, aber mal im Ernst, es ist nicht hilfreich mit Verschlüsselung zu werben, während dies nicht auf die gesamte Verbindung zutreffen kann, da viele nicht in der Lage sind die beworbene Verschlüsselung als Maßnahme ausschließlich gegen den Access Provider zu erkennen. „Man“ ließt dann nur Verschlüsselung - mehr bleibt nicht hängen…
Die Perspektive stimmt nicht.
Den „verschlüsstelten VPN-Tunnel“ hat man nicht den AP-Clients („Usern“) versprochen, sondern den Knotenaufstellenden.
Und für die kann(!) es wichtig sein, dass diejenigen, die ihnen Internet-Zugang („Uplink“) spenden prinzipiell keine Möglichkeit haben, in den Traffic Einblick zu nehmen und allein deswegen sicher sein können, dass Freifunk der Provider ist. (Das lässt sich zwar auch anders herleiten, mit dem „verschlüsselten Tunnel“ ist es deutlich einfacher. Und daher wurde dieser Weg in der Vergangenheit gern gewählt, um von Städten, Kommunen und anderen Einrichtungen „Internet-Spende“ zu bekommen für aufgestellt Router)
Ne, aber mal im Ernst, es ist nicht hilfreich mit Verschlüsselung zu werben, während dies nicht auf die gesamte Verbindung zutreffen kann, da viele nicht in der Lage sind die beworbene Verschlüsselung als Maßnahme ausschließlich gegen den Access Provider zu erkennen. „Man“ ließt dann nur Verschlüsselung - mehr bleibt nicht hängen…