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.


#120

Nimm den neusten Tunneldigger (Server und Client). Dann ist die Kernelversion egal, alt und neu wird alles unterstützt. :slight_smile:

Der Tunneldigger-Client ist seit Gluon 2017.1.5 neu genug.


#121

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 :frowning:

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?


#122

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.


#123

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?