L2TP/Tunneldigger Serverdoku-Thread


#106

Könnte es sein, dass die config

[log]
; Log filename
filename=tunneldigger-broker.log

nicht mehr dazu führt, dass logfiles produziert werden?


#107

Korrekt.
Das müsste schon mit dem rewrite des brokers verloren gegangen sein (im Code werden Logs nur ins Syslog geschrieben). Das bedeutet also, dass euer Broker ca. von 2015 sein müsste (vor dem Rewrite).
Mit journalctl lässt sich das eigentlich ganz bequem ersetzen. Wer allerdings Dateibasierte Logfiles bevorzugt (ich bin mir sicher, da gibt es genügend Gründe), müsste darauf warten bis es wieder implementiert wurde bzw. (sofern dazu befähigt) es selbst implementieren.
Aus diesem Grunde wurde die o.g. Config-Direktive auch aus dem Beispiel-Configfile entfernt.


[Anleitung] Gateway aufsetzen mit Ansible für Neulinge
#108

Gute Idee, den Changelog mal zu aktualisieren. :slight_smile: Werde die Tage einen PR vorbereiten. Da fehlen glaube ich auch noch Änderungen, die schon vor meinen PRs erfolgt sind; die kann ich dann auch gleich dokumentieren. Der von dir später erwähnte Broker-Rewrite brachte doch diverse Änderungen, die glaube ich nirgendwo alle schön aufgelistet werden. Manches fiel mir beim Portieren auf, aber ob die Liste vollständig ist?


#109

Das Changelog-Update kommt unter

@adorfer ist das hilfreich? Der FFRL-Fork ist etwa auf Stand von v0.1.0.


#110

Danke!


#111

ich habe den Client gebaut im Makefile mit

PKG_REV:=404a3c9c0b5b0f0ab8ce4ae52aca09edf2ebcd77
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=git://github.com/wlanslovenija/tunneldigger.git

Trotzdem bekomme ich noch Client-Requests auf TunnelID1, obwohl da schon ein Dutzend Sessions mit dieser ID sind.

Dec 17 01:03:19 flingern-l start-broker.sh[1504]: [INFO/tunneldigger.hooks] Running hook 'session.up' via script '/srv/tunneldigger/scripts/session-up.sh 298 1 l2tp298-1 1364 109.90.117.191 54921 20298 30b5c28644ae'.

(Zumindest passt das gemäß Doku nicht. Irgendwas klemmt da:
<tunnel_id> <session_id> <endpoint_ip> <endpoint_port> <local_port>
Was übersehe ich?)
Ja, den Server habe ich auch vom aktuellen Master installiert von wlan-slovenija.


#112

o.k. es lag an einem fehlenden make-clean im gluon-buil.
Wie ich sehe, hat das client-Paket von wlan-slovenija jetzt kein Makefile mehr.
Was muss ich denn tun, damit aus der cmakelist.txt ein makefile herausfällt beim normalen Gluon-Build für ChaosCalmer?


#113

als diff gegen das alte Paket-Makefile sieht das dann so aus:

EDIT: Das Forum schneidet leider den Anchor-Link ab. Aber du wirst die Commits schon finden, der PR ist so lang nicht :wink:
EDIT2: Aha, der Anchor verbirgt sich nur im grauen github.com Link.


#114

Ich habe jetzt sowohl den ffrl-tunneldigger-broker als auch den wlan-slovenija geforked und so weit bekommen, dass er jetzt für Gluon 2016.2.x baut.

vorher:

Dec 17 17:55:19 flingern-l start-broker.sh[1504]: [INFO/tunneldigger.hooks] Running hook ‘session.pre-down’ via script ‘/srv/tunneldigger/scripts/session-pre-down.sh 298 1 l2tp298-1 1364 109.90.117.191 54921 20298 30b5c28644ae’.

fw update läuft, dann

Dec 17 17:56:55 flingern-l start-broker.sh[1504]: [INFO/tunneldigger.broker] Creating tunnel 109.90.117.191:43916 (30b5c28644ae) with id 313.
Dec 17 17:56:55 flingern-l start-broker.sh[1504]: [INFO/tunneldigger.hooks] Running hook ‘session.up’ via script ‘/srv/tunneldigger/scripts/session-up.sh 313 313 l2tp313-313 1364 109.90.117.191 43916 20313 30b5c28644ae’.


#115

Das sieht doch gut aus :slight_smile:


#116

Wie ist denn der aktuelle Stand, was installiert man wie seit Mitte 2018 für Gluon v2018-Clients, vorzugsweise auf Ubuntu 16.04 LTS (oder 18.04 LTS mit ifupdown)? Gibt’s Erfahrungen mit FFNWs puppet-Modul?


#117

Die Doku gibts unter https://tunneldigger.readthedocs.io/en/latest/. Hast du da konkrete Fragen zu?


#118

Ich schließe mich der Frage von @wusel an und würde auch gerne den aktuellen Stand erfahren. Der Verweis auf die Tunneldigger-Doku ist für mich nicht sonderlich hilfreich, da mir eine Übersicht des Gesamtzusammenhangs aus Kernelversion und Tunneldigger fehlt.

Konkret: welchen Tunneldigger muss ich wie auf Gateway und Knoten installieren, damit es funktioniert und abwärtskompatibel ist?

Mit welchen Kernel-Versionen wäre dieses Setup dann kompatibel?

Hat schon jemand erfolgreich ein Gateway mit Ubuntu 18.04 aufgesetzt?


#119

Zugegeben, es ist nicht ganz einfach aus der commit ID in der git Lognachricht die genauen Kernelversionen zu ersehen, die den Fix haben. Daher hab ich das mal für dich besorgt:
Zu finden ist der Patch in allen Linux Kerneln ab:

  • Für den 3.2 LTS Zweig: 3.2.91
  • Für den 3.16 LTS Zweig: 3.16.46
  • Für den 4.9 LTS Zweig: 4.9.36
  • und alles ab 4.11

Diese Versionen sind inzwischen so alt, dass ich nicht mehr glaube, dass sie in irgendeiner aktuell unterstützten Distribution Anwendung finden.

Wir betreiben erfolgreich Gateways auf Fedora 28 und 29, die jeweils den Kernel 4.18.16 nutzen. Zu Ubuntu kann ich im Speziellen nichts sagen, sehe aber keinen Grund weshalb man damit nicht auch erfolgreich ein Gateway betreiben können sollte.