[Freifunk Franken] l2tp Tunneldigger in Fürth auf fff-gw-cd1 - Tester gesucht!

mayosemmel mayosemmel at googlemail.com
Di Mär 29 18:59:04 CEST 2016


Hallo zusammen,

ich hab mir das im Wiki auch mal kurz angeschaut.
Grundsätzlich finde ich das alles ziemlich gut und hatte auch schon
überlegt was in dieser Richtung zu machen. Werde eure Lösung vermutlich
die nächsten Tage auch mal auf meinem GW implementieren. Zzt. habe die
ganzen l2tp Interfaces direkt am batman hängen.

Eine Sache verstehe ich aber noch nicht ganz. Wieso generiert ihr die
Mac Adresse aus der MTU? Die MTU ist ein statischer wert und somit nicht
geeignet irgendwas zu generieren?! Weiterhin ist bei "pro GW erhöhen"
die Gefahr von Mac-Konflikten relativ hoch und das führt zu sehr blöden
Problemen, die sich auch schlecht finden lassen.

Ich würde folgendes vorschlagen:
Die ersten 3 Blöcke komplett auf 0 setzten. Der Bereich gehört
eigentlich Xerox. Die bauen hauptsächlich Drucker und sowas. Sollte
relativ unproblematisch sein. Wir wären aber sicher, das wir immer die
"niedrigste" Mac haben und die Bridge sich somit nicht verändert.
Die restlichen 3 Blöcke würde ich mit den entsprechenden Blöcken aus
"eth0" füllen.

Das würde am Beispiel von meinem GW so aussehen:
~# ifconfig|grep eth0
eth0      Link encap:Ethernet  HWaddr 7a:88:63:96:16:41

Bridge wäre also 00:00:00:96:16:41

Dieser Prozess ließe sich sogar komplett automatisieren.

Würde mich interessieren, was ihr dazu meint. Eventuell hab ich auch
irgendwas komplett übersehen und es gibt doch einen guten Grund für euer
Vorgehen. Dann würde ich mich über eine Begründung freuen ;-)

Viele Grüße
Jan

Am Dienstag, den 29.03.2016, 14:33 +0200 schrieb Robert Langhammer:
> Hi,
> 
> Am 29.03.2016 um 08:01 schrieb Christian Dresel:
> > Hi Robert (RoLa ahhhh ;))
> >
> > Am 29.03.2016 um 00:43 schrieb Robert Langhammer:
> >> Hallo,
> >>
> >> ich habe heute noch die Sache mit den festen MACs ins wiki geschrieben.
> >> Vergleiche mal die bridge_funktions.sh und die mtu_changed, ob du die
> >> neuste Version hast.
> >> Batman kommt sonst durcheinander.
> > Ich glaube ja, 0a:00:03:01:14:46 und so? Wobei die Endziffer nicht zur
> > MTU passt:
> >
> > l2-br-fu1446 Link encap:Ethernet  HWaddr 0a:00:03:01:14:46
> >           inet6 addr: fe80::800:3ff:fe01:1446/64 Scope:Link
> >           UP BROADCAST RUNNING MULTICAST  MTU:1438  Metric:1
> >           RX packets:1217071 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:1349401 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:0
> >           RX bytes:164988455 (157.3 MiB)  TX bytes:221033257 (210.7 MiB)
> >
> > l2tp1011  Link encap:Ethernet  HWaddr ca:38:bf:b7:2f:9b
> >           inet6 addr: fe80::c838:bfff:feb7:2f9b/64 Scope:Link
> >           UP BROADCAST RUNNING MULTICAST  MTU:1438  Metric:1
> >           RX packets:1217071 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:1349405 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:1000
> >           RX bytes:196632301 (187.5 MiB)  TX bytes:221033777 (210.7 MiB)
> > (ist im moment die einzige Verbindung)
> >
> > wieso fehlen da 6 Bytes?
> > Achja ich hatte noch ein Problem mit dem Aufruf
> > . scripts/bridge_functions.sh
> > in xxx.up bzw. xxx.down und mtu_changed-xxx.sh
> >
> > Ich hab somit das bridge_functions.sh Script direkt an die Stellen wo es
> > aufgerufen wird kopiert und dann hat es auch funktioniert. Keine Ahnung
> > warum sich das Script nicht im Script aufrufen hat lassen (chmod +x und
> > so hatte es).
> Also hier Vorsicht. das bridge_funktions.sh wird mehrfach gesourced.
> Auch vom mtu_changed. Da fehlt im Original dei Variable $MTU, die ich
> noch hinzugefügt habe MTU=$NEW_MTU, damit bei einem mtu-Wechsel die
> richtigen MACs erzeugt werden.
> Da scheint was nicht zu passen.
> 
> >
> >> Habt ihr in Fürth mehrere Gateways? Wenn du nur zu einem einen l2tunnel
> >> hast, solltest du mal schauen was die gw-selection macht!
> > meinen und nue1 wobei ich nue1 in der Gatewayselection immer deutlich
> > übertrumpfe (der ist eh zu lahm ;)) also wählt (die gefixte) Gateway
> > Selection eigentlich immer sicher mein Gateway aus.
> >
> >> Die Firmware habe ich nochmal neu gemacht. Habe das dual raus genommen,
> >> da das eigentlich keine gute Option ist und nur Traffic erzeugt.
> >> Ausserdem schaltet es jetzt vollständig um und bleibt bei Neustart.
> > Muss man dennoch anfangs manuell einschalten oder geht jetzt alles
> > automatisch? Werde dann wohl nochmal flashen. Ist das l2tp
> > Trafficzählfix eigentlich auch schon drinnen?
> Ja, sollte drin sein. Ist ja auch schon im master.
> >> Ach ja, die Broker in Has und Hassüd laufen auch wieder, und bis jetzt
> >> auch stabil.
> >>
> >> Du kannst also auch bestätigen, dass es sich ein so anfühlt, als wäre
> >> man auf der Überholspur?
> > theoretisch ja, Problem bei mir ich bin bei der Telekom. Selbst wenn ich
> > ohne Freifunk was über meinen 50Mbit VDSL Anschluss von meinen
> > Hetznerserver lade, lande ich bei max. 20-30Mbit [1]. Das ging auch
> > nahezu durch den fastd und geht jetzt auch l2tp wobei die CPU Last bei
> > l2tp natürlich gegen 0 geht und bei fastd schon nicht ganz ohne war.
> > Wäre super wenn es in Fürth mal Leute mit Kabeldeutschland testen, da
> > ist das peering Problem nicht so schlimm.
> > (gerne auch Download von [2] dann muss es nicht durch den Mullvad)
> >
> > mfg
> >
> > Christian
> >
> > [1] http://wiki.hetzner.de/index.php/Double_Paid_Traffic
> > [2] http://10.50.32.4/100mb.test
> >
> >> Robert
> >>
> >> On 28.03.2016 22:50, Christian Dresel wrote:
> >>> Hallo zusammen
> >>>
> >>> ich hab mich vorhin mal hingesetzt und das Tunneldigger Zeug mit Bridges
> >>> und gedöns auf meinen Server aufgebaut. Das ganze scheint jetzt zu laufen.
> >>>
> >>> Daher meine bitte das ganze unbedingt mal zu testen (nur in der Fürther
> >>> Hood!!). Rola war so nett eine fertige Firmware dafür zu bauen und den
> >>> Link ins Wiki zu schreiben. Ich hab die Firmware auf einen 841er v9
> >>> geflasht und gleich mal 30Mbit durch den Tunnel gejagd :) Die Firmware
> >>> gibt es hier:
> >>> http://10.50.60.3/firmware/ oder http://78.47.36.148/firmware/
> >>> Quelle: https://wiki.freifunk-franken.de/w/L2TP_und_Tunneldigger#Am_Router
> >>>
> >>> Nach dem flashen ganz normal im WebUI konfigurieren und dann per SSH
> >>> verbinden und folgendes ausführen (erst sobald er sicher in der Fürther
> >>> Hood ist! Lieber 5-10 Minuten warten nach dem Konfigurieren und ein
> >>> Sicherheitsreboot schadet auch nicht):
> >>>
> >>> l2tunnel conf
> >>> /etc/init.d/tunneldigger start
> >>> l2tunnel on
> >>>
> >>> und schon sollte er einen l2tp Tunnel zu fff-gw-cd1 aufbauen welcher
> >>> wesentlich perfomanter als das alte fastd VPN sein sollte.
> >>>
> >>> Ich hab aktuell hier 2 Router am Internetuplink hängen, einer macht zur
> >>> Sicherheit noch fastd (
> >>> https://monitoring.freifunk-franken.de/routers/5664399b44ce6e0307512960
> >>> ) und der zweite l2tp (
> >>> https://monitoring.freifunk-franken.de/routers/56f98b069369c317dfbc9630
> >>> ). Somit hab ich auch noch volle ausfallsicherheit, Batman kümmert sich
> >>> da schon um die beste Route. Also nicht denken "oh und wenn das
> >>> ausfällt...?" Einfach ein Backupsystem laufen lassen dann klappt das
> >>> schon :)
> >>>
> >>> Man kann gerne auch mit l2tunnel dual herumspielen, das hab ich bisher
> >>> noch nicht getestet.
> >>>
> >>> Ich würde also alle Fürther bitten das auf jeden Fall mal zu testen.
> >>> Fehler kann ich und alle anderen erst dann erkennen wenn es mal nicht
> >>> geht, wenns keiner testet erkennt man auch keine Fehler. Große bitte
> >>> auch an die Leute zu testen, die viel Traffic erzeugen, denn das würde
> >>> ich auch gern testen ob da mehr durch geht.
> >>>
> >>> Vielen Dank schon mal
> >>>
> >>> mfg
> >>>
> >>> Christian
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> franken mailing list
> >>> franken at freifunk.net
> >>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> >>
> >>
> >> _______________________________________________
> >> franken mailing list
> >> franken at freifunk.net
> >> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> >>
> >
> >
> >
> > _______________________________________________
> > franken mailing list
> > franken at freifunk.net
> > http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> 
> 
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20160329/23468afb/attachment.sig>


Mehr Informationen über die Mailingliste franken