Wie kann ich über OpenVPN einen einzelnen lokalen Computer erreichen?

Question

Dies scheint eine triviale Frage zu sein, aber ich konnte die Antwort noch nicht finden.

In meinem LAN (blau im Bild) habe ich unter anderem ein NAS und einen Raspberry Pi. Auf dem Raspberry Pi habe ich einen OpenVPN-Server installiert. Ich möchte, dass der OpenVPN-Client auf das NAS zugreifen kann, also FTP, HTTP usw. Der Client darf auf keine anderen Maschinen als das Raspberry und das NAS selbst zugreifen können.

In diesem Bild sehen Sie die Topologie meines Netzwerks:

Ich kann den OpenVPN-Client mit seinem Server verbinden. Ich weiß, dass ein Subnetzkonflikt vorliegt, kann die Subnetze aber nicht ändern.

Meine Serverkonfiguration:

port 1194
proto udp
dev tun

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/myserver.crt
key /etc/openvpn/easy-rsa/keys/myserver.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

server 10.8.0.0 255.255.255.0
#push "route 192.168.1.0 255.255.255.0"

ifconfig-pool-persist /etc/openvpn/easy-rsa/ipp.txt

keepalive 10 120
cipher AES-128-CBC
persist-key
persist-tun

status /var/log/openvpn-status.log
#log         /var/log/openvpn.log
log-append  /var/log/openvpn.log
verb 3

Meine Client-Konfigurationsdatei:

client

remote x.y.z.t 1194
proto udp
dev tun

ca /etc/openvpnclient/ca.crt
cert /etc/openvpnclient/client.crt
key /etc/openvpnclient/client.key

cipher AES-128-CBC

#route-method exe
#route-delay 3
#route 10.8.0.0 255.255.255.0
###route-nopull
route 192.168.1.20 255.255.255.255

resolv-retry infinite
nobind
persist-key
persist-tun

mute 20
verb 3

Ich kann mich mit dem Windows-Client verbinden, aber ich kann das NAS nicht anpingen oder darauf zugreifen. Ich bin sicher, dass mir noch etwas fehlt, konnte aber nicht herausfinden, wie ich den Datenverkehr umleiten kann. Ich habe viele Beiträge zu diesem Thema gelesen, aber immer noch kein Glück gehabt.

Ich sollte in der Lage sein, bei Bedarf eine Routing-Regel im Router hinzuzufügen, der über das OpenVPN-Servernetzwerk läuft.

Update 18.11.2019 @17.31 MEZ

Ich habe zwei Hauptanforderungen:

1. Ich möchte, dass der Client das NAS erreicht, aber nicht die anderen Maschinen im LAN.
2. Der Client muss eine Verbindung herstellen können, auch wenn sein Subnetz mit dem NAS-Subnetz in Konflikt steht (z. B. 192.168.1.0/24).

Tom Yan undDieser Artikelhat mir geholfen, eine Lösung für das erste Problem zu finden. Ich glaube, das zweite Problem ist noch nicht gelöst.

Lösung für Problem Nr. 1:

In der Serverkonfiguration musste ich diese Zeile hinzufügen (auskommentieren), um die Weiterleitung von Anfragen vom OpenVPN-Client an das NAS sicherzustellen:

push "route 192.168.1.0 255.255.255.0"

Um das Routing vom NAS zurück zum OpenVPN-Client zu ermöglichen, habe ich diese Routing-Regel hinzugefügtim NAS:

vi /etc/sysconfig/network-scripts/route-eth0

Hinzufügen dieser Zeile in dieser (leeren) Konfigurationsdatei

10.8.0.0/24 via 192.168.1.88

Und es service network restartwurde sichergestellt, dass die statische Route angewendet wird.

Danach habe ich den Verkehr eingeschränktim Raspberry Piüber iptables. Ich habe es tatsächlich dauerhaft installiert iptables-persistentund befolgtdieser Leitfaden.

iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 192.168.1.20 -j ACCEPT

Aktualisierung Nr. 2

Ja, ich brauche viele Clients, die eine Verbindung herstellen können, und ich denke, aus diesem Grund sollte ich NAT und Masquerading vermeiden.

Answer 1

Sie müssen eine Route für 10.8.0.0/24(wo sich das Gateway befinden würde 192.168.1.88, also Rasp.Pider OVPN-Server) entweder zu NASoder hinzufügen ROUTER(vorausgesetzt, in diesem Fall ROUTERist dies natürlich das Standard-Gateway von NAS), damit NAS/ ROUTERweiß, wohin der Antwortverkehr geleitet werden soll.

Wenn dies nicht möglich ist, müssen Sie SNAT/ MASQUERADEmit iptables(oder nftablesnatürlich ) verwenden Rasp.Pi, damit der gesamte Datenverkehr der VPN-Clients so aussieht, als stamme er vom Server.

Der Client darf auf keinen anderen Rechner als den Raspberry und das NAS selbst zugreifen können.

Stellen Sie sicher, dass Sie den Weiterleitungsverkehr mit begrenzen iptables. Sobald Sie die IP-Weiterleitung aktiviert haben Rasp.Pi(das müssen Sie tun, sonst können die VPN-Clients das LAN des Servers nicht erreichen), kann ein Client jede Route hinzufügen, die er/sie braucht, um einen bestimmten Host im LAN des Servers zu erreichen. Wenn Sie also einfach bestimmte Routen nicht pushen, wird Ihnen das nicht helfen.

Aktualisieren:

So aktivieren Sie die IP-Weiterleitung (und machen die Einstellung über den Systemstart hinaus dauerhaft):

sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf

Um nur die Weiterleitungen zuzulassen, die Sie in diesem Fall benötigen ( eth0und tun0von denen angenommen wird):

iptables -F FORWARD
iptables -P FORWARD DROP
iptables -A FORWARD -m conntrack --ctstate NEW -i tun0 -s 10.8.0.0/24 -o eth0 -d 192.168.1.20 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

NASSo führen Sie Source-NAT für die Weiterleitung von Datenverkehr durch (damit Sie die Rückroute nicht auf / konfigurieren müssen ROUTER), der über Folgendes hinausgeht eth0:

iptables -t nat -F POSTROUTING

(überspringen Sie das Obige, wenn Sie noch weitere Regeln in der Kette haben, die Sie ebenfalls benötigen)

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

oder, wenn die IP eth0über einen längeren Zeitraum bzw. mehrere Bootvorgänge hinweg bestehen bleibt:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT 192.168.1.88

PS: Wenn Sie die Tabellen, die Sie berührt haben, leeren möchten, haben Sie folgende Möglichkeiten:

for i in $(cat /proc/net/ip_tables_names); do iptables-restore /usr/share/iptables/empty-"$i".rules; done

Beachten Sie auch, dass iptablesBefehle beim Booten nicht persistent gespeichert werden. Sie sollten die Regeln daher in einer Datei speichern iptables-save(und Ihr System so konfigurieren, dass sie beim Booten irgendwie wiederhergestellt werden).

Aktualisierung 2:

Sie sollten sich unbedingt das oben Gesagte ansehen, um zu erfahren, wie Sie die FORWARDKette (in der filterTabelle) richtig konfigurieren. Ohne die DROPRichtlinie (oder eine „Standard“ DROP-Regel am Ende) ACCEPTwäre jede Regel nutzlos. (Und Ihre Regel würde nicht ausreichen, wenn Sie das DROPTeil erst einmal repariert haben.)

Um Subnetz- (genauer: Routen-)Konflikte zu vermeiden, empfiehlt es sich, eine Host-Route (das ist es, was Sie ohnehin brauchen) anstelle einer Subnetz-Route zu pushen. Das sollten Sie also tun push "route 192.168.1.20 255.255.255.255"(die Subnetzmaske kann eigentlich weggelassen werden), da die Chance, dass ein Client-Host eine Host-Route zu einem LAN-Host (außer dem Standard-Gateway) hat, viel geringer ist (eine Subnetz-Route wird unter Linux immer hinzugefügt, wenn /32einer Schnittstelle eine Nicht-Adresse zugewiesen wird).

Sie können beispielsweise auch push "route 10.8.1.1"und DNATdas Ziel auf 192.168.1.20on setzen, Rasp.Pifür den Sonderfall, dass auf einem Client bereits eine Route existiert (Sie sollten dann immer noch mit darauf 192.168.1.20zugreifen können ):NAS10.8.1.1

iptables -t nat -A PREROUTING -d 10.8.1.1 -j DNAT --to-destination 192.168.1.20