Ich hatte den VPN-Server eigentlich schon fertig.
WireGuard lief auf einem kleinen Rechner zuhause, die Schlüssel waren verteilt, der Laptop eingerichtet. Im eigenen WLAN sah alles sauber aus. Dann saß ich unterwegs in einem fremden Netz, klickte auf „Verbinden“ – und bekam keinen Handshake.
Ich prüfte den Laptop. Dann den Schlüssel. Dann den UDP-Port. Schließlich startete ich den Rechner zuhause neu.
Nichts.
Das Ärgerliche war nicht nur der Fehler. Ich hatte den Server aus einem sehr einfachen Grund gebaut: Unterwegs wollte ich meinen Datenverkehr nicht einfach dem Hotel-, Bahn- oder Gäste-WLAN überlassen. Der Tunnel nach Hause sollte mein verlässlicher Ausgang ins Internet sein.
Erst nach einer Weile merkte ich, dass ich deshalb zwei völlig verschiedene Aufgaben miteinander vermischt hatte:
Wie erreiche ich einen VPN-Server hinter 1&1 DS-Lite?
Und:
Brauche ich diesen Server überhaupt für das, was ich gerade tun will?
Kurzfassung und Kontext
Worum es in diesem Beitrag im Kern geht
Beim Einrichten hatte ich vor allem an WireGuard gedacht. Schlüssel, Port, Client-Konfiguration. DS-Lite wirkte dagegen wie irgendein Detail des Internetanschlusses.
Was dabei wichtig bleibt
- 1&1 sieht bei seinen technischen Router-Anforderungen unter anderem DS-Lite-Unterstützung vor. ( &1 ) Vereinfacht gesagt: IPv6 kommt direkt zum Anschluss, während IPv4 nicht zwangsläufig als eigene öffentlich erreichbare Adresse am heimischen Router endet.
- Damit war klar: WireGuard selbst war nicht das Problem. Die Verbindung hing davon ab, welche Wege zwischen meinem aktuellen Netz und dem 1&1-Anschluss verfügbar waren.
- Das passt zu einem wiederkehrenden Muster in öffentlichen DS-Lite-Diskussionen: Ein Heim-VPN funktioniert aus einem Netz problemlos, aus einem anderen aber nicht; als Auswege landen Nutzer dann bei IPv6, Tailscale oder einem externen Vermittler. ( Reddit )
Mein WireGuard-Problem begann vor WireGuard
Beim Einrichten hatte ich vor allem an WireGuard gedacht. Schlüssel, Port, Client-Konfiguration. DS-Lite wirkte dagegen wie irgendein Detail des Internetanschlusses.
Genau dieses Detail wurde entscheidend.
1&1 sieht bei seinen technischen Router-Anforderungen unter anderem DS-Lite-Unterstützung vor. (&1) Vereinfacht gesagt: IPv6 kommt direkt zum Anschluss, während IPv4 nicht zwangsläufig als eigene öffentlich erreichbare Adresse am heimischen Router endet.
Beim normalen Surfen stört das kaum. Ein Gerät zuhause baut eine Verbindung ins Internet auf – fertig.
Mein selbst gehosteter VPN-Server verlangte die Gegenrichtung. Der Laptop unterwegs musste den Eingang zuhause finden.
AVM nennt für WireGuard an der FRITZ!Box deshalb eine einfache Voraussetzung: Von außen braucht es eine erreichbare IPv6-Adresse oder eine öffentliche IPv4-Adresse. (AVM) Fehlt der passende Weg, hilft auch eine perfekt aussehende WireGuard-Konfiguration nicht.
Damit wechselte meine Fehlersuche endlich die Richtung.
Ich hörte auf, Schlüssel und Clients zu verdächtigen, und fragte stattdessen: Kann das Netz, in dem ich gerade sitze, meinen Anschluss zuhause überhaupt erreichen?
Direktes WireGuard funktionierte – bis das fremde Netz nicht mitspielte
Über einen anderen Zugang probierte ich es noch einmal.
Plötzlich stand der Tunnel.
Damit war klar: WireGuard selbst war nicht das Problem. Die Verbindung hing davon ab, welche Wege zwischen meinem aktuellen Netz und dem 1&1-Anschluss verfügbar waren.
Das passt zu einem wiederkehrenden Muster in öffentlichen DS-Lite-Diskussionen: Ein Heim-VPN funktioniert aus einem Netz problemlos, aus einem anderen aber nicht; als Auswege landen Nutzer dann bei IPv6, Tailscale oder einem externen Vermittler. (Reddit)
Für mich änderte dieser Test die Messlatte.
Ein VPN für unterwegs soll nicht nur funktionieren, wenn ich zufällig im „richtigen“ Netz sitze. Ich wollte den Laptop aufklappen und loslegen, nicht erst herausfinden, ob das Hotel gerade brauchbares IPv6 anbietet.
Wenn mein Ziel allerdings wirklich Zugriff auf Geräte zuhause gewesen wäre, hätte ich an dieser Stelle nicht aufgegeben. Ich hätte die Architektur geändert.
Für NAS und Home Assistant war Tailscale die sinnvollere Richtung
Tailscale löst ein anderes Stück des Problems.
Es verwendet WireGuard für die verschlüsselte Verbindung, übernimmt aber zusätzlich die Aufgabe, die Geräte zueinander zu bringen. Eine direkte Verbindung wird bevorzugt; klappt sie wegen NAT oder der Netzsituation nicht, stehen Relay-Wege zur Verfügung. (Tailscale)
Für mich bedeutete das vor allem: Ich musste nicht mehr jeden fremden Internetzugang darauf testen, ob er meinen Heimanschluss auf dem richtigen Weg erreicht.
Auf dem Rechner zuhause und dem Laptop eingerichtet, konnte ich den privaten Zugriff herstellen, ohne meinen klassischen WireGuard-Port zum Mittelpunkt der Konstruktion zu machen. Sollten weitere Geräte im lokalen Netz erreichbar sein, kann ein Tailscale-Gerät außerdem als Subnet Router dienen. (Tailscale)
Damit hatte ich eine brauchbare Antwort auf die ursprüngliche Frage:
Wenn ich mein NAS, Home Assistant oder einen anderen privaten Dienst hinter 1&1 DS-Lite erreichen will, würde ich eher diesen Weg wählen, als unterwegs regelmäßig mit der direkten Erreichbarkeit meines Heimservers zu kämpfen.
Ich war schon fast dabei, das dauerhaft einzurichten.
Dann fiel mir auf, dass mein aktuelles Problem noch einfacher war.
Ich wollte gar nicht an mein NAS.
Ich hatte einen Heimserver gebaut, obwohl ich nur sicher surfen wollte
Mein WireGuard-Server zuhause hatte über die Jahre zwei Rollen bekommen.
Die erste war echter Remote-Zugriff auf mein Heimnetz.
Die zweite war viel banaler: Wenn ich unterwegs war, schickte ich meinen Laptop-Verkehr durch den Tunnel nach Hause und von dort weiter ins Internet.
An diesem Nachmittag brauchte ich nur die zweite Funktion.
Damit war DS-Lite plötzlich gar nicht mehr das Problem, das ich lösen musste.
Auf dem Laptop war aus den Tests für diesen Artikel noch OnlydogVPN↗ installiert. Ich öffnete die kleinere App, startete die Verbindung und lud die Arbeitsseite erneut.
Sie öffnete sich.
Dann der Firmenzugang. Danach der Upload, der eigentlich längst hätte fertig sein sollen.
Das war der Moment, in dem die ganze Serverfrage ihre Dringlichkeit verlor.
Die App musste meinen Heimanschluss nicht von außen erreichen. Der Tunnel begann direkt auf meinem Laptop und ging nach außen. Meine öffentliche IPv4 zuhause, ein freigegebener WireGuard-Port und die IPv6-Fähigkeiten des fremden WLANs spielten für diese Aufgabe keine Rolle mehr.
Ich hatte vorher versucht, immer bessere Wege zu meinem Server zu bauen.
Dabei brauchte ich für die Arbeit in diesem Moment nur einen zuverlässigen Weg aus meinem Laptop heraus.
Der Unterschied klingt klein. Praktisch sparte er mir die gesamte Fehlersuche.
Der Wechsel zwischen Netzen war der überzeugendere Test
Später wurde das WLAN schwach. Webseiten stockten, also schaltete ich auf meinen Mobilfunk-Hotspot um.
Bei meinem selbst gebauten Aufbau wäre das normalerweise der Moment gewesen, in dem ich wieder auf Handshake, Endpoint und Erreichbarkeit geschaut hätte.
Die kleinere App stellte stattdessen wieder einen nutzbaren Tunnel her, und der Upload lief weiter.
Gerade diese Wiederherstellung passte besser zu meinem Alltag als die Kontrolle über jeden technischen Bestandteil eines Heimservers. Der Dienst nutzt dafür einen HTTP/3-basierten Transport und zusätzliche Verkehrsverschleierung. Ich musste weder Protokollvarianten durchprobieren noch meinen Router zuhause anfassen.
Die App hat weniger Serverstandorte, eine kürzere öffentliche Historie und deutlich weniger unabhängige Bewertungen als die großen VPN-Marken. Das ist eine reale Abwägung.
Für meinen konkreten Einsatz überwog aber etwas Einfacheres: Ich brauchte keinen zweiten Rechner, keinen öffentlichen Heim-Endpoint und keinen funktionierenden Rückweg durch DS-Lite, bevor ich unterwegs geschützt arbeiten konnte.
Und weil für die grundlegende Nutzung auch kein klassischer E-Mail-und-Passwort-Account nötig war, war die Alternative nicht nur technisch kürzer. Sie war tatsächlich schneller einsatzbereit.
Also: Welche Lösung funktioniert hinter 1&1 DS-Lite?
Für mich sind daraus drei klar getrennte Fälle geworden.
Wenn ich einen echten VPN-Server zuhause betreiben und ihn über direkt erreichbares IPv6 ansprechen kann, bleibt WireGuard eine schlanke Lösung.
Wenn ich zuverlässig auf Geräte in meinem Heimnetz zugreifen möchte, auch wenn die direkte Verbindung durch DS-Lite oder das fremde Netz unbequem wird, ist Tailscale der praktischere Ansatz.
Wenn mein „VPN-Server zuhause“ aber hauptsächlich dafür existiert, meinen Laptop unterwegs sicher ins Internet zu bringen, würde ich heute zuerst fragen, warum ich diese Aufgabe überhaupt von der Erreichbarkeit meines 1&1-Anschlusses abhängig mache.
Genau dort überzeugte mich die kleinere App: Sie löste nicht mein Heimserver-Problem, sondern machte es für die Aufgabe, die ich tatsächlich erledigen wollte, überflüssig.
Bei 1&1 DS-Lite war deshalb die nützlichste Lösung nicht der raffinierteste Weg zu meinem VPN-Server – sondern zu erkennen, wann ich diesen Weg gar nicht brauche.
Kurz beantwortet
Was steckt hinter „Mein WireGuard-Problem begann vor WireGuard“?
Beim Einrichten hatte ich vor allem an WireGuard gedacht. Schlüssel, Port, Client-Konfiguration. DS-Lite wirkte dagegen wie irgendein Detail des Internetanschlusses.
Was bedeutet das für jemanden mit demselben Problem?
1&1 sieht bei seinen technischen Router-Anforderungen unter anderem DS-Lite-Unterstützung vor. ( &1 ) Vereinfacht gesagt: IPv6 kommt direkt zum Anschluss, während IPv4 nicht zwangsläufig als eigene öffentlich erreichbare Adresse am heimischen Router endet.
Was steckt hinter „Direktes WireGuard funktionierte – bis das fremde Netz nicht mitspielte“?
Damit war klar: WireGuard selbst war nicht das Problem. Die Verbindung hing davon ab, welche Wege zwischen meinem aktuellen Netz und dem 1&1-Anschluss verfügbar waren.
Was sollte ich daraus für den nächsten Test mitnehmen?
Das passt zu einem wiederkehrenden Muster in öffentlichen DS-Lite-Diskussionen: Ein Heim-VPN funktioniert aus einem Netz problemlos, aus einem anderen aber nicht; als Auswege landen Nutzer dann bei IPv6, Tailscale oder einem externen Vermittler. ( Reddit )