L2TP pro und contra


#1

Ich bin zwar noch ein kleines Licht, aber wenn ich mir die (vielleicht nicht dem reinen Freifunk-Gedanken entsprechenden) Geflüchtetenunterkünfte ansehe und dass (zumindest die “Zur Lindung” / FF-Düsseldorf-Flingern) man mit dem alten fastd eine stabile und leidliche schnelle Verbindung hinkriegt, so würde ich dieses auch nicht unbedingt in eine weniger stabile und dafür weniger Ressourcen brauchende Alternative tauschen.
Das mag bei “normalem” Freifunk anders sein. Aber in so intensivem Kontakt mit Kommunen und unter entsprechender Beobachtung ziehe ich eine stabil mit 25-30 MBit angebundene Unterkunft einer mit wackeligen 30-40 MBit angebundenen vor. Wenn man sich ansieht, wie intensiv das hier genutzt wird, würde ich mich eher als Provider sehen und auf Stabilität und Dokumentation statt auf “Learning by doing” setzen.
Und wenn es doch schon funktioniert (bei mir in RG-West klappt es gut - wenn auch seit Tagen nur mit einem Uplink-Node), was spricht dann gegen eine Dokumentation dessen, was man an Wegen erforscht hat?

Just my 2 ct.


[ffdus] l2tp Testbetrieb
L2TP serverseitig installieren
[ffdus] Gluon 2016.2.5 release (fastd/l2tp zur Auswahl)
[ffdus] Gluon 2016.2.5.2 stable (fastd/l2tp): clientroaming + 841v12
Mehrere Knoten im Haus (was: 3 FF-TP an Fritzbox)
VPN Bandbreiten-Limit ändern (Nachträglich Bandbreite erhöhen: Ubiquiti Nanostation M2. Wie?)
Nun funkt es auch an der Bergstraße
Site.conf mit aktuellster Technik für neue Domain
#2

Darf ich fragen wie du darauf kommst das es weniger Stabil sein soll?

Wir nutzen das jetzt 5 Monate und haben wesentlich weniger Probleme mit L2TP als mit fastd. Und können sogar im Notfall mit nur einem Server unser komplettes Netz mit 600 Clients/200 Nodes laufen lassen. Und das mit ner load von 0.5


#3

Gut, es erschien mir so. Bzw. es ist nicht weniger stabil, aber in der Einrichtung nicht ganz trivial. Wie gesagt, um das im Detail beurteilen zu können, fehlt mir der technische Duchblick. Nur Kommentare wie “Learning bei doing” sind halt bei Rädern, die die Menschheit offensichtlich schon erfunden hat, nicht unbedingt notwendig.
Nach kleinen Anlaufschwierigkeiten läuft in der Tat RG-West (L2TP) bei meiner Duisburger Site sehr stabil, mit nur einem Server.
Andererseits stelle ich mir diese Anlaufschwierigkeiten aus Anwendersicht bei Flüchtlingsunterkünften, bei denen wir verglichen werden mit kommerziellen Anbietern (die Freifunk nicht sein will, sich trotzdem diesem Vergleich stellen muss), nicht besonders gut vor. Immer im Hinblick darauf, dass es ja eine funktionierende, technisch vielleicht nicht optimale, Lösung gibt (“meine” Unterkunft hat heute bis 23:30 Uhr gemessen an der Fritzbox 182 GB gefressen, seit Installation ist der Uplink absolut stabil).

Aber es geht hier ja eher um Doku als um Stabilität.


#4

Wir haben hier im 3Ländereck auch noch Fastd am laufen, wurde in einer Vorstandssitzung so bestummen, da sonst die Sicherheit nicht gewährleistet werden kann. Ein VPN Tunnel sei halt noch immer besser als keiner.

Ich bin zwar kein Vorstandsmitglied, hab mich aber für L2TP eingesetzt. Nun hab ich halt ein Offloader im Einsatz und einige andere auch.


#5

Es gibt etwa 3-4,5 Argumente die gegen L2TP vorgebraucht werden.
Und je nach Befindlichkeit kann man davon eines oder mehrere bemühen. Entweder weil es der eigenen Überzeugung wirklich entspricht, oder weil man ein Argument vorschieben möchte.
(Das sei jetzt mal so völlig wertfrei formiliert von jemandem, der eben kein L2TP nutzt derzeit)

  1. Fastd ist in der Regel verschlüsselt, L2TP ist es in der Praxis nicht. Deep Packet Inspection, Potentiell Kenntnisnahme etc… (x mal durchgekaut in vorherigen Threads)
    1b) Community hat den Routeraufstellenden/Institutionen “verschlüsselte Tunnel” in Präsentationen/Flyern beworben und mag den Diskussionspunkt nicht wieder aufmachen (obwohl es “eigentlich” kein Problem sein sollte)
  2. L2TP bringt etwas wenn die Hosts von CPU am Ende sind, aber auf den LAN-Interfaces noch (etwas) Luft ist. Die rund 30% Zugwachs “über alles” (ethernet-Limit statt CPU-Limit) in der Praxis erscheint einigen aber nicht lohnenswert, selbst wenn es reichlich kWh spart
    2b) Bandbreitenbremse durch “lahme Router” erspart den Ausbau von Serverinfrastruktur. Wenn jeder 841er 50MBit/s und mehr könnte am UnityMedia200, dann müssten ziemlich schnell neue Server her, die bei >95% 841er mit FastD-Nadelöhr von 8-15MBit/s eben noch lange ausreichen
  3. Für FastD gibt es viel Dokumentation in unterschiedlichen Geschmacksrichtungen, für L2TP/Tunneldigger gibt es öffentlich nur ein Nicht-Freifunk RTD und spärlichst kommentierte Ainsible-Repositories.

Ich möchte die Diskussion in den Details nicht neu anstarten, da es sich wohl nur wiederholen würde.

Mich würde es aber freuen, wenn zumindest 3) (Doku) und 1) (rudimentäre Verschleierung per XOR) zu bekommen wäre für L2TP.
Dafür würde ich auch ggf. einen Getränkevorratsgutschein ausloben.


#6

(Manchmal bin ich auch wieder froh, Teil eines informell organisierten Haufens zu sein und nicht eines Jägergartenzaunfreifunkvereins.)

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?

Aber die Diskussion ist müßig; beide Seiten kennen die Fakten …


#7

Ich hab auch gesagt, es könne ja einfach jemand das Netz mitschneiden.
Ist ihnen aber wohl lieber als wenn der ISP gucken kann, was durch die Leitung geht.

Nun auch egal, ich hab meinen Offloader, der macht auch ganz schön Dampf.


#8

Offloader belasten das Netz z.b. überdurchschnittlich. Die hohe Bandbreite sorgt dafür das noch mehr Kontextswitches (Der Hauptgrund warum Fastd so langsam ist) vom Kernel des Supernodes verarbeitet werden müssen. Im Grund tauscht man dann Performance gegen geringere Kapazitäten auf den Supernodes.
Dazu kommt das L2TP auch die Nodes unheimlich entlastet, ein Bullet M kann mit L2TP gut 30-40 Clients bedienen, was mit Fastd nur möglich ist wenn das Mesh klein ist (Unter 100 Nodes).

Außerdem frisst so ein Offloader doch schon recht viel Strom (Im Falle des Futro) was ich bei den heutigen Stromkosten für unwirtschaftlich halte.

Die Sicherheit ist auch nicht geringer, die Provider wissen anhand der IP-Header von Fastd sowie L2TP Paketen das diese auf einen Server des FFRL enden. Es kann also schon erahnt werden was sich in den Paketen befindet ohne das der Provider wirklich noch tiefer in die Pakete schauen muss.

Davon mal abgesehen darf er auch nicht reinschauen. In diesem Falle könnte man ihn dann verklagen und würde sicherlich eine Lawine an Shitstorms gegen den Provider lostreten. :wink:


#9

Naja ich kanns nicht ändern. Ist ein entscheid des Vorstandes. Ich hab nur den Antrag gebracht und der wurde dann nach Prüfung abgelehnt. Der Vorstand wird schon richtig entscheiden, hoff ich zumindest.

Nun haben wir dafür halt ein funktionierendes Image für den Futro S550.

Bezüglich Stromkosten: Ach ich hab Geräte die 24/7 laufen und mehr Strom ziehen als der Futro. Wenn ich mir das nicht mehr Leisten mag, dann weiss ich auch nicht :wink:


#10

Naja ich kanns nicht ändern. Ist ein entscheid des Vorstandes. Ich hab nur den Antrag gebracht und der wurde dann nach Prüfung abgelehnt. Der Vorstand wird schon richtig entscheiden, hoff ich zumindest.

Hmm mit dieser Aussage müsste in der Politik auch alles mit rechten Dingen zugehen :wink:
Evtl könnt ihr ja L2TP parallel betreiben, das ist in Neuss z.b. auch der Fall. Die beiden Dienste stehen ja nicht in Konflikt und man kann dann verwenden was man möchte :wink:


#11

Ich denke wenn beides geht koennen die anwender entscheiden (router aufsteller)
Wir haben uns vor einen halben jahr fuer l2tp entschieden und sind sehr zufrieden!
Und mehr als 900 Router mit durchsatz zeigen das aus technischer sicht nix mehr fuer fastd oder openvpn spricht. Ginge gre mit dynamischen endpunkten waere das auch was :wink:


#12

Man sollte aber nicht vergessen, dass viele Firmen oder andere private Organisatoren das in ihren (eigentlich abgeschlossenen) Netzen auf ihrer geschlossenen Benutzergruppe, die dann irgendeinen Wisch unterschrieben hat, völlig legal machen können.

Wäre ja auch kein Problem. Aber beim Freifunk hat man ja öfters Leute, die ohne Sinn und Verstand nach dem Motto “FUCK THE POLICE” einfach in diesen Netzen trotzdem Freifunk betreiben, obwohl die Organisation sowas verbietet. Im besten Fall wird dann die DPI einfach genutzt, die unzulässige Verwendung für Freifunk zu identifizieren und abzustellen. Im schlimmsten Fall läuft der Freifunk unbemerkt vor sich hin und es wird fleißig mitgelesen und mitgeloggt.

Da macht der Einsatz von Verschlüsselung natürlich Sinn um zu verhindern, die Freifunk-Benutzer an diesem Zugangspunkt der ungewollten DPI auszusetzen.

Wenn man unverschlüsselte Protokolle einsetzt sollte man also überlegen, definitiv die potentiellen Knotenbetreiber über diese Gefahr aufzuklären. Da L2TP ein doch recht weit verbreitetes Standardprotokoll ist besteht da auch noch mehr die Gefahr dass irgendeine DPI-Appliance von der Stange damit out-of-the-box klar kommt.

Wer L2TP einsetzt sollte also wohl überlegen, die potentiellen Knotenbetreiber aufzuklären, dass Freifunk nur an Anschlüssen eine Internetverbindung aufbauen sollte, an denen DPI oder ähnliche Gotchas ausgeschlossen sind,

Die Gefahr ist nicht rein hypothetisch, die Situation haben wir bei uns an der Hochschule. Freifunk ist (wie eigentlich jedes privates WLAN-Netz) von Seiten der Uni verboten, aber einige machen das natürlich trotzdem im Hochschulnetz. Daher wird es bei uns auch zumindest in naher Zukunft eher kein (unverschlüsseltes) L2TP geben.


#13

Man sollte - bis auf die Tatsache, dass L2TP vielleicht bei einem Standard-Check prüft wird - nicht vergessen, dass man natürlich den fastd-Traffic erkennen kann und natürlich schnell anhand der Ziel-IP auch Freifunk erkennt. Man muss halt nur aktiv suchen, wobei vielleicht die Menge an UDP schon auffällt.


#14

Mir ging es nicht darum, dass Freifunk erkannt wird.

Sondern dass tatsächlich automatisiert der getunnelte Datenverkehr ausgewertet wird und in irgendwelchen Logfiles landet. Das ist in dem von mir genannten Szenario (also Firmen, Unis) nämlich ein realistisches Szenario und auch legal, zumindest solange nicht auffällt, dass Freifunk im Spiel ist und daher außenstehende Dritte beteiligt sind.


#15

Ok. Dachte, es ginge um die Erkennung von Freifunk und dass dieser nicht erlaubt sei.


#16

Lass die doch loggen was sie wollen.

Wer in einer Verbindung quer durch’s Internet und dann auch noch über ein offenes WLAN keine Verschlüsselung nutzt ist ohnehin nicht mehr zu retten - da ändert auch ein verschlüsselter fastd, statt offener l2tp Tunnel, nichts mehr dran.


#17

Ich verstehe nicht wo der unterschied ist, ob ich per DPI mitlogge oder viel einfacher direkt im Freifunk WLAN?
Wenn Freifunk in diesem Netzwerk nicht erwünscht ist, warum dann aufstellen?

kopfschüttel


#18

Der Unterschied ist, dass das Logging per DPI in gewissen Szenarien mit hoher Wahrscheinlichkeit auch wirklich dauerhaft erfolgt. Beim Sniffen im WLAN passiert das nur wenn jemand in der Nähe der Meshknoten zwischen dir und dem VPN-Uplink Langeweile hat, und auch vor Ort bleibt.

Das ist einfaches Threat-Modelling. Einfach immer direkt die Arme strecken und sagen “Ich kann eh nichts garantieren”, und einfach alles offen zu lassen, egal ob man da was machen könnte oder nicht, ist zwar einfach und angenehm, bringt es aber nicht wirklich.

Genau meine Rede. Dies ist ein Problem das man am besten auf sozialer Ebene löst.

Ich wünsche mir ja nur, dass man genau das auch irgendwo mal fest hält um ein Problembewusstsein zu schaffen. Denn die Aussage “Das Reinschauen in Datenverkehr ist verboten” halte ich für sachlich falsch. Das ist wirklich nur gegeben, wenn der Uplink-Provider auch eben genau das ist: Ein Provider.
(Cyrusfox hat das ja auch exakt so gesagt. Nur kann man dieses Detail schonmal schnell überlesen)

Bitte auch beachten, dass ich explizit nicht sage, dass die Nachteile von L2TP die Vorteile überwiegen oder so, diese Aussage muss man nach lokalen Gegebenheiten selber treffen. Bei uns lokal halte ich es aufgrund der Hochschule und der offen dokumentierten DPI aber z.B. eben sehr wohl für gegeben, und ich kann mir gut vorstellen, dass es anderswo ähnlich ist. Daher darf man die Nachteile aber auch nicht einfach kleinreden, weil sonst manche Communitys auf falschen Grundlagen suboptimale Entscheidungen treffen könnten.
(Und der Thread heißt ja “pro und contra” :slight_smile: )


#19

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.


#20

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ß.