L2TP pro und contra

Weil es Leute gibt, die gern Freifunk überall ermöglichen möchten und dabei durchaus auch Risiken in Kauf nehmen.
Das muss Dir nicht gefallen. Könnte aber ein Ansatzpunkt sein, warum bestimmte Dinge getan werden und andere nicht.

3 „Gefällt mir“

Fragt sich nur, ob dieses, nicht zwingend im Einklang mit den Zielen von Freifunk stehende, Verhalten so schutzbedürftig ist, daß andere massiv darunter leiden müssen (schlechterer Durchsatz, höherer Energieverbrauch, höhere Gesamtkosten durch lokale Offloader und mehr VMs, die die CPU-Leistung der Offloader kompensieren).

Natürlich kann ich mich per DNS-Tunnel durch einen öffentlichen Hotspot tunneln und drüber auf dem Marktplatz lecker Freifunk anbieten. Kommt das allerdings raus, fällt das direkt auf meine Community zurück, erst viel später, und nur vielleicht, auf mich.
Ich würde einem solchen Tun nicht noch Vorschub geben wollen durch zweckfreie Verschlüsselung unverschlüsselten Datenverkehrs.

Aber auch das ist etwas, was jede Community für sich und intern entscheiden muß.

Naja, wir tun im Freifunk viele Dinge, die eigentlich auch eher auf einer FOSS-Agenda, oder einer OpenData-Agenda, oder in einem orangefarbenen Parteiprogramm stehen. Zumindest kann ich mich davon nicht freisprechen.

Nichtsdestotrotz ist einer meiner Lieblingssätze „Freifunk ist kein AnonVPN für Arme“, nur der zweite danach lautet auch "Freifunk schützt primär die Nodeaufstellenden, nicht die Nodebenutzenden"_
Aber es schließt sich nicht aus.

Will sagen: Man kann das eine tun ohne das andere zu lassen.
Wenn man als Community sowohl einen Firmware mit L2TP als auch eine mit fastd anbietet, dann haben die Aufstellenden die Wahl. Gibt Leute, die das mit der „informed choice“ für eine Chimäre halten. Aber man kann es ja versuchen.
Und je nach „Geschmacksrichtung“ bietet man das eine dann eben prominenter an als das andere. Oder umgekehrt. Oder versteckt das eine sogar ein klein wenig.

(Und dass mir niemand mit dem Argument „Arbeitsaufwand“ kommt. Den FW-Bau hat man doch hoffentlich sowieso automatisiert. Und die Installation des Tunneldiggers war zumindest mit der seit dieser Woche vorliegenden Doku einfacher als der Batman-Teil, wo nach wie vor trotz Selbstkompilat nach wie vor batman-versionen und batctl nicht so recht zueinander „passen“ wollen. Will sagen: Da gibt es Baustellen, die blöder sind. )

3 „Gefällt mir“

bedenkte jedoch das die M2 lediglich 400 MHz hat und von dem her nicht viel Durchsatz liefern wird.
Es wäre evtl. empfehlenswert hier ein Offloader und wenn es nur ein WR841 v10 (12-15 MBit/s) oder WR1043 v2/v3 (17-20 MBit/s) ist.
Ich glaube die M2 schaft nur so ~ 6-8 MBit/s, wobei die Geschwindigkeiten stark von Größe des Netzwerkes, eingestellte MTU von fastd usw. abhängt, kann also variiren.

Offloader werden nicht benötigt da wir in Düsseldorf kein Fastd sondern L2TP/Tunneldigger verwenden.
Die Geräte schaffen via L2TP in der Regel die Bandbreite die sie auch mit einem Offloader schaffen.

Laut Monitoring bekommt das Gerät zwischenzeitig bis zu 40 Mbit hin wobei dieser Wert bei fehlenden Datenpunkten zu hoch erscheinen kann, daher würde ich vorschlagen evtl ein weiteres Gerät aufzustellen und mit eigenem Uplink auszustatten.

a) Wir wissen nciht, wo das Limit vorher lag. Die Frage des TS bezog sich klar auf „Wie Bandbreitengrenze erhöhen/aufheben, die bei der Installation im Config-Mode gewählt wurde“

b) Auch eine Nanostation M liefert im VPN-Betrieb ausreichende Werte.
Auch mit 400MHz.

Du irrst im Glauben

Hier wäre definitiv kein Offloader sinnvoll.
Sofern keine Raumheizung benötigt wird.

2 „Gefällt mir“

Dazu kommt das per Default keine Limits aktiviert sind, sofern also beim Aufstellen keines gewählt wurde sollte die maximale Bandbreite die das Gerät schafft zur Verfügung stehen (Genügend Bandbreite beim Internetanschluss vorrausgesetzt).

Edit:
Hier ein Beispiel was ein 841v8 via L2TP schaffen kann:

https://forum.freifunk.net/uploads/default/original/2X/6/642a2e334d3e483ed0cdec225c6ddc5fc10ff3d5.png

1 „Gefällt mir“

o_O was kommt da für n vpn zum einsatz?

(20 Zeichen…)

was für crypto macht das dann?

Ich verstehe ja durchaus, auf welches Thema Du heraus möchtest.
Daher einfach mal hier im allgemeinen L2TP-Thread weiter.

Kein Crypto. Zumindest nicht auf Routern, die nur 4MB Flash haben.
Denn dort passt kein IPSEC hinein. (Nach derzeitigem Stand, auch nicht mit „XOR-crypto“)

ja, wir haben fastd mit crypto, weil sicherheit einfach vorgeht

Hier mal mein Speedtest mit einem Futro S550 als Offloader:

Das ganze noch über WLAN (WR841N):

Bin beim Freifunk-3Ländereck mit Fastd

So lässt es sich anständig surfen :wink:

welche Sicherheit ?

Vor allem welche Sicherheit bringt den Fastd ----> keine.

Jeder Otto-Normalo denkt ach das wird ja noch mal extra verschlüsselt da brauch ich das ja nicht …

Das einzigste was Sicherheit bedeutet ist ende zu ende Verschlüsselung.

Als ‚VPN‘ geht so ziemlich alles durch, was irgendeine Tunnelfunktion realisiert. MPLS zum Beispiel. Verschlüsselung würde das Außenministerium für den standortübergreifenden Verkehr voraussetzen; wir aber reden über Datenverkehr, der unverschlüsselt per Funk übertragen wird — nachträgliche Verschlüsselung ist damit mehr als flüssig. Im Grunde könnte man IPSec machen; aber wenn sich wer nackt im frei empfangbaren Fernsehen zeigt, welchen Schutz der Privatsphäre bringt dann die parallele Ausstrahlung im Pay-TV?

finde ich trifft es ganz gut

oder mal bildlich:

Das ist fastd:

du als Zugführer möchtest nicht das jemand mitbekommt wann du irgendwo bist / oder ob du überhaupt unterwegs warst.

Prima solange du im fastd tunnel fährst passt das auch / aber auf dem Weg zum tunnel (client → router) und aus dem tunnel (gateway what ever) zum Webserver sind die Daten nackig :wink:

was bringt der Fast Tunnel GAR NICHTS.

Das Einzige was beim Spanner auf der Straße was bringt ist eine U-Bahn :wink:

4 „Gefällt mir“

Leitet ihr direkt aus über Hetzner?

Scheinbar ja. Frag mich aber nicht wieso. Hab keine Ahnung wieso.

@danielkrah . es wird dir nicht gefallen, aber fastd crypto (oder welche auch immer) bringt etwas : das scheint unversöhnlich zu sein und läuft am Ende auf Design Entscheidung hinaus.

Vorteile von Performance und keine Sicherheit auf der einen (deinen) Seite

Die Sicherheit das Access Provider, und lokale Internetbereitsteller/Träger nicht mehr Traffic mitschneiden können auf der anderen Seite. Es ist eben etwas ganz anderes ob du einen Rootserver und dahinterliegendes „Internet“ aufmachen musst, oder bequem lokal alles bekommst. Insofern ist die Rechts/Instittionslage in Deutschland eben auch wichtig … wo TelekomAccessProvider eben zu Speicherung und DPI Schnittstellen verdonnert werden (können sollen). Daher ist das ein massiver L2TP Nachteil auf kosten von Performance.
Der Teil das man auch vor Ort sein könnte und direkt mitschneiden - ist technisch korrekt , im großen Stil aber Weltfremd.

Arbeit an IPsec für „größere Router“ wäre angesagt.

Zumal einige Anbieter für 2017 DPI zum Revival ausrufen möchten. Irgendwas mit Terror vermutlich (und unterstellt „Verbesserung der Kundenbindung beim MSO“…)

Ich habe da noch Verständnisprobleme:
Das Beispiel mit der Uni leuchtet mir ein - sehe ich aber ehrlich gesagt gar nicht so eng, da sehr speziell.
Aber auf lokaler Ebene ist es doch auch mit fastd überhaupt kein Problem, den Datenverkehr mitzuloggen.
Ich muss mich nur ins Freifunknetz einklinken und krieg sämtlichen Datenverkehr präsentiert.

Der Unterschied zu L2TP besteht eigentlich ja nur darin, dass das Mitschneiden auf einer Schnittstelle erschwert wird.
Das ist für mich persönlich so, als würde ich am Auto die Türen abschließen, aber die Fenster offen lassen.

Meiner Meinung nach hält sich der Mehrwert von Fastd hier sehr in Grenzen. Ein verschlüsselter Tunnel schützt eben nur einen sehr eingeschränkten Teilbereich.

3 „Gefällt mir“

Wir können uns nur auf aktuelles Recht beziehen, ob in ein oder zwei Jahren DPI bei den Providern genutzt wird ist spekulativ und bringt uns in diesem Thread nicht weiter.
Nach momentanen Recht gibt es keinen Grund den Tunnel zu verschlüsseln, zumal man das Problem dann immer noch angehen kann indem man z.b. wie @adorfer schreibt eine ordentliche Kernel-Space Implementierung entwickelt.
Das Thema driftet meiner Meinung nach zu sehr zu einer Grundsatzdiskussion ab welche mit einer Faktensammlung „Pro und Contra“ nichts mehr zu tun hat.