Hallo zusammen!
Also TOR funktioniert ja auch nach einem ähnlichen Prinzip, es wird ein verschlüsseltes VPN zum nächsten Node aufgebaut und innerhalb des verschlüsselten VPNs ein weiteres verschlüsseltes VPN usw. usf. und selbst mit nem lahmen veralteten Androidtablet kann man da halbwegs normal surfen, also warum sollte das nun plötzlich bei Freifunk mit weniger Knoten als bei TOR ein Problem sein?
Es geht bei Freifunk nach meinem Verständnis ja nicht um Highspeed-Breitband-Internet, sondern vorrangig um freien Netzzugang für alle, möglichst mit breiter Abdeckung zu erträglichem Tempo.
Bitte lasst Euch von den Chemnitzern zeigen, wie die das erfolgreich machen. Der Verein ist auch im Gegensatz zu den Vogtländern bei der RegTP offiziell registriert als Provider, also ist es wichtig, dass Vogtland Freifunk klar und deutlich als Untergruppe Auftritt, um in den Genuss dieses Privilegs zu kommen und dazu gehört meiner Meinung nach eine identische Hard-/Softwarekonfig.
Grüße, Kai
Am 09.05.2016 um 17:03 schrieb Simon Wunderlich sw@simonwunderlich.de:
Hi Carsten,
siehe inline:
On Monday 09 May 2016 16:55:45 Carsten Weber wrote: Hi,
technisch ist die Verschlüsselung und der Transport der Daten getrennte Dinge. Am VPN-Tunnel "kann" (ein technisches "kann", das heißt nicht, dass das getan werden sollte) auch eine NULL-Cipher bzw. ein NULL-Auth-Hash eingestellt werden. Dann werden die Daten unverschlüsselt übertragen, aber trotzdem in einem "VPN".
sicher, die Frage ist nich ob VPN-Tunnel, sondern ob Verschluesselung oder nicht. Auth machen wir sicher immer, die Frage ist ob wir Payload verschluesseln.
Soweit das Technische. Aaaaber bei dem Wunsch bekomme ich Kopfschmerzen :/ Ich meine, wir reißen uns ein Bein aus, damit überall jeder Mäusefurz verschlüsselt übertragen wird, damit die wichtigen Sachen in der schieren Masse untergehen, und dann reden wir davon, Verschlüsselung auszuschalten, weil das >möglicherweise< schneller ist?
Das Hauptproblem bei den meisten VPN-Technologien ist dass sie im Userspace laufen. D.h. das Datenschubsen zwischen Userspace und Kernel ist das was den Grossteil der Performance auffrisst. Verschluesselung schluckt auch nochmal einen Teil, ist aber eher das kleinere Problem. 5-10 MBit/s sollte bei der aktuellen Hardware aber in beiden Faellen moeglich sein.
Es gibt auch ein paar Technologien um Kernel-only Tunnel aufzubauen, z.B. mit L2TP, damit experimentieren auch einige Communities. Damit laeuft dann der Payload Transfer im Kernel ab. Verschluesselung dazu geht evtl. auch, ist moeglicherweise etwas komplizierte einzurichten. L2TP unterstuetzt nativ keine Verschluesselung, IPSEC kann man darunterlegen, aber spaetestens dann wirds haesslich zu konfigurieren. :)
Neee nee nee. Lass uns lieber Dinge optimieren, von denen wir wissen, dass sie ein Problem sind, anstatt an Stellen zu basteln, von denen wir das nicht wissen. Und ich gehe davon aus, wenn wir nachschauen, stellen wir fest, dass die Nanostation ihre 5 oder 10 MBit locker verschlüsselt bekommt. Oder hat schon mal jemand einen >belastbaren< Test gemacht, der zeigt, dass wir da tatsächlich in eine verschlüsslunsbedingte Grenze laufen? Baugleiche Nano2 stelle ich gern zur Verfügung.
Und die serverseitige Rechenleistung ist jedenfalls kein Argument, lieber steck ich da noch Hardware nach, als auf Verschlüsselung zu verzichten.
Sehe ich genauso. Das bottleneck ist eher der Router.
In jedem Fall wuerd ich aber, bevor wir uns weiter in die Details vertiefen, erstmal morgen schauen was die Chemnitzer benutzen und das aufsetzen, und anschliessend weiter optimieren.
Viele Gruesse, Simon