Geschichten aus dem Leben eines Admins:

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]

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]

@eXo_X5 ipv6 ist ja auch erst 30 Jahre alt. Muss man im Konzern auch nicht aktivieren …

@eXo_X5 Das klingt wie irgendwas mit IPSEC. Können wir die Schuld auf Cisco schieben?

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.

@martok @eXo_X5 Ich würd an der Stelle ja eher auf kaputte PMTUD tippen, was durch eine verkokste Konfiguration der lokalen Infra versucht wurde zu kaschieren. Normal wenn die MTU nicht passt, bekommt man ne passende Info per ICMP. Hab schon netze erlebt, da stimmte die Fehler-Meldung im ICMP nicht; gab auch sehr spannende Effekte (TLS-Handshakes die random hingen und derlei Spaß). Dass man von den 1500 Bytes MTU ~10% wegschneidet deutet auf mindestens 1-2 Layer VPN oder anderes Tunnel-Zeugs.

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