L2TP/Tunneldigger Serverdoku-Thread

Technik
86

Die Plasterouter-Seite hatte ich übersehen. Denn selbst wenn man das zu Beginn der Verbindungsaushandlung tut, müsste dann der router sinnvollerweise mit (in der Meshwolke) lokal gehaltenem RAs klar machen, was die „MTU des Tages“ ist… Und man müste sich überlegen, was man tut in Wolken mit mehreren (unterschiedlichen) VPN-Uplinks.

Das klingt jetzt nach einem größeren Unterfangen, ob denn nach einer sauberen Implementation im gluon-Paket da ein riesiger Batzen zusätzliches Regressiontesting unabdingbar wäre
a) alle „kleinen“ Routerchen schaffen (vgl. issues…->„instablility beyound certain point“ ->„high load on certain devices“) und
b) eine Testbench mit mindestens zwei Dutzend üblicher Clients (Android-Versionen inkl. zerbrandeter Herstellergewächse)

Du hast mich überzeugt, dass das nur geht, wenn sich jemand das als ganz persönliches Jahresprojekt auf die Brust heftet. (und denjenigen sehe ich gerade nicht.)

87

Ich denke am saubersten wäre es das MTU Feature umzubauen :slight_smile: Klar auf der Server Seite braucht man dann immer noch Bridges aber auf der Client Seite nicht. Außerdem würde das lästige aus der Bridge entfernen und zur richtigen hinzufügen wegfallen (das sorgt sicher auch für unnötigen Overhead).

88

Hallo,

wir haben das System mit MTU Discovery schon etwas länger am laufen. Am Server wird Automatisch pro MTU eine Bridge und ein L2TP Interface angelegt.

Auf Seite des Routers gibt es pro L2TP Gateway ein Interface.

89

Leider funktioniert das nicht zuverlässig, die MTU darf nicht geändert werden wenn das Interface bereits in bat0 hängt. Dies ist der Fall wenn das Gerät die Verbindung aufgebaut hat und das Interface erstellt ist.
Batman-adv merkt die Änderung leider nicht was ich mit bat14 getestet habe, daher ist das Feature nie mit ins Gluon Paket gekommen.

90

Sieht so aus. :wink:

Ich bin gerade seit zwei Wochen tief genug drin, um da Patches zu senden… immer langsam.^^

Ah, das wusste ich nicht! Das erklärt aber, warum das hier nicht ging solange Auto-MTU-Discovery an war.

Eh, sicher? Mein Knoten (Gluon v2017.1.3) sagt

24: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1446 qdisc tbf master bat0 state UNKNOWN qlen 1000

und das trotz einer MTU von 1406 in der site.conf…

91

Ich habe gerade einen Pull Request für das Session-ID-Problem erstellt:

3 „Gefällt mir“
92

Das Problem habe ich inzwischen diagnostiziert und entsprechend den folgenden PR eingereicht:

In Anbetracht der Tatsache, dass beim Switching an den Knoten keine MTU-Anpassung stattfinden kann (bei zu kleiner MTU des Ausgehenden Interface wird das Paket einfach gedroppt) bin ich inzw. zu dem Schluss gekommen, dass eine exakte Ermittlung der Tunnel-MTU den Aufwand nicht wert ist. Batman muss doch auf den Knoten so oder so fragmentieren, da die Clients im Zweifel eine MTU von 1500 ansetzen. Auf den Gateways dagegen findet ja Routing statt, nicht Switching. Daher haben wir da Batman-Fragmentierung ausgeschaltet – wenn vom Internet (via FFRL) eingehende Pakete zu groß sind, schickt das GW eine ICMP-Nachricht zurück, die dafür sorgt, dass der Absender die Pakete kleiner macht. Außerdem setzen wir die MTU unseres Endes der FFRL-Tunnel auf 1280. Wenn also ein Client zu große Pakete schickt, fragmentiert Batman die zwar (was schlecht ist für die Performance), aber wenn das GW sie routet, merkt es, dass sie zu groß sind, und schickt eine ICMP-Nachricht an den Client, dass er 1280 als MTU verwenden soll. Batman muss also nur einmal fragmentieren, alle folgenden Pakete werden gleich vom Client fragmentiert (zumindest unter IPv6).

2 „Gefällt mir“
93

Seltsam, bei mir klappt das ganze aber mit der MTU. Evlt ist das von Gerät zu Gerät unterschiedlich? Ich habe einen TP-Link TL-WR841N/ND v3

20: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1364 qdisc fq_codel master bat0 state UNKNOWN qlen 1000
    link/ether fa:70:2b:bb:0d:8f brd ff:ff:ff:ff:ff:ff
94

Das MTU-Problem (also dass die MTU auf den Knoten nicht die in der site.conf ist) konnte ich wie gesagt via https://github.com/wlanslovenija/tunneldigger/pull/67 lösen. Der Gluon-Client hat keinerlei Änderungen bzgl. automatischer MTU-discovery, aber wenn der Server sich weigert, mitzuspielen, dann passiert da nix.

2 „Gefällt mir“
95

Magst Du nochmal zusammenfassen, welches der Migrationsweg ist, um von einer „alten“ (mit unique-TunnelID-Bug behafteten) Version auf Plasteroutern und Servern zu der gefixten zu kommen?
Und welche Anpassungen müssen/können für „AutoMTU“ dabei parallel noch (zwingend/optional?) gemacht werden?

Also bitte die Reihenfolge von „welches Gluon-Paket zuerst“, was „dann“ auf den Servern? Muss auf letzteren (außer "ab jetzt kann ein aktueller Linux-Kernel gefahren werden) noch was anderes getan werden?

96

Die Reihenfolge (Server/Client) ist egal, da die neuen Versionen jeweils mit den alten kompatibel sind. Wir haben aktuell auf allen Gateways den neuen Server, läuft super. Außerdem haben wir eine Beta-Firmware mit dem neuen Client. Die würde sich auch mit alten Servern noch verbinden können. Eines der Gateways hat einen neuen Kernel mit dem „Problem“; auf diesem Gateway landen dann automatisch (wie unten beschrieben) nur die Clients, die unsere Beta-Firmware nutzen. Natürlich werden wir noch mindestens ein Gateway mit altem Kernel betreiben müssen, bis es keine Knoten mit altem Client mehr gibt, das wird also noch eine Weile dauern.

Auf Serverseite muss an der Konfiguration gedreht werden. In der Beispiel-Konfig siehst du, welche Optionen überhaupt noch relevant sind. Wichtige neue Optionen, wo du auch eventuell vom Default abweichen willst, sind connection_rate_limit=0 (das deaktiviert rate-limiting von neuen Verbindungen) und pmtu=1406 (also wir nehmen da 1406 und keine auto-discovery, genau wie mit dem alten Server auch). Außerdem ist noch zu beachten, dass die hooks jetzt asynchron sind – sprich, pre-down ist eher witzlos geworden, da das Interface abgeschaltet wird während das Script nocht läuft. Wir haben unseren hook auf down geändert. Ein Entfernen des Tunnelinterface von der Bridge ist ohnehin nicht notwendig; wenn der Tunnel gelöscht wird, geschieht das automatisch.

Der Server erkennt automatisch, wenn der Kernel wegen „duplicate session ID“ meckert. Sobald das der Fall ist, bekommen alte Clients, die keinen Support für „unique session ID“ ankündigen, gesagt, der Server sei voll. Wenn ihr also lastbasierte Serverauswahl macht, sollten solche Clients dann automatisch andere Broker nehmen, bei denen keine „unqiue session ID“ nötig ist. Beachtet jedoch, dass es in alten Clients (inkl. dem im aktuellen Gluon) einen (inzwischen korrigierten) Bug gibt, sodass der Client sich mit dem ersten Server zu verbinden versucht, wenn er von keinem eine Antwort bekommt – es macht also Sinn, den als letztes auf einen neuen Kernel zu aktualisieren.

Auf Clientseite nutzen wir in unserer aktuellen Beta-Firmware unser eigenes tunneldigger-Paket. Das ist der aktuelle master von wlanslovenija, plus https://github.com/wlanslovenija/tunneldigger/pull/66. Nachdem dieser PR akzeptiert wurde, will ich einen PR an Gluon schicken, der den Client dort aktualisiert. Der PR hat mit „unique session IDs“ nichts zu tun, ihr könnt also gerne statt dessen wlanslovenija master verwenden.

1 „Gefällt mir“
97

Das ist gut, ich dachte nämlich bislang, dass zunächst zwingend sämtliche Clients (Plasterouter) geupdated werden müssen.

Das verstehe ich nicht.
Wie verbinden sich diese alten Clients dann? Ist das mit dem „vollen Server“ ein Hack, damit die dann seitens des Clients doch eine höhere ID auswürfeln?

Da finde ich leider den v2016.2.x-Releasetag nicht.

Was muss genau mit den down-hooks gemacht werden, wenn die jetzt beachtet werden?

Sorry, vielleicht habe ich auch zu viele Dinge aufeinmal gefragt.

Kannst Du evtl. nochmal die Reihenfolge der notwendigen Änderungen herunterbrechen in einen klaren Ablauf?

98

Meine Aussage bezieht sich auf die neue Version des tunneldigger-Brokers, also des Servers! Den kann man auch mit alten Knoten deployen. Man muss jedoch erstmal auf dem alten Kernel bleiben, zumindest bei einem Gateway:

Alter Knoten, alter (Tunneldigger-)Server, neuer (Server-)Kernel: Kaputt.
Alter Knoten, neuer (Tunneldigger-)Server, neuer (Server-)Kernel: Kaputt.
Neuer Knoten, alter (Tunneldigger-)Server, neuer (Server-)Kernel: Kaputt.

Alter Knoten, neuer (Tunneldigger-)Server, alter (Server-)Kernel: Alles gut.
Neuer Knoten, alter (Tunneldigger-)Server, alter (Server-)Kernel: Alles gut.
Neuer Knoten, neuer (Tunneldigger-)Server, alter (Server-)Kernel: Alles gut.
Neuer Knoten, neuer (Tunneldigger-)Server, neuer (Server-)Kernel: Alles gut.

Nein. Die ID steht fest auf 1, da gibt es nichts dran zu drehen.
Es ist ein Hack, damit die alten Clients sich nicht verbinden. Sie denken, die „zu neuen“ Server sind voll, und nehmen daher andere.

Die Idee ist die: Wir wollen den neuen Kernel schon auf manchen unserer Gateways verwenden (auch um zu sehen, ob das klappt), während jedoch gleichzeitig noch alte Knoten unterwegs sind. Wie verhindert man jetzt, dass die alten Knoten sich mit dem Gateway verbinden, das den neuen Kernel verwendet? Man macht sich zu Nutze, dass die Knoten erstmal bei allen Gateways die Last abfragen, und sich dann mit dem verbinden, der am wenigsten belastet ist. Wenn als Gateways mit neuen Kerneln gegenüber alten Knoten so tun, als wären sie voll, dann gegen die alten Knoten woanders hin (solange es ein „woanders“ gibt, solange also nicht alle Gateways neue Kernel haben).

Das geht, weil die Clients, wenn sie den Server fragen, wie voll sie in, auch ein paar Flags mitschicken. Der Server sieht also, ob der Client „unique session IDs“ kann, und ändert eine Antwort auf die Frage „Wie voll bist du?“ entsprechend.

Ah, ja, wir sind auf v2017.1.x.

Das hängt davon ab, was eure pre-down hooks tun. Unsere haben zwei Dinge getan: Den Tunnel aus der Bridge nehmen, und was ins Log schreiben. Ersteres ist nicht nötig. Zweiteres geht auch wunderbar im down Hook. Da kann man leider keine allgemeine Anleitung geben, das hängt von eurer Konfiguration ab.

Wie gesagt, die Reihenfolge ist unerheblich. Ihr braucht neue Tunneldigger-Serversoftware auf euren GWs und neue Tunneldigger-Clientsoftware auf euren Knoten. Sobald ihr neue Tunneldigger-Serversoftware auf euren GWs habt, könnt ihr auf einzelnen GWs auch den Kernel aktualisieren – aber auf diesen GWs können sich dann nur Knoten mit dem neuen Client verbinden!

Beim Server hängt das Update davon ab, wie genau euer Setup vorher aussah – bei uns wurde einfach nur das git-Repo ausgetauscht (statt vom FFRL ziehen wir jetzt von wlanslovenija bzw. von unserem Fork davon), und die beschriebenen Änderungen an der Server-Konfiguration (l2tp_broker.cfg) durchgeführt.

Beim Client ist keine neue Konfiguration nötig. Man muss „nur“ Gluon dazu bringen, den Tunneldigger-Client in einer anderen Version zu ziehen. Wir haben das für die von uns verwendete Gluon-Version gemacht. Ist aber nicht schwer, wenn du unser Paket mal mit dem Original diffst, kannst du das sicher mit dem 2016er genau so machen. Oder, besser, Gluon aktualisieren. :wink:

1 „Gefällt mir“
99

Was passiert denn bei Folgendem:
„Neuer Knoten, alter (Tunneldigger-)Server, neuer (Server-)Kernel“

(ich erkenne gerade nicht, was sich am Server geändert hat. Mag aber sein, dass ich die Serverdoku (bzw den Migrationspfad) nicht so recht nachvollziehen kann serverseitig. )

100

Habe ich gerade rein-editiert. Das ist kaputt. Wenn der Kernel neu ist, müssen Knoten und Broker/Server neu sein. Dies ist die einzige Einschränkung.

Siehe alle Änderungen im Ordner broker auf Unique session ids by RalfJung · Pull Request #64 · wlanslovenija/tunneldigger · GitHub

101

Gibt es zu Eurem Tunneldigger-Server-Broker eine Installationsanweisung?
(Ich mag mich wirklich nicht durch git-Commit durchhangeln, wenn mir Sätze unklar sind wie
„once we get a duplicate session ID failure, pretend to clients not supporting unique session IDs that we are full“)
Ich vermute zwar nun nach Deiner obigen Erklärung, das verstanden zu haben. Aber es sind leider mehrerer weitere.
Installationsanweisungen aus diffs von Forks abzuleiten: Kan man tun. Aber dann muss das leider jeder tun.

Ich finde es wirklich toll, dass Du Dich des Problems angenommen hast und einen Fix lieferst.
Nur zumindest derzeit habe ich -und damit bin ich vermutlich nicht der einzige- Probleme, das inhaltlich nachzuvollziehen, da ich die Implikationen des geänderten MTU-Handlings „für den Rest des Server-Setups“ nicht abzuschätzen vermag. (Was am radvd tun, was am dhcpd, implikationen für die parallel im gleichen L2 laufenden fastd-Knoten mit niedriger MTU?)
Warum kein PR auf das original-Repository plus Update der Installationsanweisung dort?

102

Das ist doch das Original-Repository, und da habe ich auch den PR hin gesendet? Die Anleitung unter https://tunneldigger.readthedocs.io/en/latest/server.html sollte aktuell sein; wenn nicht, bitte einen Bugreport erstellen. :slight_smile:

Das MTU-Setup muss sich nicht ändern. Wenn ihr vorher auto-MTU verwendet habt, sollte das weiterhin klappen – vermute ich, da ich leider nicht ganz verstehe, warum/wie das überhaupt je geklappt hat. :wink: Testen konnte ich natürlich nur, was wir verwenden, und das war vorher und ist jetzt eine feste MTU von 1406.

Es muss sich also noch jemand finden, der die neuen Versionen mal mit auto-MTU ausprobiert, in einem Kontext, wo auto-MTU vorher ging – idealerweise jemand, der weiß, wie man sowas vernünftig testet. Da bin ich nämlich raus.

103

Zumindest finde ich da nichts zu den Hook-Scripts, wie das jetzt mit dem Logging funktioniert, das Du oben angesprochen hattest beim Pre-Down.

104

Ja, dass dort Logging passiert war unsere eigene Config. Die haben wir damals zusammenkopiert von diversen Tutorials für „l2tp und Freifunk“ – ich weiß ehrlich gesagt nicht mehr, welche das waren (und einige der Links, auf die ich damals Lesezeichen gesetzt habe, sind tot). Diese Tutorials kann ich nicht aktualisieren, die werden von den jeweiligen Communities gepflegt.

Wenn ihr kein Logging habt im pre-down, ist das auch okay. Es geht nur darum, dass du dir anschauen solltest, was ihr im pre-down habt, und dann entscheiden, ob das okay ist, das statt dessen im down-Hook zu machen. Da ich nicht hellsehen kann, weiß ich nicht, was bei euch im pre-down passiert :slight_smile: Vielleicht habt ihr auch gar keinen pre-down Hook? Falls ja, umso besser, dann kann der schonmal keine Probleme mehr machen.

Ich kann ja schlecht für jede Konfiguration, die irgendeine Freifunk-Community sich mal anhand irgendwelcher Tutorials zusammenkopiert hat, exakte Anleitungen bieten. Da gehe ich dann schon davon aus, dass jeder so viel Überblick über sein eigenes Setup hat, dass er generelle Tunneldigger-Anleitungen (die z.B. erklären, wie der Dienst jetzt gestartet wird – das hat sich auch geändert, was ich oben zu erwähnen vergaß) mit dem eigenen Setup in Einklang bringen kann. Dabei kommen u.U. konkrete Fragen auf, die ich gerne beantworte.

Was eventuell auch nützlich wäre, ist eine neue Freifunk-Tunneldigger-Anleitung für den neuen Broker. Also kein Anleitung für ein Update (da gibt es zu viele Unbekannte), sondern ein „wie setze ich das neu auf“. Sowas habe ich nicht geschrieben, da fehlt mit aktuell einfach die Zeit. „Eventuell“, weil es davon schon mehrere gibt – es wäre viel weniger Arbeit, eine der vorhandenen Anleitungen zu aktualisieren. Außerdem steht die Tunneldigger-Config natürlich nicht alleine im Raum, die muss ja passen zur Batman-Config und was man so für Bridges hat und so – also eigentlich braucht man da ein kohärentes Tutorial für ein komplettes Freifunk-GW samt passender Gluon-Config (Stichwort MTU), und dafür fehlt ganz sicher die Zeit. Sorry :confused:

1 „Gefällt mir“
105

Ralf, es wäre vielleicht hilfreich wenn die Changes und ihre Implikationen in der HISTORY.rst beschrieben wären.
Das mache ich eigentlich immer wenn ich neue Features committe. Siehe z.B. hier bei meinem letzten Change: Add cmake for client · wlanslovenija/tunneldigger@95e4229 · GitHub