Technik

In letzter Zeit schüttel ich irgendwie regelmäßig den Kopf wenn ich mit OpenVPN zu tun habe, bzw. frage ich mich wie die Standardeinstellungen ohne Probleme funktionieren sollen.

Das TUN/TAP-Device für den VPN-Tunnel wird per default mit einer MTU von 1500 Byte konfiguriert, womit für die VPN-Verbindung die bei OpenVPN typischerweise auf UDP basiert eine maximale Nutzdaten-Größe von eben diesen 1500 Bytes entsteht. Addiert man hierauf nun den Overhead von UDP, IP und Ethernet oder PPP, landet man typischerweise weit über der MTU der eigentlichen Internet-Verbindung und Datenpakete werden verworfen.

Eine Abhilfe würde die Verwendung von einer TCP-basierten Verbindung schaffen - mit unserem VPN Gateway ist immerhin beides möglich. Hier würden die Nutzdaten fragmentiert und entsprechend der maximalen MTU auf dem Weg zum VPN-Server übertragen. Allerdings ist TCP im Vergleich zu UDP nicht optimal für VPN-Verbindungen geeignet - um es zu veranschaulichen: Eine VPN-Verbindung ist eine Art "virtuelles Kabel", das dementsprechend auch die Eigenschaften wie ein reales Kabel haben sollte. Dazu gehört auch die Eigenschaft Pakete zu verlieren. UDP schickt die Daten einfach so raus und achte nicht auf Reihenfolge oder ob diese auch ihr Ziel erreichen, TCP hingegen sorgt dafür, dass die Nutzdaten immer in Reihenfolge und auch komplett ihr Ziel erreichen - das ist auch gut, solange das "Kabel" nicht ohnehin schon dafür sorgt. Ohne nun noch weiter in die Tiefe zu gehen: Eine VPN-Verbindung über TCP zu tunneln ist Mist und eigentlich nur für den Notfall bzw. wenn es nicht anders geht eine Option.

Man kann nun nicht behaupten, OpenVPN hätte hier nicht vorgesorgt, im Gegenteil: OpenVPN kennt die Konfigurations-Parameter "tun-mtu" und "link-mtu". Beide definieren einen MTU-Wert, der sich auf das TUN/TAP-Device auswirkt. tun-mtu tust das für das TUN/TAP-Device direkt, wohingegen link-mtu den Paket-Overhead für den Transport über das Netzwerk abzieht und die MTU des TUN/TAP-Device entsprechend setzt.

Nun wird OpenVPN mit "tun-mtu" voreingestellt auf 1500 ausgeliefert, was zu dem eingangs erwähnten Problem führt. Sinnvoller wäre es eigentlich "link-mtu" mit diesem Wert zu versehen. Wenn man dann aber noch die weite Verbreitung von DSL-Zugängen auf Basis von PPPoE berücksichtigt, sollte dieser Wert noch kleiner ausfallen, mindestens 8 Byte.

Nun hocke ich aber nicht immer in Stuttgart im Büro, sondern fahre oft auch durchs Land, sodass ich schon so einige fremde Netzwerke, Hotspots oder UMTS-Verbindungen gesehen habe. In Konsequenz haben wir uns nun dazu entschlossen unseren VPN Gateway mit einer link-mtu von 1400 zu betreiben. Zwar sorgen die 100 Byte weniger, dass mehr Frames generiert werden müssen, doch habe ich persönlich die Erfahrung gemacht, dass es so weitaus seltener zu Verbindungsproblemen kommt - besonders bei SSL-Handshakes.

Zu Migrationsproblemen kommt es hierbei nicht, da ja nur die Menge der zu senden Daten herab gesenkt wird. Solange die dann ihr Ziel erreichen, werden sie dort auch akzeptiert - an einem MRU-Schalter wird in der Regel nicht gedreht.

Eigentlich bin ich ja ein Fan von RFCs, denn Sie beschreiben irgendeine Technik für jedermann mehr oder minder verständlich und meistens recht eindeutig, sodass schlussendlich auch jeder seine eigene Software darauf aufbauen kann und die Interoparabilität gesichert ist. Da ist es eigentlich ein Krampf, wenn irgendwelche Unternehmen oder Entwickler hingehen und irgendetwas abweichend von einem RFC tun.

Heute möchte ich mich in die Reihe der RFC-abweichler einreihen - aber nur optional und aufgrund eines expliziten Kundenwunsches. Der Ausgangspunkt war eine Joomla-Installation eines Kunden, die stets URLs wie www.domain-des-kunden.de//images/unterverzeichnis/bild.jpg generierte. Auf den ersten Blick ist hier vielleicht nichts falsch, höchstens das "//" wirkt optisch unschön.

Doch falsch gedacht! Ein "//" am Anfang eines Pfades auf einer Domain ist in RFC 2396 Abschnitt 3.2 als "Authority Component" definiert, dementsprechend schneidet ein Webserver (der RFC-konform arbeitet) "//images" von der Adresse ab und wertet es als Authentifizierungs-Informationen aus. Wäre mir das nicht schon mal in Verbindung mit Subversion passiert, würde ich das vermutlich gar nicht wissen und ich kenne auch niemanden, der diese Regel spontan parat hätte.

Somit ist das Ergebnis dieser URL stets nicht das jenige, welches man erwarten würde. Da der Kunde auch recht wenig Interesse hatte in Joomla den Fehler zu suchen und dort wegzupatchen, habe ich - eigentlich mehr aus Spaß - ein Modul für den Apache HTTPd geschrieben das die arme wehrlose Webserver-Software RFC-unkonform macht.

Genau genommen macht das mod_ignore_authcomponent auf Wunsch zuvor geleistete Arbeit wieder rückgängig und stripped dabei einfach eines der Slashes am Anfang der Domain weg. Überraschenderweise hat das Modul auch gleich seit letzter Woche den Weg durch unser Build-System genommen und es heute Abend in unsere offiziellen Paket-Quellen geschafft. Bei Bedarf werden wir es wohl in den kommenden Nächten auf unsere Webserver ausrollen und einen entsprechenden Button bei uns im Kundeninterface einpflegen.

Wenn man den Blog hier streng auf Hosting-Themen beschränken würde, wäre dieses Thema wohl Off-Topic. Ich beschränke aber nicht derartig und werde nun voller Freude berichten.

Ein Kunde feierte am Freitag Abend seine Weihnachtsfeier, zu der ich auch gelanden war und mit großer Freude teilnahm. Der Höhepunkt war in diesem Jahr ein Menü aus 9 Gängen, dass - mit Verlaub - hervorragend war. Der Koch samt Cheffin wurde dazu extra aus Spanien eingeflogen und beide hatten offensichtlich auch jede Menge Spaß am Abend und dokumentierten fast fleißiger als jeder Gast dort das Geschehen und natürlich das Menü.

Nach der Feier wurde die Speicherkarte von einem der Geschäftsführer (sprich: Hätte es eine entsprechend Betriebsvereinbarung zur Nutzung der Computer gegeben, wäre die auch sinnlos gewesen) an einen Computer des Unternehmens angeschlossen - nur um eine Kopie der Bilder zu bekommen. Doch der Virenscanner schlug sofort an und löschte gerade zu Bedingungslos die ersten 2 KB Dateisystems auf der Speicherkarte, eine Wiederherstellung sollte nicht mehr möglich sein.

"Hah! Wieder eine gelegenheit zu puzzlen!" war wohl mein erster Gedanke und er sollte nicht mein letzter in dieser Sache sein.

Das Problem: In den ersten 512 Byte des Dateisystems stehen eigentlich alle Rahmendaten die zur Nutzung der restlichen Daten notwendig sind, nun standen dort nur noch Nullen. Erschwerend kam hinzu, dass ich eigentlich gar kein Wissen über das FAT-Dateisystem vorzuweisen hatte. Auf meiner Zugfahrt von der Feier nach Hause habe ich mich also erst einmal an ein intaktes FAT-Dateisystem heran getastet. Erst Dateisystem-Informationen ausgelesen, Verzeichnis-Informationen ausgewertet, Cluster lokalisiert und schlussendlich selbige verkettet und daraus ganze Dateien gemacht.

Ich würde ja die einzelnen Zwischenschritte zeigen, allerdings sind die mittlerweile in einer Art Bibliothek aufgegangen und vereinfacht worden.

Der Schritt zu der kaputten Speicherkarte (die ich als Image mitgenommen hatte) war dann eigentlich nur noch Parameter raten und die Verzeichnisse finden, wo alle Bilder liegen. Und siehe da: Ich habe alle Bilder aus dem Image retten können, fehlerfrei. B-)

Damit meine Code-Schnipsel, die mir hierzu verholfen haben, nicht verloren gehen, habe ich sie gleich mal online gestellt. Im Zweifel helfen sie vielleicht auch einem anderen Bastler. Die Fotos werde ich gleich manuell hochladen und so an ihre Urheber zurückgeben.

Ich habe ja gestern schon von ein paar Patches für PHP 5.1.6 berichtet. Die Version ist zwar mittlerweile stein alt und niemand wird sie noch verwenden (außer wir, wenn der Kunde es so will ), aber der Vollständigkeit halber noch zwei Backports / Patches, die ich gestern unterschlagen habe:

• Patch um die Suhosin-Extension 0.9.32.1 zu nutzen (nur für PHP 5.1.6 notwendig)
• Heimverzeichnis des jeweiligen Benutzers in Fehlermeldungen abschneiden (für PHP 5.x)

Letzterer Patch ist sicherlich so ein tiggersWelt.net-spezifisches Ding, da bei uns Kunden typischerweise ein Heimverzeichnis nach dem Schema /home/{erstedomain.tld}/ erhalten und die Domain dann auch in den Fehlermeldungen für andere Domains des selben Kunden erscheint - das will man nicht immer sehen. Praktischerweise entspricht die "neue" Fehlermeldung dann auch direkt dem FTP-Pfad, den der Kunde zu sehen bekommt.

Es ist irgendwie immer ein Drathseilakt, wenn man Limits auf dem Webserver festlegt - wie lange darf ein Skript laufen, bevor der Webserver ihn automatisch beendet? Wählt man das Limit zu kurz, schreien etliche Kunden, wählt man es zu lange, schreien sie vermutlich wieder wenn man ein Skript amok läuft.

Ich finde die Aussage "Da läuft halt gerade ein Skript von Dir nicht rund und belegt alle Ressourcen" wenig befriedigend - auch oder gerade dann wenn ich der jenige bin, der sie gibt, und nicht der jenige, der sie bekommt. Aber in dem Moment ist alles andere unwirtschaftlich, wir können nicht die Zeit aufbringen herauszufinden, welcher Skript da gerade läuft und wo genau es hakt. Wenngleich wir natürlich auch hier unser Bestes zu geben versuchen.

Um ein wenig mehr Licht in die Angelegenheit zu bringen, haben wir uns nun aufgemacht und einen kleinen Patch in der FastCGI-SAPI von PHP eingebaut:

Die laufenden FastCGI-Server ändern nun ihren Prozess-Title und geben somit Preis was sie gerade tun, z.B. ob sie gerade eine Anfrage bearbeiten oder auf die nächste warten. Super! Nun muss es sich nur noch im Produktiv-Betrieb bewähren.

Bei der Gelegenheit haben wir noch ein paar Änderungen in den PHP 5.1er-Baum zurückgeführt, um PHP 5.1.6 mit OpenSSL 1.0 und neueren CURL-Versionen zu bauen.