Hi,
Müsste statt 10.202.197.XX nicht eine Adresse aus dem Heimnetz stehen?
nein, stell es Dir einfach vor wie ein Zwischennetz, welches es nur zwischen Client und VPN-Server gibt. Die Pakete durchlaufen auf dem Weg in Dein eigentliches Netzwerk dieses Zwischennetzwerk:
Client <Zwischennetzwerk> VPN-Server <LAN>
habe ich mir einen RaspberryPi mit Pivpn dran gebastelt
Die Frage ist hier eher "wie"? Der Punkt ist jetzt folgender:
Du hast nun 2 Netzwerke:
1) Dein LAN (192.168.2.0/24)
2) Das VPN-Netzwerk (10.202.197.0/24)
Dein Client rückt nun mit einer IP aus dem VPN-Netzwerk an (10.202.197.2). Kommt am Wireguard-Server an. Soweit kein Problem. Nun wird dieses Paket weitergeleitet an z.B. Deinen Router (192.168.2.1). Hier stellt sich sofort die Frage: Weiss Dein Router denn überhaupt wie er das Netzwerk 10.202.197.0/24 erreichen kann? Anders formuliert: Ich schicke Dir einen Brief ohne Absender und möchte von Dir eine Antwort erhalten. Du wüsstest ja auch nicht, wohin Du die Antwort schicken solltest.
Der VPN-Client schickt also eine Anfrage an z.B. den Router, dieser kennt den Absender aber nicht und folgt seinem normalen Verhalten, indem er die Antwort einfach an sein Standardgateway (und somit ins Internet) schickt. Die Antwort müsste aber zum Wireguard-Server gehen, damit dieser entsprechend an den Client weiterleitet.
Die Frage nach dem "wie" bzgl. der Einrichtung zielt nun auf folgendes ab: Oben beschriebenes (Variante 1) wäre reines Routing ohne irgendwas extra. In diesem Fall müsstest Du Deinem Router vermutlich einfach nur mitteilen (sofern möglich), dass dieser das VPN-Netz über die LAN-IP vom Wireguard-Server erreichen kann.
Bzgl. Variante 2 gibt es etwas namens "NAT" (Network Address Translation). Das kennst Du schon, macht Dein Router für Deine Geräte im LAN ebenfalls. Beim NAT (bzw. konkreter SNAT (Source-NAT/Quell-NAT) wird die Absender-Adresse bei einem Paket überschrieben. In Deinem LAN ist es z.B. so, dass wenn Du eine Anfrage ins Internet stellst, die Anfrage erstmal von der "privaten LAN-IP" des Endgerätes kommt. Erreicht dieses Paket nun den Router, überschreibt der Router die Quell-IP (interne LAN-IP des Clients) mit seiner eigenen öffentlichen WAN-IP. Die private LAN-IP kann von aussen nicht erreicht werden, die öffentliche WAN-IP des Routers allerdings schon. Somit ist es einem Server im Internet auch möglich, eine Antwort an die öffentliche WAN-IP Deines Routers zu schicken. Dieser hat sich die vorherige Umschreibung gemerkt, bekommt das Antwort-Paket zurück und tauscht nun die Ziel-IP (seine öffentliche WAN-IP) wieder gegen die LAN-IP des Clients aus, welcher die Anfrage zuvor gestellt hatte.
Bei PiVPN (bzw. generell) würde es nun wie folgt laufen: Es müsste auf dem PiVPN ein SNAT erstellt werden, welches besagt: Alles was vom VPN-Netz "raus" geht, wird mit der LAN-IP (die IP des Wireguard-Servers im LAN) überschrieben/maskiert. Das hat allerdings den Nachteil, dass Zugriffe im internen Netz (von einem VPN-Client) immer mit der IP des Wireguard-Servers erscheinen. Meldest Du Dich z.B. am Webinterface des Speedport an, kommt der Login dort von der LAN-IP des Wireguard-Servers.
Sind die DNS-Server-Einträge richtig?
Je nachdem, wie Du es gerne hättest. Ich würde auf auf "intern+extern" verzichten und mich entweder nur auf intern beschränken, oder einfach nur auf extern.
Brauchen alle Netzwerkgeräte statische IP-Adressen?
Was genau meinst Du mit Netzwerkgeräte? Im Sinne von PiVPN und statischen Routen dorthin (statische Route auf Speedport für VPN-Netz über Wireguard-Server-IP) wäre alles andere ziemlich sinnfrei. Grundsätzlich "sollten" (nicht "müssen") aber alle Geräte, welche in irgendeiner Form Dienste für andere Netzteilnehmer anbieten, schon feste IP-Adresse haben.
EDIT: Wenn es nicht möglich sein sollte, dass Du statische Routen auf dem Speedport konfigurieren kannst, dann "musst" Du NAT nutzen. Kann aber sein, dass es ggf. sowieso schon genutzt wird. Teste doch erstmal etwas einfaches, z.B. den Zugriff von - via VPN eingewählten Client - auf die 192.168.2.1.
