Verständnisfrage Wireguard VPN und öffentliche IP des VPS 1000

  • Hallo!


    Ich habe mal wieder eine Verständnisfrage zu meinem Testserver welchen ich für mein Hobby zum lernen verwende.

    Es laufen auf diesem im Docker Containern - Traefik als reverse Proxy (SSL) - Nextcloud - Bitvarden. Nicht wirklich produktiv, also nur so um mich ein wenig mit der IT

    zu beschäftigen.

    Nun wollte ich den V1000 (Ubuntu) als "Client" oder besser Peer über Wireguard mit meinem Homeserver verbinden.

    Ich habe hier FTTH mit 1Gbit in beide Richtungen und eine feste öffentliche IPV4. Handy und Co. geht auch ohne Probleme mit dem VPN.

    Die Verbindung konnte ich erfolgreich herstellen. Ein Traceroute zu 1.1.1.1 zeigt mir ein erfolgreiches Routing über meinen Server hier zu Hause.

    Ping geht in beide Richtungen - also die jeweilige TUN Adresse (10.66.66.6 NetCup) bzw (10.66.66.2 Homeserver).

    Was ich nun gern verstehen würde, wenn ich den Tunnel von Client (NetCup) öffne mit "wg-quick up wg0" wird der Tunnel gestartet, im selben Moment

    aber hängt sich die SSH-Shell weg bzw. wird unterbrochen. Auch die Dienste im Docker sind nicht mehr zu erreichen. Auch die öffentliche IP des Servers

    bei NetCup ist "tot". Ich kann dann die SSH wieder neu aufbauen - aber nur über die TUN Adresse 10.66.66.6 aber so laufen die Docker Dienste nicht mehr

    bzw. sind eben nicht erreichbar.


    Wo liegt mein Denkfehler? Es wird sämtlicher Verkehr mit "Allowed IP = 0.0.0.0/0" über TUN geroutet. Kann es das schon sein und wenn ja, wie kann ich das ändern?


    Vielen Dank!


    VG Mario

  • Baust du die SSH Verbindung von dem Home-Server zu dem Netcup-Server auf? Falls ja, würde ich drauf tippen, dass er nun eine "bessere" Route zum Ziel kennt und daher die Verbindung unterbrochen ist.

    Das ist der Effekt von "Allowed IP = 0.0.0.0/0". Das würde ich einschränken auf die Netze, aus denen du auch IPs an die Clients ausgibst. Dann musst du allerdings deinen Server über die jeweiligen VPN Adressen ansprechen, damit die Verbindung über Wireguard dann geht.


    Ich kenne das wenn ich per SSH von meinem Rechner mit dem Server verbunden bin auf dem Wireguard auch läuft und dann lokal die Wireguard Verbindung starte. Da hilft https://linux.die.net/man/1/autossh

  • Baust du die SSH Verbindung von dem Home-Server zu dem Netcup-Server auf?

    Hallo! Nein ich gehe von einem Windows PC - welcher im selben Netz wie der Server ist - über Bitvise auf den NetCup.


    Was mich eigentlich am meisten stört ist die Tatsache, dass ich die Docker Container bzw. die dort laufenden Dienste nicht mehr erreichen kann, also es wird keine URL mehr zum NetCup Server durchgereicht. Auch ein Ping auf die öffentliche IP des NetCup Servers ist nicht mehr möglich, als ob eth0 abgeschaltet ist - ist es natürlich nicht aber eben nicht mehr direkt erreichbar. Der V1000 kann sich nur noch selbst anpingen - also seine öffentliche IP, alle über den Wireguard Tunnel, also mein Heimnetz kann auch erreicht werden. DNS wird über meinen AdGuard (VM auf meinem Homeserver) aufgelöst - auch das funktioniert.


    Beende ich dann den Tunnel, ist wieder alle über die öffentliche IP erreichbar, also auch die Dienste im Docker.


    Muss ich noch manuell was Routen damit wg0 quasi eth0 findet? Oder denke ich da mittlerweile komplett falsch.

    Ich muss mir das ganze mal skizzieren und mit den ensprechenden Nummern versehen.

    Vielleicht finde ich selbst den fehler - oder hier kann man sich das ganze besser veranschaulichen ;)


    VG Mario

  • Muss ich noch manuell was Routen damit wg0 quasi eth0 findet?

    wg0 findet ja eth0, sonst würde ja der Tunnel (mit 10.66.66.6) auch nicht mehr funktionieren. Dafür sorgt wg beim Verbindungsaufbau durch eine dedizierte Host Route.


    Aber natürlich ist 0.0.0.0/0 das Problem. Damit schaltest du das Internet im VPS quasi ab. Mach es dir klar: Ein Paket kommt von außen auf deinem Server auf eth0 an. Der will darauf antworten, guckt in seine Routen und schickt die Antwort zum VPN Interface raus, über deinen Heimrouter ins Internet. Es kommt vielleicht am Ende wieder beim Absender an, aber von einer komplett anderen IP Adresse. Der Sender weiß gar nicht, dass die Antwort mal zu seiner Frage gehörte und wird sie verwerfen.


    Wenn der Internetzugang über eth0 erhalten bleiben soll, dann darfst du nicht 0.0.0.0/0 über VPN routen. Alternativ musst du über Portweiterleitungen dafür sorgen, dass die Dienste des Servers auf deinem FTTH Zugang erreichbar werden. Aber aus Sicht der Latenzen ist das natürlich eine Katastrophe. Und ich würde auch nicht Server Traffic durch mein Heimnetz routen wollen.


    Was natürlich geht, ist ein policy based Routing für spezifische Randbedingungen. Da müsstest du dir halt überlegen, unter welchen Randbedingungen der VPN Tunnel genutzt werden soll, dann kann man ggf. eine Regel dafür bauen.

  • wg0 findet ja eth0, sonst würde ja der Tunnel (mit 10.66.66.6) auch nicht mehr funktionieren. Dafür sorgt wg beim Verbindungsaufbau durch eine dedizierte Host Route.


    Aber natürlich ist 0.0.0.0/0 das Problem. Damit schaltest du das Internet im VPS quasi ab. Mach es dir klar: Ein Paket kommt von außen auf deinem Server auf eth0 an. Der will darauf antworten, guckt in seine Routen und schickt die Antwort zum VPN Interface raus, über deinen Heimrouter ins Internet. Es kommt vielleicht am Ende wieder beim Absender an, aber von einer komplett anderen IP Adresse. Der Sender weiß gar nicht, dass die Antwort mal zu seiner Frage gehörte und wird sie verwerfen.

    Hallo!


    uih, dann lag ich ja mal ziemlich richtig mit meiner Vermutung. Danke die Erklärung - die ist genau so wie ich es brauche - klar und gut verständlich :) .

    Jetzt habe ich das auch für mich klar bekommen, ist ja dann auch logisch und kann so einfach nicht funktionieren.

    Wenn der Internetzugang über eth0 erhalten bleiben soll, dann darfst du nicht 0.0.0.0/0 über VPN routen. Alternativ musst du über Portweiterleitungen dafür sorgen, dass die Dienste des Servers auf deinem FTTH Zugang erreichbar werden. Aber aus Sicht der Latenzen ist das natürlich eine Katastrophe. Und ich würde auch nicht Server Traffic durch mein Heimnetz routen wollen.

    Ok das möchte ich natürlich auch nicht machen. Aber nun müsste man (ich) mich besser mit Wireshark auskennen und mal hier intern mit lauschen - aber das erstmal nicht so wichtig (ich träume ;) ).


    Was natürlich geht, ist ein policy based Routing für spezifische Randbedingungen. Da müsstest du dir halt überlegen, unter welchen Randbedingungen der VPN Tunnel genutzt werden soll, dann kann man ggf. eine Regel dafür bauen.

    Ok dann geht es schon einige Etagen höher vom Niveau - ich lese mich da mal etwas ein und entscheide dann, ob das was wäre oder ob es schon zu weit geht.


    Vielen Dank für die tolle Hilfe! - Hat mich wieder etwas weiter gebracht!

    VG Mario

  • Was genau ist denn dein Vorhaben? Einfach nur ein Point to Point Tunnel zwischen Heimserver und VPS, oder wirklich den VPS über deinen Heimanschluss erreichbar zu machen?

    Hallo!


    meine Vorstellung war eigentlich diese: Auf dem VPS laufen div. Dienste unter Docker - diese sind über einen Reverse Proxy zu erreichen (Meine Familie und 7 Feunde) vor allem Bitwarden und Nextcloud. Die auf dem VPS anfallenden Daten sollten dann mittels sicherer Verbindung (erster Gedanke VPN) auf meinen Homeserver gesichert werden. Bzw. hatte ich die Idee (was für mich aktuell noch sehr viel Stoff zum lernen ist) das Datenverzeichnis von Nextcloud (VPS 1000) auf meinen Server "umzubiegen" um den Storage beim VPS1000 nicht vollaufen zu lassen. Mein Server hier hat 8TB Plattenplatz mit kleimem Backupserver so das hier auch der Datenverlusst eher gering sein sollte.

    Natürlich könnte ich die Dienste auch hier zu Hause für die Familie freigeben, da bin ich mir dann aber wegen der Sicherheit nicht mehr ganz so "sicher" ;).

    Dann doch lieber über einen Tunnel eine art Backup auf meinen Server hier zu Hause, als evtl. ungebetene Gäste direkt hier zu Hause =O.

    Warscheinlich wird es dann eher über einen SSH-Tunnel gehen oder sowas, aber hier betrete ich dann auch für mich wieder Neuland.

    Wenn ich das Thema IT nicht so faszinierent finden würde, dann würde ich mir viel arbeit sparen und Angeln gehen oder sowas 8o.


    Ist aber ein tolles Forum wie ich finde, gibt dann doch immer wieder tolle Unterstützung.

    Danke!

    VG Mario

  • Okay also im Grunde nur ne Point to Point Verbindung. Dann musst du in deiner Wireguard Config auf dem VPS nur die Direktive "AllowedIPs = 0.0.0.0/0" ändern.

    Von jetzt 0.0.0.0/0 auf das innerhalb von Wireguard benutzte Netz. In deinem oben geschilderten Fall also 10.66.66.X/YY.


    Damit routest du dann nicht mehr den gesamten Traffic des VPS zu deinem Heimserver, sondern nur noch das Netz innerhalb von Wireguard.


    Da wie du schreibst noch weitere Clients darauf zugreifen sollen, musst du diese entsprechend auch in die AllowedIPs aufnehmen, entweder als Netz, oder als /32 EinzelIPs.


    Beispiel

    AllowedIPs = 10.66.66.0/30, 10.77.77.0/24, 10.88.88.8/32


    Sofern noch nicht geschehen, muss außerdem das IPv4 Forwarding auf deinem Heimserver aktiv sein, damit mehr als nur der Traffic Heimserver <=> VPS geroutet wird.

  • :thumbup: Klasse, so funktioniert es. Tunnel steht und die Docker-Dienste sind weiter über die URL erreichbar. VPS kann auf eine zum Test erstellte NFS Freigabe zugreifen und auch eine Linux VM kann auf den VPS bzw. die dort erstellte NFS Freigabe zugreifen. Darauf kann ich nun aufbauen - gleich mal testen wie schnell eine 5GB Datei hochgeladen wird 8o.

    Das Backup der Docker-Umgebung bzw. die Daten von Nextcloud wird dann die nächste Aufgabe.


    Danke für die tolle Unterstützung!


    VG Mario

  • Manchmal fehlt auch das forwarding.
    Mir hat das geholfen:

    Make sure you create the following file using a text editor too:

    vim /etc/sysctl.d/10-wireguard.conf

    Add the following text:

    Code
    net.ipv4.ip_forward=1
    net.ipv6.conf.all.forwarding=1

    Reload all changes and turn on NAT routing:

    sysctl -p /etc/sysctl.d/10-wireguard.conf

    # chmod -v +x /etc/wireguard/helper/*.sh

    # systemctl restart wg-quick@wg0.service