[ffdus] l2tp Testbetrieb

Community Düsseldorf
1

Dank der Serverdokumentation von @CyrusFox
läuft nun für ffdus auch ein L2TP-Supernode.

Das dreht auf dem neuen Server, den @trickster Ende letzten Monats zusätzlich beschafft hat.
Der „Konzentrator“ auf dem Eisen wartet noch auf eigene FFRL-GRE-Tunnel, aber mit einer vermuteten Wartezeit von 8 Tagen bin ich guter Hoffnung. Derweil müssen die Hosts „Flingern3“ (cable3-cableX) und „Flingern-L“ (cable9-cableX) also ihre Nutzlast noch über Flingern-1 (cable1-cablex twin) und Flingern2 (cable2-cableX - nadeshda) abwerfen.

Wer testen möchte (und keine Garantie für 24/7-Verfügbarkeit) benötigt, der mag sich die Firmware von
http://images.ffdus.de/broken-l2tp/
ziehen. Ein Wechsel zwischen fastd und l2tp-FW ist problemlos möglich.
ggf. ist lediglich -für zukünftige Update- die Autoupdater-Branch zu tauschen.

uci set autoupdater.settings.branch=experimental 
uci commit

bzw

uci set autoupdater.settings.branch=experimentall2tp
uci commit

Wechsel dann zum Beispiel (hier: 841v9) mit:

cd /tmp
wget http://[fda0:747e:ab29:9375:cafe::]/images/brokenl2tp/sysupgrade/gluon-ffdus-2016040718-exp-tp-link-tl-wr841n-nd-v9-sysupgrade.bin
sysupgrade gluon-ffdus-2016040718-exp-tp-link-tl-wr841n-nd-v9-sysupgrade.bin

ggf. Link anpassen.
Oder konventionell den Router in den Setup-Mode drücken aus dem laufenden Betrieb und dann das Sysupgrade-Image über das Webinterface hineinladen.

Wichtig zu beachten: L2TP bietet keine Content-Verschlüsselung. Der Uplink-Spender kann also potentiell mittel DPI schauen, was die clients für Daten für VDS liefern. Diskussionen dazu wurden aber bereits ausführlich an anderer Stelle geführt. ggf. bitte dort anknüpfen.
Für FFDUS ist derzeit geplang, langfristig sowohl Fastd mit Verschlüsselung und L2TP -derzeit ohne Verschlüsselung- anzubieten.

P.S. Die Darstellung auf der Karte (genauer: Dem Node-Graphen) ist leider derzeit unbefriedigend, da Alfred/respondd die L2TP-Tunnel leider nicht als typ „mesh-vpn“ melden, sondern nur als „other“, und damit das Rendering „als graue Linie“ leider nicht gelingt, da kein Unterschied (in den übermittelten Daten) zu Lan-Mesh-Links besteht.

<img src=„/uploads/default/original/2X/7/72844558878658a7afa459288239046be95d0e01.png“ width=„690“ height="313

1 „Gefällt mir“
2

Im Vorgriff auf eine eventuelle Umstellung der „Lindung“: Welche Ports braucht L2TP im Gastnetz der Fritzbox abgehend freigeschaltet? Wenn beides parallel angeboten wird, werden es wohl andere sein?

3

Wenn es dabei um die 164.132.62.120 geht, habe ich die Tunnel am Montag Abend angelegt und dir via Ticketsystem geantwortet. Kannst du mal bitte im Spamfilter schauen (Zeitpunkt: 04.04.2016 20:51)?

1 „Gefällt mir“
4

Muss nicht unbedingt ein anderer Port sein, da l2tp ja über einen anderen Server läuft

5

Ahh ja. Würde natürlich den Umstieg auf Anwenderseite sehr vereinfachen. Ich habe hier den Zugang des Uplinks ziemlich vernagelt bis auf die Ports für den Tunnel.

6

Danke Lars für den Hinweis,
es war in der Tat von dem Roboter bei Gmail in den Spam geräumt worden und lag dort zwischen einer Mitteilung zu meinem angeblichen Sparkassen-Banking-Login und Anpreisungen für Präparate gegen erektile Dysfunktion…

Aber schön, Tunnel am Freitag abend in Betrieb genommen, Exit-IP rüber gezogen.
Neuer Konzentrator (gre-Tunnel, NAT) läuft. Auf dem gleichen Eisen liegt auf einer vmbr jetzt als eine VM der fastd-supernode „flingern-3“ und ein „flingern-l“, der -wer würde es vermutet haben- l2tp macht.

Hätte man natürlich auf einer VM machen können, aber für’s Monitoring und debugging lass ich es lieber getrennt. Wir haben sowieso erfahrungsgemäß mehr Kerne und RAM als eth-Bandbreite. Bandbreite physikalisch ist schließlich das Nadelöhr.
(Da hilft dann auch kein L2TP, geht eher um’s Offloader-einsparen.)

Wie @PetaByteBoy schon schrieb: Es bleibt bei 10000/UDP, da so wenig geändert werden muss in vernagelten Setups.
(Settings wie üblich bei Github, wenn jemand nachschauen oder selbst bauen möchte.)

Ich überlege, ob ich noch zusätzlich auf Port 53 gehe als Alternative. Wobei das an „Fritbox-Gastnetz“&Co auch nicht hilft, da die meines Wissens den DNS (53/UDP) nicht transparent durchlassen, sondern sich da mit ihrem „Jugendschutzfilter“ dazwischenhängen und selbstredend dann natürlich auch nicht raw data durchlassen.

Was den Aktuellen Status betrifft:
4-5 Nodes laufen derzeit drauf. Auch 841v9 schaffen nun etwas mehr Grip auf die Straße. War zu erwarten.
Vom Logging/Debugging bin ich vom L2TP positiv überrascht. Und das Einhängen in die Tunnel ist so smart samt der Hook-Scripts, dass ich schon viele Dinge überlege, die man dort tun könnte. Allein diese Möglichkeiten sind großartig gegenüber dem mürrisch verschwiegenen Fastd, der selbst mit „verbose debug“ settings jedes Byte an Infos einzeln aus der Nase gezogen bekommen möchte.

Zurück zu Praxis: Meiner Meinung nach kann man es nun schon ausprobieren auf Nodes, die zumindest „in Griffweite“ sind und zu denen man auch einen ssh-Login hat für den Fall der Fälle.

Ach ja, wie dort hinwechseln? manuell ein sysupgrade aus

oder einfacher:
Einloggen auf die Shell und dann:

uci set autoupdater.settings.branch=experimentall2tp
uci commit
echo "config branch 'experimentall2tp'">>/etc/config/autoupdater
echo "        list mirror 'http://images.ffdus/brokenl2tp/sysupgrade'">>/etc/config/autoupdater
echo "        list mirror 'http://images.ffdus.de/brokenl2tp/sysupgrade'">>/etc/config/autoupdater
echo "        list mirror 'http://[fda0:747e:ab29:9375:cafe::]/images/brokenl2tp/sysupgrade'">>/etc/config/autoupdater
echo "        list mirror 'http://[2a03:2260:122::4]/images/brokenl2tp/sysupgrade'">>/etc/config/autoupdater
echo "        option good_signatures '1'">>/etc/config/autoupdater
echo "        option name 'experimentall2tp'">>/etc/config/autoupdater
echo "        list pubkey 'fb919d4adc69bd404f5093ce6b43badf351f9e642ad458406be986baf6096247'">>/etc/config/autoupdater
echo "        list pubkey '2a61930930a240c027f6ca4197203d400b6e4a32f9e92041e5f086907796c9bc'">>/etc/config/autoupdater
echo "        list pubkey 'd02f8e60fb7a5069556500694ebe512b6017b01e9950476e4cfcf10d5130c296'">>/etc/config/autoupdater
echo "        list pubkey '7afe187ceb34e83b2cb33c244ab5c8a7e80829c3e83b8d3fc471d2642eb6a602'">>/etc/config/autoupdater
echo "        list pubkey '610e9acf4d550c3a272b88ec5b4cf0a0e382be203f98b860181fb1bcb1641abd'">>/etc/config/autoupdater
echo "        list pubkey 'dd6a9d1aefc175f885705691498e904cbda12cc4602316f04816d78026c7c0f0'">>/etc/config/autoupdater
echo "        list pubkey '579de7b1ded1dc39583515f722d72524f6dce78da635a7ac2d11cfe1dc046e7e'">>/etc/config/autoupdater
echo 20160101>/lib/gluon/release
autoupdater -f &
1 „Gefällt mir“
8

Es gibt jetzt aus Redundanzgründen noch einen zweiten L2TP-Server (flingern-m.ffdus.de)
Der ist auf einem anderen Eisen als der erste auf dem anderen Tunnelsatz zum Backbone.

9

Zum Wechsel von fastd zu l2tp gibt’s ein packet:

10

Ich denke mal, dass es beim Wechsel des Release-Channels keinen Einfluss hat.
Oder meinst Du, der Wechsel „zurück“ ist damit ggf. für Leute versperrt?

Ich sehe gerade nicht das Szenario, welches das Problem bereitet.

11

Wenn meshvpn mit fastd aktiviert ist und eine Firmware mit l2tp eingespielt wird , dann ist l2tp nicht automatisch aktiv. Das Script setzt die richtigen Parameter.

12

Und was ist da schief gelaufen oder sollte verbessert werden Deiner Meinung nach?
Oder meinst Du, man sollte das Paket nicht verwenden?