Ich habe das Gefühl, dass mir etwas fehlt, da ich mein OpenVPN seit vielen Jahren mit Debian-, Fedora- und Macintosh-Clients verwende. Ich hatte nie Probleme, auf Freigaben in meinem Heim-LAN zuzugreifen, in dem sich mein OpenVPN-Server befindet.
Ich kann problemlos auf SMB, AFP und NFS zugreifen.
Aber in letzter Zeit verwende ich mein OpenVPN auf einem Windows 7-Client und kann auf keine Freigaben zugreifen.
Beispielsweise verfügt mein Synology NAS unter der Adresse nas.mylan.local über die drei Freigaben, die ich aufgelistet habe, und ich kann mich bei seiner Weboberfläche anmelden und es vom Windows-Client aus mithilfe von nas und nas.mylan.local auflösen, aber ich kann nicht auf die Freigaben zugreifen.
Ich habe es beispielsweise mit \nas\Downloads und \nas.mylan.local\Downloads versucht und versucht, es über das Netzwerk und das Freigabecenter zu ermitteln.
Wenn ich den direkten Pfad angebe, erhalte ich eine Anmeldeaufforderung. Der Windows-Client, mit dem ich dies gemacht habe, war per AD mit einem anderen Unternehmen verbunden, daher gebe ich \Benutzername ein, um die Domäne zu negieren.
Das Kennwort funktioniert in der Web-Benutzeroberfläche, aber in der Freigabeaufforderung erhalte ich eine Fehlermeldung, die etwa lautet: „Der Benutzer darf von diesem Computer aus nicht zugreifen.“
Das von OpenVPN verwendete Tap-Gerät befindet sich im öffentlichen Bereich. Deshalb bin ich in die Windows-Firewall gegangen und habe versucht, meine LAN-Adressen und meine VPN-Adresse zur Liste der zulässigen öffentlichen IP-Adressen des SMB in der Regel für den öffentlichen Bereich hinzuzufügen.
Aber nichts da. Außerdem fiel mir später auf, dass die Windows-Firewall doch deaktiviert war.
Ich habe auch versucht, in die Optionen zur Bereichsfreigabe zu gehen und die Zulassung für eingehende Freigabeanforderungen im öffentlichen Bereich festzulegen.
Was ist los mit Windows 7 und dem Teilen über OpenVPN? Ich gehe davon aus, dass es sich um eine Sicherheitsfunktion von Microsoft handelt, die mich daran hindert, auf meine Freigaben zuzugreifen, da alle anderen Clients einwandfrei funktionieren.
Dies ist die OpenVPN-Serverkonfiguration, die ich seit einigen Jahren verwende. Davor war sie auf einem Debian-Server etwas anders.
server 10.8.0.0 255.255.255.0
port 1194
proto udp
dev tun0
comp-lzo
keepalive 10 120
tls-auth minserver_static.key 1
ifconfig-pool-persist ipp.txt
persist-key
persist-tun
user openvpn
group openvpn
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN domain.local"
ca ca.crt
cert minserver.crt
key minserver.key
dh dh2048.pem
#status /var/log/openvpn/openvpn-status.log
#log-append /var/log/openvpn.log
#verb 3
Hier ist die betreffende Windows 7-Clientkonfiguration. Sie ist genau wie meine Linux-, Mac- und Android-Konfigurationen. Ich habe Bash-Skripte und Vorlagen, die die Konfigurationen generieren, aber ich habe die Zertifikate und Schlüssel hier weggelassen.
client
dev tun
proto udp
remote minserver 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
resolv-retry infinite
comp-lzo
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN domain.local"
# Comment this for the ovpn config
;tls-auth minserver_static.key 0
;ca ca.crt
;cert .crt
;key .key
<ca>
...
</ca>
...
Mein iptables-Setup auf dem Server ist sehr einfach, nur diese Regeln.
sudo firewall-cmd --add-service=openvpn
sudo firewall-cmd --permanent --zone=trusted --add-interface=tun0
sudo firewall-cmd --permanent --zone=trusted --add-masquerade
sudo firewall-cmd --permanent --direct --passthrough ipv4 -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
sudo firewall-cmd --reload
Ich bezweifle, dass es sich hier um ein Problem mit dem OpenVPN-Server handelt. Wahrscheinlicher ist, dass es an Windows liegt.