@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.

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.

Jetzt frage ich mich, ob ich ein Issue aufmachen sollte, oder ob das gar ein Bugreport wert ist?

Wie auch immer - #wifi MTU 1350 in der #bahn ?
Was habt ihr denn geraucht?

Das Debuggen hat übrigens die ganze Fahrt gedauert.

[6]

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]

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]

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]

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]

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]