7
Remote Zugriff auf Heimnetz trotz DS-Lite über Wireguard-VPS
Hallo zusammen,
ich versuche derzeit das Unheil meiner DS-Lite-Internetanbindung zu überwinden und komme damit nicht so recht weiter. Ich bin Kunde bei Vodafone Cable und bekomme wie viele andere von denen keine eigene ipv4-Adresse. Um jetzt aber trotzdem Remote auf meine im Heimnetz gehosteten Services zugreifen zu können, habe ich versucht, mich folgender Lösung zu bedienen:
Ich habe einen günstigen virtuellen Server bei Ionos gemietet, darauf läuft Ubuntu inkl. Wireguard. Auf meinem Homeserver im Heimnetz läuft ebenfalls Ubuntu und es ist ebenfalls Wireguard installiert. Ich bin dabei grob dieser Anleitung gefolgt: https://apfelcast.com/ds-lite-ipv6-portfreigaben-erstellen-inkl-reversep ...
Zusätzlich habe ich mir bei Ionos auch noch eine Domain gemietet, um am Ende die Namensauflösung zu erleichtern.
Auf dem VPS läuft außerdem nginx um die eingehenden Anfragen an die richtige Stelle zu bringen (s. verlinkte Anleitung).
Die Konfiguration von Wireguard auf beiden Maschinen sieht wie folgt aus:
Homeserver:
VPS:
Der Wireguard Tunnel steht auch soweit. Ich kann vom VPS aus sämtliche Geräte im Heimnetz anpingen.
Bei ionos habe ich nun für meinen Jellyfin-Server (gleiche Maschine wie der Wireguard-Client) die Subdomain jellyfin.meine.adresse inkl. a- und aaaa-record angelegt (die auf die IPv4- und IPv6-Adresse des VPS zeigen). Auf dem VPS habe ich in nginx einen Eintrag angelegt, der auf den Domain-Name jellyfin.meine.adresse hört und weiterleitet an http://192.168.0.X:8096. Zusätzlich habe ich direkt in der entsprechenden Einstellung ein LetsEncrypt-SSL-Zertifikat eingerichtet.
Gebe ich nun jellyfin.meine.adresse in meinen Browser ein, lädt er sich zu Tode und endet mit "504 Gateway Time-out". Allerdings hat er dabei die URL bereits verändert, es steht nämlich da nichtmehr "https://jellyfin.meine.adresse", sondern "https://jellyfin.meine.adresse/web". Dieses "web" ist Teil der URL, die jellyfin auf dem "homescreen" lädt. Das lässt mich darauf schließen, dass der Request schon irgendwie am richtigen Ort landet, aber aus irgendeinem Grund die Inhalte des jeweiligen Services nicht geladen werden können.
Die Beschreibung für den Jellyfin-Service ist hier nur beispielhaft. Ich habe das gleiche mit mehreren anderen Geräten probiert, mit dem gleichen Resultat.
Zusatzinfo: Mein Router ist eine FritzBox 6591 Cable.
Ich hoffe mir kann hier jemand helfen und dass ich nur irgendwo einen einfachen Fehler gemacht habe.
Falls weitere Informationen benötigt werden, reiche ich die natürlich gerne nach.
Vielen Dank im Voraus!
Gruß Philip
ich versuche derzeit das Unheil meiner DS-Lite-Internetanbindung zu überwinden und komme damit nicht so recht weiter. Ich bin Kunde bei Vodafone Cable und bekomme wie viele andere von denen keine eigene ipv4-Adresse. Um jetzt aber trotzdem Remote auf meine im Heimnetz gehosteten Services zugreifen zu können, habe ich versucht, mich folgender Lösung zu bedienen:
Ich habe einen günstigen virtuellen Server bei Ionos gemietet, darauf läuft Ubuntu inkl. Wireguard. Auf meinem Homeserver im Heimnetz läuft ebenfalls Ubuntu und es ist ebenfalls Wireguard installiert. Ich bin dabei grob dieser Anleitung gefolgt: https://apfelcast.com/ds-lite-ipv6-portfreigaben-erstellen-inkl-reversep ...
Zusätzlich habe ich mir bei Ionos auch noch eine Domain gemietet, um am Ende die Namensauflösung zu erleichtern.
Auf dem VPS läuft außerdem nginx um die eingehenden Anfragen an die richtige Stelle zu bringen (s. verlinkte Anleitung).
Die Konfiguration von Wireguard auf beiden Maschinen sieht wie folgt aus:
Homeserver:
[Interface]
Address = 10.0.0.2/24
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eno1 -j MASQUERADE
PrivateKey = [PrivateKey des Homeservers]
[Peer]
PublicKey = [PublicKey des VPS]
AllowedIPs = 10.0.0.0/24
Endpoint = ipv4-des-VPS:51820
PersistentKeepalive = 25VPS:
[Interface]
Address = 10.0.0.1/24
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens6 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens6 -j MASQUERADE
ListenPort = 51820
PrivateKey = [PrivateKey des VPS]
[Peer]
PublicKey = [PublicKey des Homeservers]
AllowedIPs = 10.0.0.0/24, 192.168.0.0/24
PersistentKeepalive = 25Der Wireguard Tunnel steht auch soweit. Ich kann vom VPS aus sämtliche Geräte im Heimnetz anpingen.
Bei ionos habe ich nun für meinen Jellyfin-Server (gleiche Maschine wie der Wireguard-Client) die Subdomain jellyfin.meine.adresse inkl. a- und aaaa-record angelegt (die auf die IPv4- und IPv6-Adresse des VPS zeigen). Auf dem VPS habe ich in nginx einen Eintrag angelegt, der auf den Domain-Name jellyfin.meine.adresse hört und weiterleitet an http://192.168.0.X:8096. Zusätzlich habe ich direkt in der entsprechenden Einstellung ein LetsEncrypt-SSL-Zertifikat eingerichtet.
Gebe ich nun jellyfin.meine.adresse in meinen Browser ein, lädt er sich zu Tode und endet mit "504 Gateway Time-out". Allerdings hat er dabei die URL bereits verändert, es steht nämlich da nichtmehr "https://jellyfin.meine.adresse", sondern "https://jellyfin.meine.adresse/web". Dieses "web" ist Teil der URL, die jellyfin auf dem "homescreen" lädt. Das lässt mich darauf schließen, dass der Request schon irgendwie am richtigen Ort landet, aber aus irgendeinem Grund die Inhalte des jeweiligen Services nicht geladen werden können.
Die Beschreibung für den Jellyfin-Service ist hier nur beispielhaft. Ich habe das gleiche mit mehreren anderen Geräten probiert, mit dem gleichen Resultat.
Zusatzinfo: Mein Router ist eine FritzBox 6591 Cable.
Ich hoffe mir kann hier jemand helfen und dass ich nur irgendwo einen einfachen Fehler gemacht habe.
Falls weitere Informationen benötigt werden, reiche ich die natürlich gerne nach.
Vielen Dank im Voraus!
Gruß Philip
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2968274828
Url: https://administrator.de/forum/remote-zugriff-auf-heimnetz-trotz-ds-lite-ueber-wireguard-vps-2968274828.html
Ausgedruckt am: 30.12.2024 um 17:12 Uhr
7 Kommentare
Neuester Kommentar
Du bist mit dem Peer Netzwerk im 10.0.0.0/24 Bereich, eine Route kann nur in einen Bereich gehen, der außerhalb vom internen Netzwerk 10.0.0.0/24 liegt.
Mach das Peer Netz zu 10.0.1.0/24
Mach das Peer Netz zu 10.0.1.0/24
Hi und danke erstmal für die Antwort. Ich verstehe das noch nicht so ganz. 10.0.0.0 ist doch das Wireguard-Transport-Netz oder? Muss das nicht unter AllowedIPs eingetragen werden? In der Config des VPS habe ich zusätzlich ja noch 192.168.0.0/24 als Peer-Netzwerk eingetragen (das ist das Netzwerk meiner Fritzbox).
Welche IPs hat der Home Server?
Im Heimnetz 192.168.0.3 und im Wireguard Netz die 10.0.0.2.
Ich glaube ich konnte das Problem mittlerweile lösen.
Habe statt der ipv4 des VPS als Endpoint jetzt dessen ipv6 eingetragen und siehe da: es läuft!
Ich glaube ich konnte das Problem mittlerweile lösen.
Habe statt der ipv4 des VPS als Endpoint jetzt dessen ipv6 eingetragen und siehe da: es läuft!
Moin.
Etwas Lektüre für verregnete Sommertage
Merkzettel: VPN Installation mit Wireguard
Gruß Strods
PersistentKeepalive = 25
Keepalive am VPS ohne Endpoint macht keinen Sinn.AllowedIPs = 10.0.0.0/24, 192.168.0.0/24
Die Maske für den Peer auf dem VPS ist falsch, diese ist immer eine 32er Maske auf die IP des Peers.AllowedIPs = 10.0.0.2/32, 192.168.0.0/24AllowedIPs = 10.0.0.0/24
AllowedIPs am Client setzt man auf 10.0.0.1/32 wenn eh nur Traffic von und zum VPS selbst fließt.Etwas Lektüre für verregnete Sommertage
Merkzettel: VPN Installation mit Wireguard
Gruß Strods
Hi und sorry für die späte Rückmeldung.
Das klingt alles ganz logisch für mich. Habs entsprechend geändert und es funktioniert auch weiterhin.
Wenn ich in Zukunft weitere Peers hinzufügen wollte, sollte ich dann die allowed IPs im WG-Netz wieder zurück auf 10.0.0.0/24 setzen oder für den zweiten Peer dann eine 10.0.0.3 (usw.) vergeben und die entsprechend als 10.0.0.3/32 in den allowed IPs auf dem VPS ergänzen?
Gruß Philip
Das klingt alles ganz logisch für mich. Habs entsprechend geändert und es funktioniert auch weiterhin.
Wenn ich in Zukunft weitere Peers hinzufügen wollte, sollte ich dann die allowed IPs im WG-Netz wieder zurück auf 10.0.0.0/24 setzen oder für den zweiten Peer dann eine 10.0.0.3 (usw.) vergeben und die entsprechend als 10.0.0.3/32 in den allowed IPs auf dem VPS ergänzen?
Gruß Philip
Wenn ich in Zukunft weitere Peers hinzufügen wollte, sollte ich dann die allowed IPs im WG-Netz wieder zurück auf 10.0.0.0/24 setzen
Am Client nur wenn du direkt auf andere Peer-Adressen des Transfernetzes zugreifen können musst. Wenn du das dann aber bei einem machst muss du es bei anderen beteiligten ebenfalls machen, damit Traffic direkt von den anderen Peers fließen kann sofern diese mit ihrer Transfernetz IP Daten senden. Denn die Allowed-IPs bestimmen ja nicht nur was raus fließen darf sondern auch von welchen Adressbereichen Traffic rein kommen darf.oder für den zweiten Peer dann eine 10.0.0.3 (usw.) vergeben und die entsprechend als 10.0.0.3/32 in den allowed IPs auf dem VPS ergänzen?
Auf dem Server immer die vergebene IP des Peers im Transfernetz mit 32 Maske, und je nach Ziel eventuelle zusätzliche Netze hinter dem Client!
