Tunneldigger IPv6 support

Felix · 13. Oktober 2019 um 20:26

Im Topfschlagen um den IPv6 Support im Tunneldigger konnte ich ein erstes Klirren vernehmen: broker: Allow listening on IPv6 addresses · kaechele/tunneldigger@63182ff · GitHub

Der Durchbruch ist aber eigentlich das hier: broker: Remove NAT logic · kaechele/tunneldigger@9a683d3 · GitHub
Das ist das Kernel-Problem, was eigentlich gar keines ist.

Die o.g. Variante des Tunneldiggers läuft bereits auf einem unserer Gateways ohne Probleme und ohne IPTables NAT regeln, allerdings nur mit IPv4 Clients, da ich die Änderungen am C Client noch nicht fertig umgesetzt habe.
Mit einer ersten Testversion, die nur mit expliziter Angabe des Brokers als IPv6 Adresse funktioniert, kann ich bereits einen IPv6-basierten Tunnel aufbauen und nutzen. Es fehlt das korrekte Dual Stack DNS handling.

Wir sind ganz ganz nah dran.

ralfj · 15. Oktober 2019 um 08:42

Wow, das klingt super.

Aktuell hat tunneldigger, wie du sicher gemerkt hast, ein paar Infrastrukturprobleme – die CI ist kaputt. Das sollten wir IMO lösen bevor wir neue Dinge landen. Ich hoffe ich habe morgen oder an Wochenende mal etwas Zeit dafür. Danach kann ich mir endlich mal deine PRs näher anschauen.

Felix · 15. Oktober 2019 um 14:27

Ich stimme dir zu.
Ich habe da schon mal ein bisschen Debugging geleistet: Die pip/OS Version, die in den Testing Containern verwendet wird ist zu alt um erfolgreich die Python Pakete herunterzuladen. Bei PyPI hat sich einiges getan (z.B. HTTPS enforced und mind. TLSv1.2). Möglich, dass das eingesetzte Ubuntu 14.04 es einfach nicht unterstützt.
Upgraded man die Travis Config auf Xenial oder Bionic dann funktioniert der LXC Kram nicht mehr um die einzelnen Broker und Clients gegeneinander zu testen.
Möglicherweise wäre es an der Zeit das Testing auf etwas wie Vagrant umzubauen.

Nachtrag:
Wie es aktuell steht werde ich wohl zunächst kein Happy Eyeballs implementieren. Heißt: Hat der Knoten eine globale IPv6 Adresse, dann geht Tunneldigger davon aus, dass darüber eine Kommunikation stattfinden kann. Ein gleichzeitiges Testen von IPv4 erfolgt nicht, sodass bei Vorhandensein von IPv6 kein Fallback auf IPv4 erfolgt.

Weiterhin sind durch meine PRs auch mehr Testfälle für die Testmatrix dazugekommen. Mindestens sind das:

Broker auf Python 2 (wobei ich eigentlich gerne ASAP Python 2 komplett droppen will)
Broker auf Python 3
Client auf Dual Stack
Client auf IPv4-only
Client auf IPv6-only

Felix · 17. Oktober 2019 um 05:00

https://github.com/kaechele/tunneldigger/commit/640e2a6849e5be1472d46e184d47a5d5c8664a4b

Damit wäre die Gleichung vollständig.

Ich wäre sehr dankbar wenn sich jemand mit besseren C Skills als den meinen die Sache mal anschaut.
Das ist offen gesagt das komplexeste, was ich bisher in C gemacht habe. Insofern nehme ich gerne Feedback entgegen.

Felix · 17. Oktober 2019 um 20:06

Die o.g. Version funktioniert leider nicht sehr gut in Netzwerken ohne IPv6. Muss ich nochmal ran.

EDIT:
Fixed: client: Implement IPv6 · kaechele/tunneldigger@e0fa525 · GitHub
Jetzt funktioniert alles so, wie ich mir das vorstelle. Nächster Schritt: Gluon Test Build meiner Freifunk Leverkusen Firmware.

anon14684236 · 20. Oktober 2019 um 20:12

Ich finde man sollte in auf dieses IPv6 Tunneldigger ein bischen von diesem Geld drauf werfen,oder zumindest die Zinsen die sich ja ansammeln:

anon68922371 · 20. Oktober 2019 um 20:15

Zinsen hat mir gefallen.

Felix · 21. Oktober 2019 um 14:31

Erfolg!
Auf beiden Endpunkten läuft: client: Implement IPv6 · kaechele/tunneldigger@276772a · GitHub

Knoten: https://map.fflev.de/#!/de/map/a42bb0eeae12

Sat Jul 20 13:15:27 2019 daemon.info td-client: Performing broker selection...
Sat Jul 20 13:15:27 2019 daemon.info td-client: Trying broker gw1.fflev.de on IP 2001:4ba0:fff9:1a7:ff::1
Sat Jul 20 13:15:27 2019 daemon.debug td-client: Broker usage of gw1.fflev.de:10076: 2751
Sat Jul 20 13:15:27 2019 daemon.info td-client: Selected gw1.fflev.de:10076 (IPv6) as the best broker.
Sat Jul 20 13:15:28 2019 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Sat Jul 20 13:15:28 2019 daemon.info td-client: Tunnel successfully established.
Sat Jul 20 13:15:28 2019 daemon.notice netifd: Network device 'mesh-vpn' link is up
Sat Jul 20 13:15:28 2019 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Sat Jul 20 13:15:28 2019 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Sat Jul 20 13:15:29 2019 daemon.notice netifd: Interface 'mesh_vpn' is now up

Server: Freifunk Leverkusen - loading...

Tunnel 160, encap UDP
  From 2001:4ba0:fff9:1a7:ff::1 to 2607:fea8:5df:fe4a:872:bfff:fe67:1ef8
  Peer tunnel 1
  UDP source / dest ports: 10076/37008
  UDP checksum: enabled

Edit:
Zum selber ausprobieren:

Server auf neuen Broker-Code aus dem o.g. Repo updaten
Diesen Patch ins Gluon verzeichnis unter patches/packages/gluon packen.
make update
Gluon neu bauen
???
Profit!

Edit2:
So. Endlich daheim und direkt mal den Router in Natura getestet. Läuft gut!

Edit3:
Zwei bugs hat der code noch:

Wenn ein Broker eingetragen ist, der DNS-seitig NXDOMAIN zurückliefert (also im DNS nicht eingetragen ist) wird in kurzer zeit häufig versucht den Namen erneut aufzulösen, der Client verbindet darauf mit einem IPv4 Broker, egal ob IPv6 auch ginge.
Nach einem Abbruch des Tunnels verbindet der Client mit einem IPv4 Broker.

MPW · 26. Oktober 2019 um 11:26

@Felix, ich bin gerade dabei das mal zu testen.

Bei mir laufen im Syslog mehrere 100 solcher Zeilen pro Sekunde auf:

Oct 26 13:23:48 corny systemd-udevd[7741]: Could not generate persistent MAC address for l2tp9218-9218: No such file or directory
Oct 26 13:23:48 corny kernel: [50642.577497] br04: port 3(l2tp9218-9218) entered blocking state
Oct 26 13:23:48 corny kernel: [50642.577498] br04: port 3(l2tp9218-9218) entered disabled state
Oct 26 13:23:48 corny kernel: [50642.577652] device l2tp9218-9218 entered promiscuous mode
Oct 26 13:23:48 corny kernel: [50642.577824] br04: port 3(l2tp9218-9218) entered blocking state
Oct 26 13:23:48 corny kernel: [50642.577825] br04: port 3(l2tp9218-9218) entered forwarding state
Oct 26 13:23:54 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:54 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (f4f26ddcdc5c) while processing prepare request.
Oct 26 13:23:55 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:55 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (10feedc466c6) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (c46e1f978f3a) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (60e3275a0076) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (c46e1fe80eb2) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (50c7bf7b0f70) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [INFO/tunneldigger.broker] Creating tunnel (18d6c78ff854) with id 9219.
Oct 26 13:23:56 corny python[7644]: [INFO/tunneldigger.tunnel] Set tunnel 9219 MTU to 1364.
Oct 26 13:23:56 corny python[7644]: [INFO/tunneldigger.hooks] Running hook 'session.up' via script '/srv/tunneldigger/broker/scripts/addif_domain04.sh'.
Oct 26 13:23:56 corny systemd-udevd[7821]: Using default interface naming scheme 'v240'.
Oct 26 13:23:56 corny systemd-udevd[7821]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 13:23:56 corny systemd-udevd[7821]: Could not generate persistent MAC address for l2tp9219-9219: No such file or directory
Oct 26 13:23:56 corny python[7644]: [INFO/tunneldigger.broker] Rejecting tunnel (ec086bf7d9a8) due to rate limiting
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (ec086bf7d9a8) while processing prepare request.
Oct 26 13:23:56 corny kernel: [50650.568144] br04: port 4(l2tp9219-9219) entered blocking state
Oct 26 13:23:56 corny kernel: [50650.568146] br04: port 4(l2tp9219-9219) entered disabled state
Oct 26 13:23:56 corny kernel: [50650.568240] device l2tp9219-9219 entered promiscuous mode
Oct 26 13:23:56 corny kernel: [50650.568295] br04: port 4(l2tp9219-9219) entered blocking state
Oct 26 13:23:56 corny kernel: [50650.568296] br04: port 4(l2tp9219-9219) entered forwarding state
Oct 26 13:23:59 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:59 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (c4e9845b1086) while processing prepare request.
Oct 26 13:24:00 corny python[7644]: [INFO/tunneldigger.broker] Creating tunnel (647002aabbac) with id 9220.
Oct 26 13:24:00 corny python[7644]: [INFO/tunneldigger.tunnel] Set tunnel 9220 MTU to 1364.
Oct 26 13:24:00 corny python[7644]: [INFO/tunneldigger.hooks] Running hook 'session.up' via script '/srv/tunneldigger/broker/scripts/addif_domain04.sh'.
Oct 26 13:24:00 corny systemd-udevd[7821]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 13:24:00 corny systemd-udevd[7821]: Could not generate persistent MAC address for l2tp9220-9220: No such file or directory
Oct 26 13:24:00 corny kernel: [50653.797136] br04: port 5(l2tp9220-9220) entered blocking state
Oct 26 13:24:00 corny kernel: [50653.797137] br04: port 5(l2tp9220-9220) entered disabled state
Oct 26 13:24:00 corny kernel: [50653.797298] device l2tp9220-9220 entered promiscuous mode
Oct 26 13:24:00 corny kernel: [50653.797412] br04: port 5(l2tp9220-9220) entered blocking state
Oct 26 13:24:00 corny kernel: [50653.797413] br04: port 5(l2tp9220-9220) entered forwarding state
Oct 26 13:24:01 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:24:01 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (8416f9c89d26) while processing prepare request.
Oct 26 13:24:01 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:24:01 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (98ded03c24ba) while processing prepare request.

Hast du eine Idee, was da schief läuft?

Ich führe deinen TD-IPV6-Zweig mit Python3 aus.

Felix · 26. Oktober 2019 um 12:05

Hast du verwendete Distribution, Kernelversion und Pythonversion für mich?
Wird das Ganze in einem virtualenv ausgeführt?
Dann versuche ich das mal lokal zu reproduzieren.

MPW · 26. Oktober 2019 um 12:14

Siehe Telegramm. Aber hier auch die Details:

root@corny ~ # cat /etc/*release*
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@corny ~ # uname -a
Linux corny 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux
root@corny ~ # python3 --version
Python 3.7.3

Ja, wird im virtualenv ausgeführt. In dem virtualenv was per apt von Debian 10 kommt.

root@corny ~ # virtualenv --version
15.1.0

MPW · 26. Oktober 2019 um 12:40

@Felix, wir stellen uns gerade die Frage, ob wir vllt. etwas falsch gemacht haben: Läuft der neue Broker von dir mit dem alten Client auf den Knoten?

Soweit ich dich verstanden habe, müsste das erstmal gehen. Nur um Missverständnisse auszuschließen.

PS: Ich habe gerade mal ein bisschen Statistiken angeschaut.

Ich habe hier 120 verbundene Knoten mit altem Client und neuem Broker. Das scheint also erstmal zu laufen. Da gehen auch gut 100 Mbit/s durch.

Allerdings habe ich über 375 verschiedene Mac-Adressen die obigen Fehler verursachen.

Felix · 26. Oktober 2019 um 12:55

Ja, so betreibe ich es in Leverkusen. Ich hab nur 3 Knoten auf dem neuen Client.

Danke für’s Testen, den Fehler hab ich bei uns noch nicht gesehen. Vielleicht liegt es an unterschiedlichen Kernelversionen (wir verwenden 5.3). Ich gehe da mal investigativ vor.

MPW · 26. Oktober 2019 um 14:52

Gerade mal mit dem Kernel 5.2 aus den Debian-Backports getestet. Da scheint das Problem nicht aufzutreten.

Wir haben jetzt nur noch alte Gluons ohne gepatchten Tunneldigger, die das Session-ID-Problem haben. Aber das soll mir egal sein, wenn die Leute ihre Knoten nicht aktualisieren.

MPW · 26. Oktober 2019 um 16:46

PS: Für mich brauchst du da keine Zeit reinstecken. Wie nehmen einfach den aktuellen Kernel und jut is.

MPW · 26. Oktober 2019 um 20:37

@Felix, nachdem ich erst vergessen hatte V6 auf den Knoten zu schalten, geht es jetzt leider trotzdem nicht:

root@ffmsd04-tdv6:/# /etc/init.d/tunneldigger start
Not starting tunneldigger - missing uuid
Starting tunneldigger on mesh-vpn
root@ffmsd04-tdv6:/# logread -f
Sat Oct 26 22:34:00 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:34:05 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:34:06 2019 daemon.info td-client: Trying broker [2a01:4f8:191:8224::56] on IP 2a01:4f8:191:8224::56
Sat Oct 26 22:34:16 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:34:21 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:34:22 2019 daemon.info td-client: Trying broker [2a01:4f8:191:8224::56] on IP 2a01:4f8:191:8224::56
Sat Oct 26 22:34:32 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:34:37 2019 daemon.info td-client: Performing broker selection...
^Croot@ffmsd04-tdv6:/# ping6 2a01:4f8:191:8224::56
PING 2a01:4f8:191:8224::56 (2a01:4f8:191:8224::56): 56 data bytes
64 bytes from 2a01:4f8:191:8224::56: seq=0 ttl=59 time=0.619 ms
64 bytes from 2a01:4f8:191:8224::56: seq=1 ttl=59 time=0.390 ms
^C
--- 2a01:4f8:191:8224::56 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.390/0.504/0.619 ms
root@ffmsd04-tdv6:/# uci show|grep address
tunneldigger.mesh_vpn.address='[2a01:4f8:191:8224::56]:20004'

Ping zum Gateway geht. Aber der baut den Tunnel nicht auf.

Hat vllt. der Patch nicht geklappt? Kann ich irgendwie abfragen, ob ich wirklich die gepatchte Version eingebaut habe?

Ist ein x86-Gluon.

PS: Auch mit DNS geht es nicht.

Sat Oct 26 22:39:03 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:39:03 2019 daemon.info td-client: Trying broker ipv6-td.servers.ffmsl.de on IP 2a01:4f8:191:8224::56
Sat Oct 26 22:39:14 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:39:19 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:39:20 2019 daemon.info td-client: Trying broker ipv6-td.servers.ffmsl.de on IP 2a01:4f8:191:8224::56
Sat Oct 26 22:39:30 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:39:35 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:39:36 2019 daemon.info td-client: Trying broker ipv6-td.servers.ffmsl.de on IP 2a01:4f8:191:8224::56

PPS: Da sich ein definitiv ungepatchtes, altes Gluon wie folgt verhält, denke ich schon, dass ich den Patch korrekt angewendet habe.

Fri Oct 25 16:28:19 2019 daemon.info td-client: Tunnel successfully established.
Sat Oct 26 22:46:10 2019 daemon.warn td-client: Got termination signal, shutting down tunnel...
Sat Oct 26 22:46:11 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:46:11 2019 daemon.err td-client: Failed to resolve hostname '[2a01'.
Sat Oct 26 22:46:27 2019 daemon.info td-client: Reinitializing tunnel context.
Sat Oct 26 22:46:27 2019 daemon.err td-client: Failed to resolve hostname '[2a01'.
Sat Oct 26 22:46:32 2019 daemon.info td-client: Selected [2a01:4f8:191:8224::56]:20004 as the best broker.
Sat Oct 26 22:46:33 2019 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!

Felix · 26. Oktober 2019 um 22:06

Am Tunneldigger Broker entsprechend auch die Konfiguration angepasst damit der auch auf der IPv6 lauscht?

MPW · 26. Oktober 2019 um 22:19

Ähm ja, da sagst du was. Ich hatte das in der Beispielkonfig gesehen aber verpeilt, dass wir natürlich unsere eigene Konfig per Ansible auf die Gateways schieben.

Sun Oct 27 00:16:14 2019 daemon.info td-client: Selected ipv6-td.servers.ffmsl.de:20004 (IPv6) as the best broker.
Sun Oct 27 00:16:14 2019 daemon.info td-client: Tunnel successfully established.

Felix · 26. Oktober 2019 um 22:22

Interessant. Dann müsste man mal triangulieren bei welcher Kernelversion man Einsteigen kann ins IPv6-Vergnügen.

Vielen Dank für’s Testen!

MPW · 26. Oktober 2019 um 22:23

Vielen Dank dir für’s Bauen. Denke das wird recht schnell produktiv gehen hier bei uns.

Wir sollten uns noch die letzten zwei Bugs angucken und dann ab ins Gluon damit…