Tunneldigger und IPv6 — Status 2022?

Fortsetzung der Diskussion von Tunneldigger updates - Ihr Handeln ist erforderlich!:

I’ve lost track, I admit. Dennoch, wie ist denn der aktuelle Status bzgl. Tunneldigger (in Gluon) und IPv6?

Ist zwar nicht ganz das Thema aber fastd kann ab v22 auch L2TPv3. Funktioniert mit IPv4 und IPv6.

https://fastd.readthedocs.io/en/stable/releases/v22.html

Ich hab das mal bei mir auf einem 842v3 getestet und die Ergebnisse können sich sehen lassen.

Genau … WireGuard kann auch mit IPv6 umgehen, L2TP ebenso, OpenVPN auch, …

Die Frage wurde schon gezielt so gestellt, wie sie gestellt wurde; ich möchte nicht schon wieder die Infrastruktur ändern, wenn vermeidbar — zumal dann 90% der Bestandsgeräte rausfallen (4/16-Thema aka »841er«). Falls unvermeidbar (Mobilfunk- als auch DSL-Zugänge in D werden mehr und mehr v6-mainly (mit Alibi-v4-Adresse 192.0.0.4)), würde es dann wohl vxlan-in-wg werden.

 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.666.1                                         0.737ms 
 1:  192.168.666.1                                         0.790ms 
 2:  192.0.0.2                                             1.183ms pmtu 1452
 2:  192.0.0.1                                             5.655ms 
 3:  i66F666F6.versanet.de                                 8.397ms
1 „Gefällt mir“

Der vorbereitende Schritt (entfernen der kruden NAT-hacks) ist getan und bei uns seit geraumer Zeit in Produktion.

Für den eigentlichen IPv6-Support hat sich jedoch seit diesem Draft nichts mehr getan. Siehe auch diesen Issue. Ich habe das auch selber nicht auf der TODO-Liste, helfe aber gerne beim Begutachten von PRs.

1 „Gefällt mir“

Ich hab mir das ganze Thema seit Ewigkeiten nicht mehr angeschaut.
Ich arbeite außerdem gerade an einem Testsetup für fastd v22 mit L2TPv3 in unserem Netzwerk. Die Gluon Doku zu fastd mit L2TPv3 stammt in großen Teilen von mir. Ich vermute mal, dass ich das Thema Tunneldigger IPv6 also nicht unbedingt nochmal aufnehmen werde.

Mein letzter Stand zu meinem damaligen Pull Request: Funktioniert soweit, ich hatte glaube ich nur einen Fehler bei der MTU Berechnung im Client Code gemacht, der dazu führte dass auf manchen Leitungen ein paar Verbindungen nicht klappten.
Wir hatten meinen IPv6 Code sogar kurzzeitig in Produktion.

Die größte Schwierigkeit (die hauptsächlich damit zu erklären ist, dass ich ein lausiger C Programmierer bin) war aus meiner Sicht die Implementierung von Happy Eyeballs, sodass stets die Verbindung zustande kommt, die am zackigsten aufgebaut werden kann. So wie es aktuell ist verbindet sich der Client nach und nach mit den in der DNS Auflösung vorhandenen Replies, die je nach Betriebssystem unterschiedlich geordnet sein können. Somit ist der Verbindungsaufbau nicht wirklich strukturiert gemäß Bevorzugung irgendeines Protokolls.

Helfe gerne, falls jemand sich entscheidet die Arbeit wieder aufzunehmen.

Danke für die klaren Worte. Damit ist aus meiner Sicht Tunneldigger als Transport EOL’d; so long and thanks for all the traffic served.

Ich fühle mich natürlich geschmeichelt, dass du die Zukunft des Tunneldiggers an meinem Involvement festmachst. Ich bin aber was Contributions angeht da eher ein kleiner Fisch gewesen :wink:
Kann ja sein, dass sich das nochmal jemand zu Gemüte führt.

Allerdings ist fastd als L2TPv3 broker aus meiner Sicht etwas einfacher zu handhaben (und zusammen mit systemd-networkd echt unschlagbar, dank dem batman-adv support von @awlnx und anderen (:bouquet:))
Gatewayseitig ist das fast schon ein drop-in replacement. Clientseitig ist natürlich ein Firmware Update fällig. Man kann Tunneldigger und fastd mit L2TP sogar parallel betreiben, falls notwendig.
fastd kann außerdem auch die Verbindungen authentifizieren, sodass das Aussperren von Knoten im Fehler/Missbrauchsfall wieder etwas besser klappt.

Du bist ja nicht der Erste, der kein gesteigertes Interesse an Tunneldigger & IPv6 zeigt:

Ist ja auch ok, ggf. muß man mit der MTU einfach weiter runter, um mit getunneltem IPv4 klarzukommen.

fastd ist verbrannte Erde, fastd war der Bremsklotz, den L2TP mit Hilfe von Tunneldigger entfernte — der Drops ist PR-mäßig gelutscht, I won’t touch this. Bis auf weiteres tut Tunneldigger ja, IIRC hatten wir eine MTU gewählt, die für Unitymedia-AFTR-v4 paßte, und das, was 1&1 derzeit macht, scheint nicht mehr Overhead zu produzieren.

Und jüngst wurde gerade wieder eine v4-only-Glasfaser bereitgestellt (Stadtwerke-ISP) – moar incomimg –, vielleicht wird IPv6 doch überbewertet :wink:

Das ist natürlich schade, dass du das so siehst.
Ich denke technische Argumente werden für dich in dieser Situation belanglos sein. Aber ich habe meine Gedanken dazu dennoch mal niedergeschrieben, für die, die es möglicherweise interessieren könnte:

fastd v22 macht mit der null@l2tp method und konfigurierter offload Option exakt das selbe wie Tunneldigger (per Netlink L2TPv3 Interfaces konfigurieren). D.h. Transport komplett im Kernelspace.
Gluonseitig wird das ebenso (d.h. per Kernel L2TPv3 Treiber) umgesetzt, wenn null@l2tp zum Einsatz kommt. Im Ergebnis hast du damit die selbe Performance wie bei Tunneldigger Setups.
Nur kannst du bei fastd wie gewohnt mit peers und keys arbeiten (muss natürlich nicht, ein on verify "true"; tut’s natürlich auch) und komplett transparent auch verschlüsselte Methoden anbieten für die, die ihren 841 eher gemächlich aber verschlüsselt mögen.
All das natürlich auch per IPv6. Und ich denke IPv6 kann im Zeitalter verstopfter AFTR (Wortwitz nicht beabsichtigt) durchaus eine Verbesserung darstellen.

Siehe auch die VPN Doku des Gluon master branch: Mesh VPN — Gluon 2023.1.1 documentation

6 „Gefällt mir“

Danke, aber das ändert nichts an der eher ungewissen Zukunft von Tunneldigger, und darauf zielte die Frage ja ab.

Aber für ein Netz, daß sich vor n Jahren mühsam von fastd gelöst hat, ist der Rückwechsel zu fastd als v6-taugliches Frontend für L2TPv3 doch weder technisch noch strategisch so richtig zielführend. Wireguard macht verschlüsselte L3-Verbindungen mit näherungsweise der Geschwindigkeit von unverschlüsselten L2TP-Tunneln möglich, warum dann also, wenn man schon den Transportlayer tauschen muß, nicht gleich auf ein moderneres Setup setzen? (Wer bei fastd geblieben ist, kann nun natürlich diese Ernte billig einfahren :-))

Wobei für mich die Frage war, ob ich in diesen sauren Apfel beißen muß — und danach sieht es derzeit ja aus.

Wir nutzen nach wie vor Tunneldigger und haben aktuell auch keine Pläne, das zu ändern. Ich bin zuversichtlich dass ich Tunneldigger so weit maintainen kann dass das auch weiterhin geht. Allerdings sehe ich bisher nicht den Leidensdruck, IPv6-Support einzubauen.

1 „Gefällt mir“

Ich sehe das etwas anders. Beim Wechsel von Tunneldigger auf fastd mit L2TPv3 wechselt man nur das VPN Client/Broker-Gespann. Bei der Einführung von Wireguard hast du einen größeren Wechsel im Backend zu stemmen, da VXLAN als weiterer Layer hinzukommt.

Ein Wechsel von Tunneldigger auf fastd ist mit 2-3 Änderungen am Backend und einem Gluon Update erledigt.

Die Packages für alle Varianten – fastd, L2TP mit Hilfe von Tunneldigger, VXLAN-über-Wireguard-plus-Broker – existieren ja. Und VXLAN wurde ja gerade gewählt, weil es in Gluon sowieso schon vorgesehen ist — zwischen Knoten zumindest. (Nicht auf meinem Mist gewachsen.)

Was bleibt – bei einem Wechsel weg von Tunneldigger egal wohin –, ist ein inkompatibler Change, wodurch alte Knoten keine akuellen Gateways mehr ansprechen können — also abgehängt werden, wenn es für sie keine Firmware mehr gibt (4/32). Und wenn ich diesen Schritt gehen muß, dann für den größtmöglichen Nutzen. Policy: KISS. Damit fallen Ansätze mit dualen Protokollen raus. Aber wie gesagt, vermutlich reicht die aktuell gewählte MTU von 1364 noch lange …

1 „Gefällt mir“