Für schlechte Anschlüsse (im Sinne von „Packet-Loss“) ist Fastd besser als L2TP, da ersteres damit besser zurecht kommt.
1 „Gefällt mir“
Habe bewusst von schmalbandigen Internetanschluessen gesprochen. Ich habe einen Knoten in Duisburg in der RG-West stehen, der ueber eine 8 MBit Leitung im Netz ist, und habe da ca. ~ 20- 30% mehr Durchsatz bekommen, als dort auf L2TP umgetellt worden ist.
Spannend, das war mir nicht bekannt, dann sollten wir das für Eifel & Co vielleicht auch anbieten.
Stimmt, an ein breiteren Internetanschluss wäre die Steigerung natürlich deutlich größer gewesen.
Der Flashenhals lag bei den CPU-mäßig überbuchten RRL-VMs (die ESXI-Hosts) bei ca 1 bis 2 MBit/s pro VPN-Tunnel.
Mit Umstellung auf L2TP war dann die Netzwerkbandbreite der Hosts der Flaschenhals.
Von daher: Wenn man als Community Supernodes hat, die CPU-technsich „underpowered“ sind, dann ist ein Wechsel zu L2TP ratsam.
Davon abgesehen, dass unverschlüsseltes VPN sowieso keine gute Idee ist… Den Nutzern wurde gesagt, dass der VPN-Tunnel verschlüsselt ist. Man kann daher nicht einfach auf ein unverschlüsseltes Protokoll wechseln. Ich hatte angefangen eine Layer 2-Version von WireGuard zu schreiben. Das macht mit einem WR841 40 MBit/s verschlüsselt. Mit einer Fritz!Box 4040 sind es fast 400 MBit/s. GitHub - CodeFetch/TunnelBridge: Encrypted layer 2 VPN kernel module
Da ich dafür eigentlich keine Zeit habe, da ich jetzt selbstständig bin, warte ich auf finanzielle Unterstützung durch die Niedersachsenförderung.
2 „Gefällt mir“
Hm, ich kann mich nicht daran erinnern, dass wir jemals eine Zusage gemacht haben, ein verschlüsseltes VPN anzubieten. Wenn ja, dann halte ich diese Zusage für überholt.
Man kann Internet über das Freifunknetz teilen
Nun kann man an einer Stelle das Netzwerk an eine Internetverbindung anschließen und es so den Nachbarknoten zur Verfügung stellen. Um die Aufsteller der Knoten, die ihren Internetzugang teilen, vor der Störerhaftung zu schützen, bündeln wir den Internetverkehr und schicken ihn verschlüsselt über die Server des Freifunk Rheinland e.V. ins Internet.
Naja, das ist eigentlich technisch auch nicht ganz richtig.
@jbacksch Freifunk hat eine Vorbildfunktion. Wenn wir das nicht hätten, würde keiner der involvierten Softwareentwickler, die ich kenne, das unterstützen und dann gäbe es Freifunk garnicht. Während es den Knotenaufstellern nur darum geht, überall freies WLAN zu haben, möchten die Softwareentwickler ein zukunftsweisendes, zensurresistentes Konzept realisieren. Auch wenn der Großteil des Internettraffics heutzutage Ende-zu-Ende-verschlüsselt ist, kann und wird eine Freifunk-Supernode abgehört und die Nutzer getrackt. Das ist umso leichter, wenn die VPNs unverschlüsselt sind. Eigentlich ist L2TP überhaupt kein VPN, sondern ein Tunnel. Dein Firmennetzwerk würdest du ja auch nicht über L2TP betreiben wollen. Und wenn wir mal gucken, was Big Brother so kann, dann können sie auch SSL-Zertifikate fälschen und den Inhalt abhören. Wenn Initiativen wie Freifunk nicht wären, dann würden wir jetzt schon in George Orwells 1984 leben und man müsste sich mit Personalausweis bei WLAN-Hotspots registrieren. Jeder Schritt den wir den Überwachern aus Bequemlichkeit entgegenkommen ist ein Schritt in die Digitaldiktatur.
1 „Gefällt mir“
Dann lies es nochmal. es wird nichts von den Knoten verschlüsselt nach dem Text.
Um die Aufsteller der Knoten, die ihren Internetzugang teilen, vor der Störerhaftung zu schützen, bündeln wir den Internetverkehr und schicken ihn verschlüsselt über die Server des Freifunk Rheinland e.V. ins Internet.
Die Daten gehen von den Knoten zu den Gateways und gehen von dort dann über verschlüsselte Tunnel zum Rheinland Backbone.
Von daher passt da alles:
Hm, ich kann mich nicht daran erinnern, dass wir jemals eine Zusage gemacht haben, ein verschlüsseltes VPN anzubieten. Wenn ja, dann halte ich diese Zusage für überholt.
Komm’ mal wieder runter von Deiner Palme und geh’ ins Kühlhaus — und lies’ mal wieder, wofür Freifunk steht:
Freie Netze werden von immer mehr Menschen in Eigenregie aufgebaut und gewartet. Jeder Teilnehmer im freifunk-Netz stellt seinen WLAN-Router für den Datentransfer der Allgemeinheit zur Verfügung. Das erweitert das Netz und eröffnet die Möglichkeit Daten, wie zum Beispiel Text, Musik und Filme über das freifunk-Netz zu übertragen oder über von Teilnehmern eingerichtete Dienste im Netz zu chatten, zu telefonieren und gemeinsam Onlinegames zu spielen. Dafür nutzen wir Mesh Netzwerke.
[…]
Unsere Vision ist die Demokratisierung der Kommunikationsmedien durch freie Netzwerke. Die praktische Umsetzung dieser Idee nehmen freifunk-Communities in der ganzen Welt in Angriff.
Da steht mal genau gar nichts von Verschlüsselung des unverschlüsselten WLAN-Datenverkehrs im Transport (der eh’ zwingend unverschlüsselt an die Upstream geschickt wird). Vielleicht ist ja auch Deine Aluhut-Mentialtät mitursächlich für Vergangenes?
Ja, ein verschlüsselter Tunnel Knoten<>Gateway würde DPI vorbeugen; aber wenn das den Knotenaufstellern nicht versprochen wurde, warum daran so krampfhaft festhalten?
2 „Gefällt mir“
Wer hier meint, dass ich nicht lesen könne und wieder zur Schule gehen solle, obwohl er meinen Kommentar anscheinend nicht versteht, der braucht sich nicht wundern, wenn ich sauer werde. Es wurde den Leuten in Essen immer mitgeteilt, dass der Verkehr verschlüsselt werden würde.
Der Text hier:
sollte genau das ausdrücken, aber er war unglücklich formuliert. Denn wenn man ihn wörtlich nimmt, nimmt man an, dass der Traffic nachdem er auf den Supernodes gebündelt wurde, verschlüsselt ans Rheinland Backbone gesendet wird. Davon abgesehen, dass der Verkehr unverschlüsselt von den Supernodes zum Backbone übertragen wird, war die Formulierung nicht falsch, als sie geschrieben wurde. Die Supernodes wurden früher nämlich vom Freifunk Rheinland betrieben. Der Text sollte ausdrücken:
„Um die Aufsteller der Knoten, die ihren Internetzugang teilen, vor der Störerhaftung zu schützen, bündeln und verschlüsseln wir den Internetverkehr und schicken ihn über die Server des Freifunk Rheinland e.V. ins Internet.“
Ob die Formulierung jetzt gelungen oder nicht war, ist egal. Die Leute, die sich einen Freifunkknoten in Essen aufgestellt haben, nehmen an, dass der Traffic in irgendeiner Weise verschlüsselt wird, um den Ursprungsknoten zu schützen.
Ganz sicher nicht. Davon abgesehen, dass ich von Leuten, die IT-Sicherheitsleute als Aluhüte bezeichnen, auch nicht viel halte.
Edit: Ich finde es übrigens nicht nett, dass du einen Beitrag, den ich geschrieben habe, weil ich sauer war und 5 Minuten später zurückgezogen habe, zitierst.
1 „Gefällt mir“
der Thread geht um Essen.
Manche Communities, so Essen und z.b. auch wir, haben die Verschlüsselung immer zugesagt.
2 „Gefällt mir“
Das ist ja einer der Diskussionspunkte; der auch derzeit noch auf der vom Freifunk Essen e. V. (der »Ortsgruppe des gemeinnützigen Freifunk Rheinland e.V.«) verantworteten Seite befindliche Text sagt genau nichts über eine Verschlüsselung zwischen Knoten und Gateway/»Superknoten« aus. »Um die Aufsteller der Knoten, die ihren Internetzugang teilen, vor der Störerhaftung zu schützen« reicht es rechtlich aus, daß der Traffic nicht über deren Internetzugang rausfließt, sondern, »NATs are good«, über $wenanders, also z. B. den Freifunk Rheinland e. V. Selbst wenn der transportierende Anbieter DPI machen würde: soweit ich weiß dürfte er es nicht und hätte mithin keine Handhabe gegen seinen Kunden.
Kurz und prägnant: ersichtlich verspricht Freifunk Essen gerade nicht, daß der Weg zwischen Knoten und der Freifunk-Essen-Infrastruktur »verschlüsselt« würde, Punkt. Somit fehlt es auch an Argumenten gegen L2TP.
Ob das anders gemeint war? Wenn dem so wäre, warum schrieb man man das nicht auch so, wie es angeblich gemeint war? Letztlich ist Freifunk Essen ja ein Verein, insofern könnte man ein Meinungsbild oder gar einen Beschluß herbeiführen …
1 „Gefällt mir“
Doofe Frage, was bring die Verschlüsselung?
Rechtlich gesehen?
Ohne richterlichen Beschluss darf eh niemand mithören, mit Beschluss muss der SN Betreiber eh Zugang schaffen.
Pauschal/Technisch ist der Knotenbetreiber ja „abgesichert“ vor 99% der anfallenden anfragen durch das ausleiten über einen „anderen“ Provider/Zugangsanbieter. Der restliche 1% ist nur unter engen Vorraussetzungen nicht „abgesichert“, bzw. Der Knotenbetreiber dann erstmal in der Pflicht nach seinen Möglichkeiten an der Identifizierung mit zu wirken.
Egal ob verschlüsselt oder nicht…
Es geht nicht um die rechtlichen Aspekte, sondern um die Möglichkeiten. Rechtlich gesehen, darf niemand hacken. Wieso sichert ihr also euren Computer ab? (Davon ab, dass der BND sehr wohl ohne richterlichen Beschluss abhören darf)
Rechtlich gesehen darf der BND keine deutschen Bürger abhören, praktisch macht er das aber im Weltraum und da „gilt bekanntlich kein deutsches Recht“. Siehe Weltraumtheorie.
Ja klar, rechtlich gesehen, darf der BND keine deutschen Bürger abhören, aber wenn er ja nicht weiß, dass es Deutsche sind, dann muss er ja erst einmal die Peering-Glasfasern abhören, um die Identität festzustellen.
Davon abgesehen kooperieren Geheimdienste mit ausländischen Geheimdiensten, um den in der Verfassung gewährten Schutz der Privatssphäre zu umgehen. Die Verfassung gilt ja z.B. für den BND nur in Deutschland. In Frankreich darf der BND abhören was er will. Dafür hören die Franzosen dann die deutschen Bürger ab und die beiden Geheimdienste tauschen ihre gewonnenen Erkenntnisse aus. So findet man Terroristen 
. Siehe Fourteen eyes.
Also eure tollen unverschlüsselten Knotenverbindungen werden schon mal von fast jedem westlichen Geheimdienst dieser Welt ausgewertet…
Und wer jetzt meint, dass sich doch niemand dafür interessiert, liegt falsch, denn heutzutage wird der Großteil von solch einem Internetverkehr nicht mehr von Menschen ausgewertet, sondern von fast komplett autonom arbeitenden Systemen wie Prism. Wenn z.B. ein Telefonat abgehört wird, wird das automatisch in Text übersetzt und dieser Text mittels soetwas wie dem Grammatical Framework in eine computerparsebare Sprache wie Lojban übersetzt. Diese Daten packt man in eine Datenbank und lässt einen komplexen Clustering-Algorithmus drüberlaufen und wenn der Inhalt des Gesprächs vorher aufgenommenen Telefonaten von Terroristen o.Ä. ähnelt, dann geht da ein Alarm los und ein Mensch guckt sich den Inhalt an und wenn auch er die Meinung des Computers teilt, wird die Person komplett überwacht.
Und wenn ihr jetzt immer noch meint, dass das ja nicht so schlimm ist, weil ihr keine Terroristen seid, dann vergesst nicht, dass die Deutschen schon mal einen Hitler demokratisch gewählt haben und wie sehr der sich darüber freuen würde, wenn er eine Datenbank mit dem Browserverlauf seiner Bürger der letzten 10 Jahre und Mitschnitte ihrer Telefonate hat… Selbst wenn euer Internetverkehr Ende-zu-Ende-verschlüsselt ist, lassen sich die IPs nachvollziehen und zu welcher Webseite sie gehören. Ein NSA-Chef hat mal sinnbildlich gesagt, dass Metadaten mittlerweile wertvoller geworden sind, als eigentliche Gesprächsinhalte.
Wenn die Knotenverbindungen zu den Supernodes verschlüsselt sind, dann lässt sich immerhin nicht nachvollziehen, wo denn jetzt der Surfer sitzt. Dafür braucht man dann schon Echelon (Es gibt Echelon-Foliensatelliten so groß wie Fußballfelder mit denen man auch z.B. WLANs am Boden hören kann) und das ist zu teuer, um „normale“ Bürger abzuhören. Mit OWE (Opportunistic Wireless Encryption) ist auch das nicht mehr möglich. Unsere Schwachpunkte sind noch, dass die Routingprotokolle keine Sicherheitsmechanismen besitzen, um ein Orten durch aktive Maßnahmen zu verhindern, aber das kommt noch…
Also… Wieso wollt ihr euer Netzwerk komplett offen haben, sodass jeder mitlesen kann, wenn es auch anders geht? Nur weil es dann schneller ist? Mit WireGuard wird sowieso mehr Durchsatz durch die Knoten rauschen, als der Internetanschluss hergibt…
Es gibt meines Wissens nach keine Freifunk-Community, die IPv6 NATet. Ohne security extensions sieht man sogar deine MAC-Adresse in deiner globalen IPv6-Adresse. Und selbst mit security extensions lässt sich deine MAC-Adresse aus deiner link-local-IPv6-Adresse im Freifunknetz ableiten.
Interessantes derailing. Ich habe Interesse diese Diskussion in einem anderen Thread fortzusetzen, müsste aber erst mal zur Arbeit. Ich füge meine Gedanken dann später ein.
Ja, ich könnte hier auch nur die drei bis sieben vorangegangenen L2TP-Diskussionen verlinken.
Eigentlich ist zum Thema wirklich alles gesagt, nur noch nicht von jedeR/M.
Daher ist Derailing das einzig Interessante was hier noch bleibt.
Ich klinke mich an der Stelle aus der Diskussion um L2TP in Essen aus, aber hoffe, dass ihr zu einem sinvollen Ergebnis kommt. Freifunk Essen kann machen, was sie wollen.
Mir wäre eigentlich ganz lieb, wenn es aus einer dieser Diskussionen einen Spin-Off gäbe, der dazu führt dass entweder (z.B. als GSoC)
- jemand Wireguard um einen TAP-mode erweitert
- oder eine Methode baut, GretapOverWireguard als Package für Gluon + Doku zum Serverbau erweitert.
(Und ja, ich kenne den Einwand, dass man dann plötzlich auf dem Supernode auf der Bridge ganz viele Interfaces hat und jemand fürchtet, dass es da Limits gibt… Aber das ändert nichts daran, dass das eine oder andere für kleine L2-Domains und/oder Domains mit vielen Supernodes mit jeweils wenigen Dutzend Tunneln trotzdem sinnvoll wäre.)
Aber solang es kein „Wireguard für Batman-Gluon“ gibt, ist L2TP zumindest in den vielen Communities die favorisierte Lösung, die ohne gangbare (bezahlbare/akzeptierte!) Alternativen dasteht.
2 „Gefällt mir“
Ich habe angefangen einen TAP-Mode für WireGuard zu schreiben. Der funktioniert auch soweit, aber da sind noch ein paar kleine Bugs drin, was die Paketlängen angeht, das Netlink-Interface muss umgeschrieben werden und ein 3-way-handshake sollte implementiert werden, damit der Umstieg von fastd einfacher fällt, man keinen Broker braucht und Knoten keine Uhrzeit brauchen, um sich nach einem Reboot zu authentifizieren. GitHub - CodeFetch/TunnelBridge: Encrypted layer 2 VPN kernel module
In diesem Fall reicht auch ein einzelnes Interface aus, da mein Patch die MAC-Adressen trackt und den Peers ähnlich wie fastd zuordnet.
Einen GRETAP over WireGuard-Ansatz habe ich auch noch auf einem Rechner rumliegen. Da musste ich aber feststellen, dass der Overhead nicht zu unterschätzen ist, dass man das ip-full package braucht und dass der Broker, um die GRE-Verbindungen über das WireGuard aufzubauen nicht schön ist. Letztendlich ist der zusätzliche IP-Header durch GRETAP auch unnötig.
Ich hoffe, dass ich bald aus der Niedersachsenförderung Unterstützung für die Entwicklung kriege, damit ich das ordentlich in WireGuard einpflegen kann und das irgendwann nicht mehr selbst maintainen muss.
6 „Gefällt mir“