Avenger84 schrieb:
War das korrekt ?
So leitet der Raspberry überhaupt erst anfragen vom internen Netz weiter zum WG-Client PC.
Jein. NAT und im Speziellen masquerade hat nichts mit Routing zu tun, sondern mit der Manipulation der Quell- bzw. Ziel-Informationen, allen voran die IP. Masquerade verpasst beispielsweise jedem Paket, das dieses Interface verlässt die (primäre) IP-Adresse dieses Interfaces als Quell-IP. Klassisches Anwendungsbeispiel wäre der Internetrouter, der alles was den WAN-Port verlässt mit der WAN-IP als Quell-IP versieht, damit computerbase.de überhaupt wissen wohin sie antworten sollen (mit einer privaten 192.168.x.y könnte computerbase.de ja nix anfangen).
Die Befehle, die du da eingegeben hast, maskieren also sämtlichen Traffic, der wg0 bzw. eth0 verlässt mit der wg0- bzw eth0-IP. Somit kann das Ziel des Pakets nicht erkennen ob das Paket von
hinter dieser IP stammt. Wieder das Beispiel mit dem Internetrouter: computerbase.de sieht nur die IP deines Routers, hat aber keine Ahnung davon, dass dahinter dein 9000€ Alienware Laptop sitzt oder die 8 Jahre alte Medion Klapperkiste als B-Ware von ebay für 90€.
NAT sollte in gerouteten Netzwerken inkl. VPN daher stets der letzte Ausweg sein. Man verliert nämlich die Möglichkeit, den Traffic im Zielnetzwerk anhand der Quelle zu unterscheiden, weil alles was aus dem VPN kommt mit der IP des VPN-Gateways maskiert wird und somit de facto als lokaler Traffic aus dem lokalen Netzwerk betrachtet wird (kommt ja von einem lokalen Netzwerkteilnehmer).
Das Zusammenspiel aller beteiligten Router bzw. Gateways ist zwar eigentlich sehr simpel, weil logisch, auf den ersten Blick wirkt es aber auf ungeübte Anwender sehr komplex.
Ich versuche es mal in möglichst kurzen Worten:
In Netzwerk A muss es eine eindeutige Route nach Netzwerk B geben. Der Einfachheit halber kann man diese im Standardgateway implementieren.
Standardgateway A: Route nach Subnetz B via VPN-Gateway im Netzwerk A
Standardgateway B: Route nach Subnetz A via VPN-Gateway im Netzwerk B
Jetzt ist sichergestellt, dass jedes Endgerät in Netzwerk A weiß wo es nach Netzwerk B geht, nämlich über das Standardgateway A und umgekehrt gilt das für alle Endgeräte in Netzwerk B.
Nu muss man aber dem jeweiligen VPN-Gateway noch beibringen, dass es eben als Gateway zum anderen Netzwerk fungiert. Das erfolgt in der Regel über die VPN-Konfiguration (bei OpenVPN zB mit route bzw iroute oder eben mit push route). Bei wireguard weiß ich das mangels persönlicher Erfahrung damit leider nicht wie genau das da funktioniert. So oder so müssen sich VPN-Server und -Client aber darüber austauschen welche Subnetze sie bedienen. Gegebenenfalls muss man das bei wireguard vielleicht sogar über manuelle Einträge in die Routing-Tabelle umsetzen.
Zusätzlich muss das VPN-Gateway jeweils natürlich erst dazu gebracht werden
überhaupt irgenwelche Pakete weiterzuleiten. Das ist zB der Part wo ip-forwarding in der Registry bzw sysctl ins Spiel kommt. Ist das nämlich deaktiviert, werden alle Pakete, die nicht für das Gateway selbst bestimmt sind, in die Tonne getreten.
An dieser Stelle ist das Routing soweit vollständig, ganz ohne NAT/Masquerade. Jetzt kommt der Traffic von PC A via Router A via VPN-GW A via VPN-GW B zu PC B und von dort allerdings nicht denselben Weg zurück, sondern wiederum erst via Router B und dann VPN-GW B, VPN-GW A und PC A, also exakt spiegelverkehrt. Der ankommende Traffic hat dann aber wie gesagt eine "fremde", weil nicht-lokale Quell-IP und muss somit in der Firewall auch freigeschaltet werden wie oben schon beschrieben.
dann sind die Regeln wieder weg.
. (Mit der .74.50 und nicht nur der VPN IP).
