Lokale Wolken per L2TP anbinden

@netminion @CyrusFox @nomaster

Da auf diversen Ebenen schon dazu diskutieren wurde:

Es gibt ein Projekt, lokale Wolken per L2TP (auf OpenWRT?) anzubinden.

Bitte erläutert doch das Konzept.
Ich halte es für durchaus lohnenswert, den Fastd durch ein Protoekoll zu ersetzen, welches die MTU autonom aushandelt.

Was würde dann durch den l2tp gesprochen? batman? Oder wäre das gateway lokal?
Derzeit sind fastd-Supernodes einer Domain in der Regel „backend“ redundant untereinander vernetzt (z.B. per zweitem bat-interface). Müsste man diese bat-interfaces dann auch mehrfach durch den Tunnel ziehen?

Darüber hinaus haben wir den Bedarf, Wolken über mehrere Uplinks anzubinden.

Da die Perspektive, bei den Geflüchtetenunterkünften ist, systematisch Dach- und Fassadenzugang zu haben, möchte ich eine einwandfreie Meshfunktionalität (auch "außerhalb der jeweiligen Anlage, in die Nachbarschaft) gern nutzen.
Daher wäre es ungünstig, wenn die Freifunkenden dort „Spezial-Firmware“ bräuchten. (Wovon ich aber nicht ausgehe)
(Noch schlimmer wäre es, falls man mit so einer Installation Probleme mit dem PPA bekäme, weil eine Netzteilnahme nicht mit niedriger Barriere möglich wäre.

Natürlich ist auch OLSR nicht verkehrt in dieser Hinsicht. Wäre aber für mich ein Beispiel, wie man es nicht machen sollte, um einen niedrigschwelligen Netzzugang i"im Mesh" anzubieten.

3 Likes

Hallo @adorfer ,

bei uns sind zb. die Supernodes alle per L2TPv3 angebunden anstelle von FastD,
mit L2TPv3 unter Gluon basteln wir derzeit mit dem Tunneldigger. (Server&Client)

http://tunneldigger.readthedocs.org/

LG

1 Like

d.h. die fastd-server sind (im Stern?) per l2tp verbunden und per GRE dann mit dem Backbone?
Oder auch per l2tp am Backbone und gar nicht untereinander?

Sorry, mir fehlt wirklcih das Bild von der Architektur. Was L2TP ist das weiss ich ansatzweise.

Der Freifunk Rheinland Backbone bindet aktuell ausschließlich per GRE over IPv4 an!

Ist as so zu verstehen, dass das dann zukünftig auch per L2TP gemacht wird?
(Noch läuft meines Wissens keine solche Installation produktiv.)

Dazu gibt es keinen Beschluss.
Ist aber technisch natürlich vorstellbar.
Allerdings sehe ich da gerade keinen echten Vorteil, außer dass man damit etwas besser durch NAT käme.
Aber wer betreibt schon Supernodes hinter NAT? Für realistischer halte ich die Anbindung via GRE over IPv6!

VG
takt

1 Like

Ich glaube das es weitesgehend egal ist welche Tunneltechnologie in richtung Backbone benutzt wird.

Deine Frage bezog sich im Ursprung ja (so denke ich) auf die Anbindung von Nodes zum Supernode.
Hier wäre L2tp in form von Tunneldigger Script brauchbar.
Was man verliert ist allerdings die Verschlüsselung.
Vorteil wäre es läuft im Kernel und braucht entsprechend weniger System resourcen.

Ob man die Crypto braucht seit dahingestellt.
Ich persöhnlich benutzte aktuell schon FastD Tunnel ohne Crypto

Gruß
Thomas

Das weiss ich eben nicht.
Ich hatte es zumindest so verstanden, als ob lokale Wolken geplant sind auf eigenen Broadcast-Domains.
Nur halte ich das zumindest für schwer vorstellbar, da solche lokalen Supernodes ja irgndwie aus Redundanzgründen und für die L2-Erreichbarkeit über mehrere lokale Supernodes hinweg) trotzdem auch „oben herum“ nochmal gekoppelt werden sollten, man also dann mehrere Tunnel fährt auf einer Uplink-Strecke.

Oder kann man mit L2TP auch irgendwie Bonding/Link-Aggregation zu unterschiedlichen Endpunkten machen? Das wäre ja doch eher etwas, was der Batman leisten muss.

Aber wie eingangs beschrieben: Ich kenne nur die Vorschläge, aber nicht das komplette angedachte Szenario, daher frage ich eben genau hier nach, um es nicht zwischen Tür und Angel durchzusprechen.

Das was du eigentlich haben willst ist lokal auf dem Node eine L2 Wolke mit Batman und einen Uplink per L3 zum Supernode.

Dafür gibt es aktuell heute noch keine Lösung.

Möglich wäre hier „Bubble“. Aber dafür gibt es aktuell keine lauffähige Implementierung.
Wir werden sehen, was die Zeit bringt.

Gruß
Thomas

L2TP statt fastd zu nehmen (in dem heutigen üblichen Gluon-Setup) hätte den Vorteil einer dynamischen MTU.
obwohl… es wird bei mehreren Nodes auf einem Interface dann die MTU des kleinsten genommen. Also kann man gleich doch wieder 1280 einstellen. Oder habe ich die Automatik falsch verstanden?

So genau kann ich dir das leider nicht sagen.
Allerdings kannste kein L2TP Tunnel über dynamische IPs aufbauen.
Dafür brauchste dann z.B. den TunnelDigger

Aber mal erlich 1280 als MTU reicht auch vollkommen. :smiley:
Das ist zumindest das min. bei IPv6.

Ich habe in Troisdorf gerade die erste l2tp Testfirmware gebaut. Ich bin ziemlich begeistert.

Gleiche Grundlage wie in Ruhrgebiet (configs aus eurer Site geklaut)

Ich bekomme hier mit einem 1043v2 meine 50Mbit leitung voll.

1 Like

Habt ihr zum Thema LTP eine Anleitung was Gateway mäßig eingestellt werden muss? Eventuell einmal eine Beispiel conf?

In der siteconf müssen ja nur die tunneldigger adressen mit rein oder?

Grad ziemlich Neuland für mich :wink:

offloader waren gestern.

Ist nur das Problem mit dem Marketing. so von wegen crypto tunnel

Neuland ist das glaube ich für uns alle. such mal im forum die düsseldorfer haben da was gemacht.
Im Internet musste mal nach Tunneldigger suchen. Den L2TP ist per Default nicht mit dynamischen IPs möglich

Hier ist zumindest die Doku vom Tunneldigger: Tunneldigger documentation — Tunneldigger latest documentation

Eigentlich ganz einfach, wenn man nach der Doku geht.

Wie routet ihr das ganze denn raus?
Weiterhin per ip default route?
Was ist damit gemeint das ds mit dynamischen IPs nicht geht?

Das Routung bleibt gleich.

L2TP kann im Normalfall nicht mit Dynamischen IPs umgehen (die ja jeder DSL Anschluss im Normalfall hat)

Dafür ist der Tunneldigger da

Hallo, ist jemanden von euch Aufgallen dass UDP gedrosselt wird? Habe Tunneldigger am laufen und bekomme nur über Port 53 die vollen 25Mbit über UDP durch den Tunnel - alle anderen Ports pendeln sich bei Testdownloads um die 400kByte/s ein… 1und1 VDSL25 an Fritzbox 7412.

Hab das jetzt mehrfach überprüft und den Server als Fehlerquelle ausgeschlossen, auch andere UDP-Tunnel (vtun für Freifunk Weimar) zeigen das gleiche Verhalten an diesem Anschluss.

Das wäre ja ein ziemlich blödes Problem für diese UDP-Tunnel - ist das schonmal jemanden aufgefallen?

Der tunneldigger läuft bei uns auf 10050 und max waren 18k auf einem 100k KD Uplink möglich

Kann es damit zusammenhängen? Wie umgeht ihr dann das Problem, wenn dnsmasq auf 53 läuft?