Geschichten aus dem Leben eines Admins:
Ich saß gestern in einem erfreulich gering besetzen IC der #bahn von Berlin nach Magdeburg.
Um mir die Zeit zu vertreiben, wollte ich über das Bahn #wifi an ein paar Geräten rumspielen.
Mangels eigener Adressen, sind diese über IPv4 nur mit mehreren #ssh hops zu erreichen. IPv6 gibt es im Bahn wifi nicht.
Ist ja kein Problem, dachte ich mir, dazu habe ich ja mein #wireguard #vpn mit IPv6.
Und damit beginnt unsere Geschichte:
[1]
Als ich also wie gewohnt "wg-quick up wg1" eintipperte, sah ich, dass der Verbindungsaufbau bei dem Versuch den default Gateway für IPv6 zu setzen scheiterte. Die Verbindung wurde komplett wieder abgebaut.
Die Route aus der Konfiguration heraus zu lassen funktionierte, allerdings hatte das Interface dann gar keine IPv6 Adresse. Nutzlos.
Nach einigem Rätseln habe ich dann jeden Schritt den wq-quick machte einzeln selbst ausgeführt.
Merkwürdig war dabei, dass ich zwar das Interface …
[2]
mit allen Adressen konfigurieren konnte, aber sobald ich im Nächten Schritt "ip link set up" machen wollte, verschwand die IPv6 Adresse einfach wieder und ließ sich daraufhin auch nicht mehr neu setzen.
Auch das Interface erst hoch zu bringen und dann Adressen dran zu hängen funktionierte nur für IPv4.
Ohne eigene IPv6 Adresse konnte natürlich später auch kein Gateway konfiguriert werden.
Das war allerdings der erste Schritt, der tatsächlich zu einem Fehler führte.
Was nun?
[3]
Ich muss gestehen, dass ich an dieser Stelle ChatGPT gefragt habe, wo auch tatsächlich die richtige Antwort raus fiel.
wg-quick fährt nämlich nicht nur das Interface hoch, sondern setzt dabei auch noch eine passende MTU um Fragmentierung zu verhindern.
Die Bahn hat in ihrem wifi das Netz aber so seltsam konfiguriert, dass schon das wifi Interface nur eine MTU von 1350 hat.
Zieht man jetzt hier noch die 80 Byte WG overhead ab, bleiben dem WG Interface nur noch 1270 Byte MTU.
[4]
Hausaufgabe: Setzt ma unter #linux bei einem beliebigen Interface mit einer IPv6 Konfiguration die MTU auf 1270!
Ihr werdet Zeuge, wie sämtliche IPv6 Einträge einfach verschwinden.
IPv6 ist für eine MTU unter 1280 nicht spezifiziert.
Kann man wissen, ich wusste es nicht.
Wäre cool wenn wg-quick bei einer berechneten MTU unter 1280 entweder einen brauchbaren Fehler werfen würde, oder 1280 als Minimum setzt, wenn IPv6 konfiguriert wurde.
Besser gelegentliche Fragmentierung, als kein IPv6.
[5]
Also nur zur Klärung:
Bugreport natürlich an wireguard, weil die kleine MTU ohne brauchbaren Fehler den Start kaputt macht.
Der Bugreport an die Bahn wäre ein Anderer: Bitte keine staatliche Infrastruktur privatisieren.
Aber der kommt wohl zu spät.
@martok Wieso erinnert mich das gerade an die Geschichte, wo sie eigenmächtig in plain HTTP einige für mich wichtige Header raus gefiltert haben?
Ich möchte gar nicht wissen, was die Bahn da noch so mit dem Datenverkehr macht, was erfordert so ein "schady" Routing mit Verkapselung in was weiß ich da zu betreiben.
@eXo_X5
Passt aber:
Die Bahn kann ja auch nicht zaubern und muss als Internetzugang normale LTE-SIM-Karten benutzen, wie jeder andere auch.
D.h. die haben dann (von einem externen Unternehmen zugekauft) eine Kiste, die mehrere VPN-Tunnel über ne Reihe an Mobilfunkmodems aufmacht -- aber jeder dieser Tunnel kostet wieder MTU.
150 Byte (!) Headeroverhead finde ich auch komplett absurd, zum Vergleich, mit Wireguard fängt man sich (mit v4 außen) nur 60 Bytes Overhead ein.
@manawyrm ja Moment. So macht das ja noch weniger Sinn.
Wenn WG bei IPv4 nur 60 byte overhead hat, wieso hat wg-quick dann bei der Berechnung der MTU 80 abgezogen?
Mit 60 Wäre ich ja über den 1280 geblieben - und das wäre alles nicht passiert.
@eXo_X5 weil wg-quick nicht weiß, welches Protokoll "außen" genutzt wird.
erst WG selbst löst den DNS-Namen deines Endpoints auf und weiß dann, ob es v4 oder v6 ist.
Du hättest das Teil händisch auf v4 forcen und die MTU händisch hochstellen können.
@manawyrm Hab ich ja dann auch gemacht.
Allerdings ohne zu wissen, dass ich mir mit der 1280er MTU nicht mal Fragmentierung eingefangen hätte, weil wg-quick die MTU so defensiv setzt und bei IPv4 eigentlich 20 bytes mehr bleiben.
Danke, dass du mich da noch mal mit der Nase drauf drückst.
@manawyrm oh, hab ich auf den ersten Blick gar nicht richtig gelesen.
Der Endpoint ist eine statische IPv4 Adresse. Es ist also kein DNS beteiligt.
Keine Ahnung ob das einen Unterschied macht - aber wenn man denn wollte, könnte man ja auch erst DNS auflösen und den Adresstyp berücksichtigen.
Äh, ja. Es gibt bei der MTU und der Fragmentierung einen zentralen Unterschied:
Bei IPv4 gibt es garkeine (oder nur eine sehr niedrige) Mindest-MTU. Falls Pakete zu groß sind, dürfen IPv4-Router für die nötige Fragmentierung sorgen, indem sie Pakete unterwegs aufteilen und dann in mehreren Teilen auf die Reise schicken. Dieser Mechanismus hört sich in der Theorie einfach an, ist aber für DOS-Angriffe anfällig und wurde deshalb für IPv6 nicht übernommen.
Bei IPv6 ist es die
(1/4) @eXo_X5
Aufgabe des Absenders, die technisch mögliche Pfad-MTU zu ermitteln und dann dafür zu sorgen, dass die Pakete auch die richtige Größe haben. Zu große Pakete gehen zurück an den Absender (zumindest in der Theorie; In der Praxis gibt es fehlerhaft programmierte Router, die solche Pakete verschlucken).
Lt. RFC 2460 muss jeder Netzwerklink, der für IPv6 genutzt wird, eine Mindest-MTU von 1280 haben, damit niemand das Netz mit extra niedrigen MTUs durcheinanderbringt. Allerdings wird
(2/4) @eXo_X5
empfohlen, dass man nach Möglichkeit eine MTU von mindestens 1500 nimmt, damit bei VPN-Verbindungen noch genügend Reserve für den VPN-Header ist.
Was passiert nun aber, wenn man in einer VPN-Verbindung die MTU von 1280 nicht realisieren kann?
Die IPv6-eigene Fragmentierung kann man in diesem Fall nicht nutzen, weil ja eine Mindest-MTU von 1280 vorhanden sein muss.
Die Antwort lautet schlichtweg, dass die Fragmentierung in diesem Fall auf der Ebene des VPN-Protokolls erfolgen
(3/4) @eXo_X5
muss. D. h. Wireguard müsste die zu großen Pakete aufteilen, in mehreren Teilen durch den Tunnel schicken und am Ende des Tunnels müssten sie wieder zusammengesetzt werden. Für die IP-Schicht im Tunnel muss dieser Prozess transparent sein.
ICh weiß nicht, welche VPN-Protokolle diese Fragmentierung-im-Tunnel-Verrenkung können. Fakt ist: Wenn der Tunnel es nicht kann, hast du in dem Fall verloren.
(4/4) @eXo_X5
@hallunke23 Wow, danke dass du dich da noch mal so rein hängst.
In meinem Fall ist das tatsächlich alles halb so wild - bis eben auf den von mir beschriebenen Fehler beim Setup.
In diesem Fall war ja das transportierenden Protokoll IPv4. Damit kann ich also eine absurd kleine MTU am Wifi Interface konfigurieren und die MTU des Wireguard Iface auf 1280 stellen.
Im Wifi ist das halt nur UDP, was bei Bedarf fragmentiert wird. Keine große Sache. WG muss da an den Paketen nichts machen.
Christoph
Exolon Voncor
M. Vorsprach
Martok
BenBE
Manawyrm | Sarah
waldi
ㅤㅤ F09f988e
adingbatponder 
👾
hallunke23 🇺🇦