Könnte es sein, dass die config
[log]
; Log filename
filename=tunneldigger-broker.log
nicht mehr dazu führt, dass logfiles produziert werden?
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.
1 „Gefällt mir“
Gute Idee, den Changelog mal zu aktualisieren. 
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?
Das Changelog-Update kommt unter
@adorfer ist das hilfreich? Der FFRL-Fork ist etwa auf Stand von v0.1.0.
Danke!
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.
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?
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 
EDIT2: Aha, der Anchor verbirgt sich nur im grauen github.com Link.
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‘.
2 „Gefällt mir“
Das sieht doch gut aus 
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?
1 „Gefällt mir“
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?
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.
2 „Gefällt mir“
Nimm den neusten Tunneldigger (Server und Client). Dann ist die Kernelversion egal, alt und neu wird alles unterstützt.
Der Tunneldigger-Client ist seit Gluon 2017.1.5 neu genug.
2 „Gefällt mir“
Bei der Vorbereitung der Migration stolpere ich grade über komische Effekte: Grundidee ist es, die br-mesh der fastd+v14- und tunneldigger+v15-Teilnetze per L2TP-Tunnel zu verbinden (oder VXLAN oder $l33tsh1t); das „alte“ Netz bekommt eine Hälfte des /20, das neue die andere, v6 geht wg. SLAAC kunterbunt durcheinander. Kopplung via Layer 2, alles schick, tut auch soweit. Problem 1:
Wohl weil der dhcpd auf br-mesh hängt, und br-mesh auf beiden Gateways (v14, v15) per l2tp-Tunnel gebridged sind, greift die batman-adv-interne Filterung nicht, jedenfalles landen DHCP-Anfragen aus dem v14-Netzsegment auch beim v15-dhcpd, der brav antwortet, was bißchen doof ist (Cross-Gateway-Traffic). ebtables to the rescue, jeweils:
ebtables -I FORWARD -o L2TPToOtherSide -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
ebtables -I OUTPUT -o L2TPToOtherSide -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
ebtables -I INPUT -i L2TPToOtherSide -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
Und auf beiden Seiten kommen nun keine DHCP-Pakete an.
Während Clients die neue Geschwindigkeit wohlwollend konsumieren, bleibt noch ein Wermutstropfen: Direkt am Gateway hängenden Knoten kann ich i. d. R. nicht per IP erreichen, wohl aber per Flattervogel 
root@l2tp-gut02:~# ping6 -c 10 2001:bf7:1310:11:c6e9:84ff:fef9:a823
PING 2001:bf7:1310:11:c6e9:84ff:fef9:a823(2001:bf7:1310:11:c6e9:84ff:fef9:a823) 56 data bytes
From 2001:bf7:1310:11::12:2 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=3 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=4 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=5 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=6 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=7 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=8 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=9 Destination unreachable: Address unreachable
From 2001:bf7:1310:11::12:2 icmp_seq=10 Destination unreachable: Address unreachable
--- 2001:bf7:1310:11:c6e9:84ff:fef9:a823 ping statistics ---
10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 8999ms
root@l2tp-gut02:~# batctl-ffgt tr c4:e9:84:f9:a8:23
traceroute to c4:e9:84:f9:a8:23 (46:c6:64:6b:a4:db), 50 hops max, 20 byte packets
1: 46:c6:64:6b:a4:db 15.749 ms 17.958 ms 15.979 ms
Wo ist mein Denkfehler?
Ist irgendwas aktiv, das reverse path filtering für IPv6 implementiert? firewalld auf Fedora/RedHat macht das zum Beispiel. Ist das aktiv geht nüscht.
Nope, Ubuntu 16.04, kein firewalld. ipXtables sehen auch leer aus. Aber mir schwant was:
Die tunneldigger-Bridge ist wie hier dokumentiert aufgesetzt, also mit post-up ebtables -A FORWARD --logical-in $IFACE -j DROP, um die Clients auf der Ebene von einander zu isolieren. Konkret habe ich das so verknotet:
root@l2tp-gut02:~# brctl show
bridge name bridge id STP enabled interfaces
br-ffgt 8000.7aff4cf41620 no Egwgut01
bat-ffgt
br-tdig 8000.1abeef000001 no l2tp101-101
l2tp103-103
l2tp104-104
root@l2tp-gut02:~# batctl-ffgt if
br-tdig: active
root@l2tp-gut02:~#
In br-ffgt auf dem L2TP-GW (batman-adv v15) hängt also »das Mesh«, bestehend einerseits aus dem L2TP-Traffic, der via bat-ffgt durch Batman ankommt, sowie »einem virtuellen Kabel« von dieser in die br-ffgt des fastd-Gateways (batman-adv v14). Dort sieht es so aus:
root@gw-gut01:~# brctl show
bridge name bridge id STP enabled interfaces
br-ffgt 8000.224e235ae543 no El2tpgut02
bat-ffgt
root@gw-gut01:~# batctl-ffgt if
Etmpstats: active
Etmp00: active
Etmpgw01: active
ens8: active
ens7: active
ens9: active
ens10: active
ffgt-mesh-vpn: active
ens7 bis ens9 hier sind hostseitige Bridges: die fastd laufen auf dem Blech und werden per Bridge in die VM geholt. ffgt-mesh-vpn ist der fastd in der VM, der nicht genutzt wird (Automatisierungsartefakt: »ein Gateway kommt immer mit genau einem lokalem fastd« war das Credo 2015/16). Die anderen Exxx sind »virtuelle Kabel« (L2TP) zu anderen VMs. Das alles läuft auf batman-adv Kompatibilitätslevel V14.
Kurzum: ich habe auf Ethernet-Ebene also die beiden br-ffgt auf zwei VMs zu einem Netz verbunden. Geht nur auf der Ebene, da »links« batman-adv mit Kompatibilitätslevel v14, »rechts« mit V15: koppeln kann ich da nur außerhalb von batman-adv.
Ich vermute mal, daß durch den ebtables-Eintrag kein »normaler« Datenverkehr mit »außen« funktioniert, der wird auf Layer2 in der Tunneldigger-Bridge (br-tdig bei mir, da Interfacenamen >8 Zeichen »unhandlich« sind) blockiert. Das v14-Mesh kommt aber über Bridging und nicht batman-adv rein, aus die Maus?
Was ich aber dann wiederum nicht verstehe: von einem Endgerät an einem L2TP-v15-Knoten kann ich die Statusseiten sowohl der anderen (derzeit 3) v15-Knoten aufrufen als auch jene von v14-Knoten. Genau das klappt „von der anderen Seite“ nämlich nicht, dort sind nur v14-Knoten erreichbar.
»Lustig« ist auch, daß v14 und v15 Knoten (per 802.11s) meshen — das ist aber nur eine Fata Morgana, oder? Die bekommen keinen Datentransfer zustande?
Funfact: Der Kernel akzeptiert ab 5.5.3 wieder überlappende Session IDs, sofern UDP als Transport genutzt wird (was bei Tunneldigger der fall ist):
commit 0d0d9a388a858e271bb70e71e99e7fe2a6fd6f64
Author: Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz>
Date: Tue Feb 4 12:24:00 2020 +1300
l2tp: Allow duplicate session creation with UDP
In the past it was possible to create multiple L2TPv3 sessions with the
same session id as long as the sessions belonged to different tunnels.
The resulting sessions had issues when used with IP encapsulated tunnels,
but worked fine with UDP encapsulated ones. Some applications began to
rely on this behaviour to avoid having to negotiate unique session ids.
Some time ago a change was made to require session ids to be unique across
all tunnels, breaking the applications making use of this "feature".
This change relaxes the duplicate session id check to allow duplicates
if both of the colliding sessions belong to UDP encapsulated tunnels.
Fixes: dbdbc73b4478 ("l2tp: fix duplicate session creation")
Signed-off-by: Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz>
Acked-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1 „Gefällt mir“
