L2TP ist ohne verschlüsselung
Als reiner Transporttunnel
@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.
Gruß
Thomas
2 „Gefällt mir“
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.
1 „Gefällt mir“
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
Jawohl der ständige Wechsel von Userspace nach Kernelspace ist tatsächlich das entscheidende Kriterium.
Von dem Batman Problem mal ganz abgesehen 
Aber ich bitte euch. Das soll doch jetzt hier keine Diskussion werden, wer den der größte ist oder?
Beides hat so seine vorteile.
Ich für meinen Teil werde nach der Migration nach Berlin mal schauen was geht. Aber noch eine parallele Baustelle aufzumachen finde ich verkehrt!
Aber dann musste halt Vorort sein. Wie auch immer ich will hier keine solche Diskussion führen.
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)
3 „Gefällt mir“
Den Transporttunnel muss man ebenfalls manipulieren um an die Daten zu kommen, spart sich lediglich die rechenintensive Entschlüsselung. Ob es dann legaler ist den Transporttunnel zu „hacken“, weil das unaufwändiger ist, das will ich nicht beurteilen - technisch gesehen ist es ein Tunnel, der identisch dafür sorgt, dass die Pakete nicht im entsprechenden Netz rumspuken.
Nachtrag:
Im Falle des fastd ist es im Übrigen so, dass die Verschlüsselung optional zu- und abschaltbar ist. Wenn auf der entsprechenden Supernode die jeweilige Verschlüsselungsmethode nicht mehr angeboten wird, dann sind auch die fastd Tunnel reine Transporttunnel - nur nicht so schnell wegen des fortlaufenden Switching der CPU. Nur mal so btw.
wir sollten alleine schon aus umweltschutz aspekten l2tp nutzen … wo kommt denn der Strom her … (AUF BEIDEN SEITEN)
3 „Gefällt mir“
Hm, war das wirklich so? Bei uns waren eher die CPUs der Gateways und Superknoten der Engpass, nicht die Netzwerkkarten. Fastd rödelte am Anschlag > 75% (echte 100% gehen nicht) und bremste, während der Durchsatz oft nicht über ~60 Mbit/s liegt.
@CHRlS: Mal so Interesse halber, hast du das Per Kabel am 841er oder per Funk gemessen?
Wie @CHRlS geschrieben hatte, war der Test von mir. Ja der Test war mit einem Client per Kabel. Per WLAN wäre ja auch ein wenig durch die Luft verschluckt worden.
1 „Gefällt mir“