pro82 schrieb:
Auch wenn ich nun eventuell eine "doofe" Frage stelle, oder "doof" ausdrücke.
Muss es nicht an die Standard-Gateway (in meinen Fall der Router) gehen, da der dies doch an die Gegenstelle zurückschickt?
So doof ist das gar nicht... und prinzipiell ist das ja auch so. Aber wie so oft, liegt die Tücke im Detail. Jedes TCP-Datenpaket beinhaltet gemäß der Beschreibung des Protokolls TCP/IP eine Absender-IP-Adresse und eine Empfänger-IP-Adresse. Jede dieser 2 IP-Adressen enthält weiterhin einen Site-Anteil und einen Machine-Anteil. Alle Geräte mit dem gleichen Site-Anteil können untereinander kommunizieren, eben weil deren Datenpakete in der IP-Adresse alle den gleichen Site-Anteil haben. Alle Datenpakete hingegen, deren Empfänger-Site-Anteil ein anderer als das lokale Netz ist, werden vom Standard-Gateway verarbeitet, im Regelfall also vom DSL-Router, der solche Pakete ins Internet "gibt", damit sie dort den Emfänger erreichen.Aber genau das ist nicht möglich, weil die überlicherweise verwendeten 10.0.0.0/8 VPN-Adressen nicht internettauglich sind.
Damit das aber trotzdem funktioniert, ersetzt der OpenVPN-Server vorher schon die komplette Absender-IP-Adresse der von den VPN-Clients hereinkommenden Pakete durch seiner eigene IP-Adresse und gibt das Paket erst dann weiter. Für alle anderen LAN-Geräte sieht es also so aus, als kämen die TCP-Pakete von dem VPN-Server und nicht von außerhalb, was ja faktisch auf das VPN-Netz zutrifft. Das bedeutet, alle zurückkommenden Antwortpakete gehen also nicht an das Default-GW, sondern kommen wieder zurück zum OpenVPN-Server. Der Server ersetzt dann die Zieladresse des Pakets, die jetzt seine eigene war, wieder mit der des VPN-Clients und es verlässt den Rechner über das virtuelle TUN-Device und erreicht damit den VPN-Client. Den Vorgang nennt man NAT, einmal Source-NAT, einmal Destination-NAT.
Im Endeffekt läufts also in etwa darauf hinaus, dass VPN-TCP-Pakete keine echten TCP-Pakete sind, sondern eigentlich nur Daten-Packages, die mit dem normalen TCP transportiert werden. Erst das virtuelle TUN-Device sowie der damit einhergehende Crypt/Decrypt machen aus dem Daten-Package wieder ein normales TCP-Paket, das dann im lokalen Netz transportiert und von den Geräten verstanden wird. Auf der Reise durchs Internet ist das quasi ein Paket im Paket... 🙄
Das war jetzt hier nur ein grober Umriss, sehr pauschal, ohne genau hinzusehen, ohne den Anspruch auf 100% .... sondern nur um eine vage Vorstellung über die Abläufe zu erwecken. Du findest auf dem Link, den ich Dir zugesandt habe, tiefergehendere Infos.
Diesen Befehl würde ich nun ergänzen
iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d "lokale IP-VPN-Server" -j ACCEPT
Da fehlt dann noch das NAT. Wie ich sagte, Du kannst das auf dem genannten Link nachlesen.Einfach nur wahllos irgendwas nehmen, wird allerdings nicht funktionieren. Man kann das auch mit Routing und Sub-Nets und dann via TAP-Device einrichten, ich halte das aber für komplizierter. Und meine persönliche Meinung dazu ist, wer mangels Verständnis der Zusammenhänge nicht in der Lage ist, seine Zugänge auch wirklich zu kontrollieren, sollte in seinem eigenen Interesse lieber darauf verzichten, somit faktisch unsichere Zugänge vom Internet in sein Heimnetz zu öffnen.