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]
@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.
Exolon Voncor
Manawyrm | Sarah