Netz - Rettung - Recht (Artikel mit Tag vpn)

WIFI-on-ICE, VPN und die MTU

nospam@example.com (Thomas Hochstein) — Mon, 29 Jan 2018 12:30:00 +0000

Dankenswerterweise hat die Bahn ihren ICE-Zügen ein (nach meiner Erfahrung) überraschend gut funktionierendes WLAN verpasst (aber ich nutze auch eher bandbreitensparsame Dienste). Schon bei der letzten Bahnreise warf aber der Abruf von News und Mails vom heimischen Server Schwierigkeiten auf; es “hakte” irgendwie, die Daten tröpfelten durch die Leitung, und der Abruf der ersten größeren Newsgroup führte zum Stillstand.

Bildquelle und Lizenz: XoCoO via Wikimedia Commons [CC BY-SA 3.0]

Bei meiner gestrigen mehrstündigen Bahnreise dann dasselbe Problem: kaum hatte der Zug gewendet und mein Sitz zeigte für die nächsten vier Stunden in Fahrtrichtung, packte ich meinen Laptop aus, verband mich mit dem WLAN und wollte loslegen. Doch wieder war die Konnektivität sehr unbefriedigend: ein paar einzelne Mails wurde ich los, der Newsaustausch wollte nicht recht funktionieren, auch der Zugriff auf das Webmailinterface wollte nicht, und eine SSH-Verbindung kam zwar zustande, hängte sich aber reproduzierbar beim Attachen der laufenden screen-Session auf. Andere Webseiten waren aber (mit kurzen Aussetzern) ohne Schwierigkeiten verfügbar, und auch die VPN-Verbindung ins heimische Netz stand: die Hosts dort ließen sich pingen (und ja auch via SSH nachweislich erreichen).

Ich muss eingestehen, dass ich mehrere Stunden darüber gegrübelt habe, wo das Problem wohl liegen könnte, obschon das Fehlerbild eigentlich eindeutig ist: die Netzverbindung ist stabil und recht flott, wenn man pingt, kleine Datenmengen lassen sich auch übertragen, aber sind mehr Daten zu übermitteln (wie eine Webseite oder eine screen-Session), dann läuft alles in Timeouts - das kann eigentlich nur ein MTU-Problem sein, um so mehr, wenn ein VPN beteiligt ist! Und, um das Ergebnis vorwegzunehmen: nachdem ich flüchtig gegoogelt und die MTU auf der VPN-Verbindung von 1380 auf 1300 herabgesetzt hatte, flutschte alles durch die VPN-“Leitung”, als sei nie etwas gewesen.

Aber was hat es mit dieser MTU auf sich? - Eine recht schöne Erläuterung habe ich bei der Packet University gefunden: Recognizing IP MTU Issues

Um das laienhaft zusammenzufassen: Die MTU ist die maximum transmittable unit und gibt (bei IP-Verbindungen) an, bis zu welcher Größe IP-Pakete über die Verbindung übertragen werden können. Über Ethernet-Verbindungen lassen sich Pakete mit höchsten 1.500 Bytes übertragen, die MTU ist also 1.500, und das ist auch der in der Praxis übliche Wert, denn logischerweise gibt die kleinste MTU auf einer Teilstrecke die Paketgröße für die gesamte Verbindung vor. Werden IP-Verbindungen bspw. über ein VPN getunnelt, müssen die IP-Pakete entsprechend “gekapselt” werden, “wachsen” also durch die VPN-Übertragung, sollten aber immer noch nicht die MTU überschreiten; die zu übertragenden Pakete müssen also am Anfang kleiner sein. Nachdem man Übertragungsprotokolle mehrfach ineinander verschachteln kann, kann die MTU am Ende deutlich unter 1.500 liegen.

Eigentlich sollte das kein Problem sein: ist ein Paket zu groß, um weiter übertragen zu werden, kann es entweder in mehrere Teile zerlegt (“fragmentiert”) und beim Empfänger wieder zusammengesetzt werden, oder, wenn das nicht gewünscht - und das Paket entsprechend gekennzeichnet - ist, als “unzustellbar” zurückgegeben werden. Dabei wird zugleich die MTU der Teilstrecke übermittelt, durch die das Paket nicht durchpasste. Der Absender schickt es jetzt erneut - und setzt vorher die MTU passend herab. Diese automatische Aushandlung nennt sich PMTUD oder Path MTU Discovery - und scheitert leider manchmal (oft?), bspw. weil Firewalls entsprechende ICMP-Pakete ausfiltern, aber auch aus anderen Gründen. Dann hilft es nur, beim Auftreten charakteristischer Probleme die MTU herabzusetzen - in meinem Fall von den schon niedrigen 1.380 auf 1.300. Und dann flutscht auch alles wieder.

FRITZ!Box-VPN mit Shrew Soft

nospam@example.com (Thomas Hochstein) — Fri, 12 Aug 2016 05:40:00 +0000

Wie ich beschrieben habe, kann ich leider den VPN-Client FRITZ!Fernzugang nicht benutzen, weil sich nach dessen Installation mein Rechner beim Wechsel in den Standby-Modus immer aufhängt. Außerdem soll der Client offenbar nicht mit Windows 10 laufen.

Doch es gibt eine Lösung, auf die Andreas Edler dankenswerterweise in seinem Kommentar hier im Blog hinwies: der Shrew Soft VPN-Client, dessen Installation auch bei AVM dokumentiert ist.

Genauer gesagt gibt es sogar zwei Möglichkeiten, den Client einzusetzen. Die eine ist beim Hersteller der FRITZ!Boxen, AVM, dokumentiert, und setzt auf die Aktivierung der Option “VPN” in den Einstellungen eines FRITZ!Box-Benutzers. Das funktioniert problemlos, hat aber aus meiner Sicht zwei Nachteile:

Es ist die Eingabe von Benutzernamen und Passwort erforderlich. Das muss kein Nachteil sein, bedeutet aber zusätzlichen Aufwand bei jeder Herstellung der Verbindung (und das Passwort speichern will man jedenfalls dann nicht, wenn es auch Zugriff auf die Konfiguration der FRTIZ!Box gibt).
Ich habe keine Möglichkeit gefunden, festzulegen, welche IP das über VPN von außen eingewählte Gerät im lokalen Netz der FRITZ!Box erhält. Bei meinem Test war es irgendeine, die zudem außerhalb des Bereichs lag, der für den DHCP-Server der FRITZ!Box eingestellt ist, den ich allerdings ohnehin deaktiviert habe.

Letzteres stört meinen Ordnungssinn. In meinem lokalen Netz läuft ein DHCP-Server - außerhalb der FRITZ!Box -, der zum einen für dynamisch vergebene Adressen für eine Vorwärts- und Rückwärtsauflösung im lokalen DNS sorgt, und der vor allem zum anderen für jedes bekannte Gerät eine nach einem bestimmten Schema vergebene feste IP-Adresse herausgibt. Da passt das scheinbar willkürliche Agieren der FRITZ!Box nicht hinein.

Daher habe ich nach einer Möglichkeit gesucht, die über das Programm FRITZ!Box-Fernzugang einrichten generierte, für FRITZ!Fernzugang vorgesehene Client-Konfiguration für den Shrew Soft-Client nutzbar zu machen. Ich muss gestehen, dass ich - sicherlich nicht zuletzt dank meiner völligen Unkenntnis der Funktionsweise eines VPN - damit trotz mehrerer Stunden Arbeit gescheitert bin. Gerade noch rechtzeitig habe ich dann aber im Blog von Harald Popke den Beitrag FritzBox VPN mit Windows 10 gefunden, in dem er auf das Konvertierungstool FritzToShrew verweist. Dessen letzte Version 1.0 datiert zwar von 2009, aber zum einen ist auch der letzte veröffentlichte Shrew Soft-Client von 2013 nicht mehr brandneu, und zum anderen - viel entscheidender - funktioniert die Konvertierung problemlos!

Jetzt komme ich also wieder ohne Passworteingabe - nur mit dem PreSharedKey - und vor allem mit meiner “richtigen” IP ins lokale Netz.

VPN mit der FRITZ!Box

nospam@example.com (Thomas Hochstein) — Tue, 09 Aug 2016 12:45:00 +0000

Schon lange interessiere ich mich für die Möglichkeiten eines VPN, eines Virtual Private Network. Dabei geht es mir weniger darum, meine tatsächliche IP-Adresse zu verstecken, um Geoblocking zu umgehen oder böse Dinge[tm] zu tun - gereizt hat mich vielmehr einerseits die Möglichkeit, meinen Datenverkehr aus unsicheren Netzen gesichert auszuleiten, vor allem aber der Gedanke, mein heimisches Netzwerk mit anderen Netzen zu koppeln oder mich von außen in mein hausinternes Netz einloggen und auf alle Ressourcen zugreifen zu können, statt einzelne Dienste über SSH zu tunneln. Mit dem letzteren Gedanken spiele ich schon seit etlichen Jahren, zur Umsetzung ist er aber nie gekommen.

Doch jetzt bietet die neue FRITZ!Box die Möglichkeit dazu, das einmal auszuprobieren. Die Vorgehensweise ist tatsächlich so einfach, wie sie sich auf der entsprechenden Supportseite von AVM liest:

Mit dem Programm FRITZ!Box-Fernzugang einrichten lassen sich trivial die notwendigen Konfigurationsdateien für den VPN-Server (FRITZ!Box) und den Client (Laptop) erstellen. Man sollte nur darauf achten, dem VPN-Client eine bisher nicht vergebene IP im lokalen Netz zuzuweisen, weil die FRITZ!Box diese IP dann “reserviert”, so dass sie im Heimnetz nicht mehr anderweitig genutzt werden kann. Die Konfigurationsdatei für den Server kann man dann ggf. noch in einem Texteditor bearbeiten und jedenfalls über die Oberfläche der FRITZ!Box importieren.
Danach ist nur noch der VPN-Client FRITZ!Fernzugang herunterzuladen, auf dem Laptop zu installieren und mit der bereits erstellen Konfigurationsdatei zu bestücken.

Danach kann man sich mit dem Laptop zu Testzwecken bspw. über eine UMTS-Verbindung ins Netz einwählen und dann von außen auf das Heimnetz zugreifen. Der Laptop hat dann eine IP aus dem Netz des Mobilfunkanbieters, taucht aber zugleich im lokalen Netz auf und kann auf alle Dienste dort zugreifen - so wie es sein soll.

Zwei Schönheitsfehler hat die Geschichte allerdings, einen kleinen und einen großen.

Zum einen sind die Netzwerkshares und Drucker im lokalen Netz nicht über den Rechnernamen, sondern nur über die IP-Adresse zugänglich, wie sich auch dem Hilfetext “Über VPN-Verbindung auf Datei- und Druckerfreigaben zugreifen” entnehmen lässt.

Zum anderen - und das ist besonders ärgerlich - ist mein Lenovo Thinkpad T520 nach der Installation des VPN-Clients nicht mehr in der Lage, in den Standby-Modus (Suspend to RAM, Sleep Mode) zu wechseln. Und das äußert sich leider nicht dergestalt, dass er schlicht in den Betrieb bleibt, sondern so, dass der Bildschirm abschaltet, aber der Rechner in Betrieb bleibt. Und aus diesem Zustand lässt er sich leider nur noch durch hartes Abschalten (“Power”-Taster mehrere Sekunden lang drücken) befreien. Nach Deinstallation des VPN-Clients ist der Spuk wieder vorbei.

Man findet das Phänomen im Netz mehrfach beschrieben, aber leider keine klare Ursachenbeschreibung oder gar Lösungsvorschläge (außer der Deinstallation). Daher bin ich leider vorerst ratlos und muss auf den VPN-Zugang verzichten.

Vielleicht hat aber ein Leser eine kluge Idee?