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.
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)
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.
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!
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
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.
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.
Das ist zumindest das min. bei IPv6.
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
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?
