Open VPN - Kein Zugriff auf Netzwerkordner

[Stefan]

Hallo zusammen,

ich habe auch meinem Raspberry Pi ein OpenVPN installiert.
Das Verbinden mit dem OpenVPN klappt und ich komme auch ohne Probleme auf die Internen Webseiten (z.b. Pihole)
Ich habe ein Synology NAS in meinem Netzwerk und habe auf einem Windows 10 Rechner meiner Frau einen Netzwerkordner erstellt.
Lokal komme ich ohne Probleme auf den Ordner, extern natürlich nicht. Deshalb habe ich den OpenVPN Server aufgesetzt um auch von aussen auf diesen Ordner zugreifen zu können.
Es scheint so zu sein, das mein VPN Probleme beim routing hat.
Ich habe einmal die Daten zusammengefasst und würde mich über Tipps sehr freuen.


Mein Router hat die IP 192.168.0.1


Daten vom OpenVPN Server



Hier die server.conf
http://slexy.org/view/s21pX5MVGf
Hier habe ich die
push "dhcp-option DNS 192.168.0.45" auf meinen Pihole umgeleitet um auch unterwegs mit dem OpenVPN meinen Pihole nutzen zu können.


Die openvpn-status.log
https://slexy.org/view/s21gJOLCTW

Code: Alles auswählen

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    202    0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

Code: Alles auswählen

sudo iptables -nvx -L -t nat
Chain PREROUTING (policy ACCEPT 697909 packets, 83852235 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 661467 packets, 76887219 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 23864893 packets, 1431967596 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
   16851  2392990 MASQUERADE  all  --  *      eth0    10.8.0.0/24          0.0.0.0/0            /* openvpn-nat-rule */

Chain OUTPUT (policy ACCEPT 23864893 packets, 1431967596 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Daten vom NAS

Code: Alles auswählen

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

Code: Alles auswählen

sudo iptables -nvx -L -t nat
Password: 
Chain PREROUTING (policy ACCEPT 31095 packets, 4536688 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 17134 packets, 3508351 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
   17316  3572125 DEFAULT_POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 17316 packets, 3572125 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain DEFAULT_POSTROUTING (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
     182    63774 MASQUERADE  all  --  *      *       10.8.0.0/24          0.0.0.0/0

ip a

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:32:15:92:c5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.112/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::211:32ff:fe15:92c5/64 scope link 
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN 
    link/sit 0.0.0.0 brd 0.0.0.0
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0

[TomL]

Lokal komme ich ohne Probleme auf den Ordner, extern natürlich nicht. Deshalb habe ich den OpenVPN Server aufgesetzt um auch von aussen auf diesen Ordner zugreifen zu können. Es scheint so zu sein, das mein VPN Probleme beim routing hat.

Ich denke auch, dass das ein Routing-Problem ist. Dabei bin ich mir sicher, dass die von außen via VPN kommenden Pakete durchaus korrekt bei der Synology ankommen, nur werden die Antwortpakete an den VPN-Client mit einer Zieladresse 10.8./16 vom DSL-Router (dessen Netz 192.168./16 ist) via Default-Gateway ins Internet gesendet, und nicht an den VPN-Server. Und im Internet ist natürlich eine Adresse 10.8./16 unbekannt und wird aller Wahrscheinlichkeit einfach verworfen.

Ich halte es für möglich, dass im DSL-Router die Default-Routen für das VPN-Netz vielleicht nicht gesetzt sind.

[Stefan]

Hallo,
ich hoffe das ich dich richtig verstanden habe.
Bei meiner Fritzbox habe ich jetzt die Statische Routingtabelle so eingerichtet, dass
diese auf meinen VPN Server verweist.
Die Einträge:

Code: Alles auswählen

192.168.0.198 (IP OpenVPN)
255.255.255.0
192.168.0.255
Hier können Sie die statische Routing-Tabelle der FRITZ!Box ändern.

Leider hat das bisher keine Änderung gebracht.

[TomL]

Leider hat das bisher keine Änderung gebracht.

Ja... ist klar, das ist ja auch keine Route auf das Netzwerk 10.8.0.0/24. Schau Dir die Settings in meinem Setup an:

[Stefan]

Hallo TomL,

tolle Webseite, bin schwer beeindruckt
Leider bin ich hier vollkommen überfordert.
Auf deiner Seite steht:

Als nächstes sind im DSL-Router noch statische Routen zu setzen. Wir haben es ja hier faktisch mit 3 Netzen zu tun.

Home-Network: 10.0.1.0/24 Gateway: DSL-Router = 10.0.1.1

OpenVPN-Netz via UPD: 10.0.8.0/24 Gateway: OpenVPN-Server = 10.0.1.2

OpenVPN-Netz via TCP: 10.0.9.0/24 Gateway: OpenVPN-Server = 10.0.1.2

Meine Daten
OpenVPNServer

ip route
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.198 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.0.0/24 dev eth0 proto dhcp scope link src 192.168.0.198 metric 202

Synology NAS

ip route
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.8.0.0/24 via 10.8.0.2 dev tun0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.112
default via 192.168.0.1 dev eth0 src 192.168.0.112

Hier meine Daten von der Fritzbox

https://freeimage.host/i/2rtZ6Q

Wie ermittle ich die Werte dich ich in die ins Routing meiner Fritzbox eintragen muss.
Die alten Daten sind falsch und ich verstehe es nicht wie ich jetzt meine Daten in den passenden Wert umrechnen bzw. ermitteln muss.
Würde mich sehr freuen wenn du mir hier helfen könntest.

VG

[TomL]

Eigentlich ist das ganz einfach... oder anders gesagt, das sieht nur verwirrend aus, weil ich zwei VPN-Netze betreibe. Meine Grundlagen sind wie folgt... und ich versuche mal, Deine Daten dahinter zu schreiben.

Code: Alles auswählen

10.0.8.0/24 = VPN UDP                   10.8.0.0/24
10.0.9.0/24 = VPN TCP                   -

10.0.1.0/24 = das normale Hausnetz      192.168.0.0/24
10.0.1.1/24 = die Fritte                192.168.0.1/24
10.0.1.2/24 = der VPN-Server            10.8.0.2/24

Das heißt, im Grunde genommen muss Du in der Fritte nur die eine Route für Dein VPN 10.8.0.0/24 setzen. Wie das geht, kannst Du ja aus dem Screenshot ableiten. Die gleichzeitig vorhandenen Hinweise zu meinem zweiten VPN-Netz kannst Du schlichtweg ignorieren.

Leider bin ich hier vollkommen überfordert.

Da bist Du leider nicht alleine. Die meisten User meinen, sie könnten ohne Sachkenntnis 'ungestraft' ein Portal in ihr Heimnetz öffnen und es wird nix passieren. Tja... ... Gerade das Thema privates Netzwerk und Internet ist sicherheitstechnisch imho eines der anspruchsvollsten überhaupt... und mit einem VPN hantiert man sogar zeitweise gleichzeitig mit mehreren Netzwerken. Aber Deinen Ansatz, das mit OpenVPN zu lösen, halte ich jedenfalls für eine richtig gute Idee und für die derzeit m.M.n. beste Möglichkeit, die Sicherheit seines LANs mit Zugängen vom WWW nicht selber zu kompromittieren.

[Stefan]

Hallo TomL,

leider komme ich nicht weiter, oder ich sehe den Wald vor lauter Bäume nicht mehr.
Wir reden doch über diesen Eintrag:



Hier soll ich deine Daten eintragen, natürlich nur die Daten die du dahinter geschrieben hast:

Code: Alles auswählen

10.0.8.0/24 = VPN UDP                   10.8.0.0/24
10.0.9.0/24 = VPN TCP                   -

10.0.1.0/24 = das normale Hausnetz      192.168.0.0/24
10.0.1.1/24 = die Fritte                192.168.0.1/24
10.0.1.2/24 = der VPN-Server            10.8.0.2/24

Ich habe jetzt versucht, die Daten dort einzutragen.


Bei IPv4-Netzwerk habe ich 10.8.0.0 versucht 10.8.0.0/24 kann ich nicht eintragen
Subnetzmaske 255.255.255.0
Gateway 10.8.0.2
Es kommt dann leider diese Meldung.

Es ist ein Fehler aufgetreten.
Fehlerbeschreibung: Die Route ist nicht zulässig.

Mir ist zum einen noch unklar wie die an die Adressen z.b 10.8.0.0/24 gekommen bist und würde sehr gerne wissen was ich genau in die Fritte eintragen muss damit das Routing auch läuft.
Eventuell kannst du so nett sein und mir diese Liste anpassen:

Bei IPv4-Netzwerk ???
Subnetzmaske 255.255.255.0
Gateway 10.8.0.2

VG

[TomL]

Da kann ich mich jetzt nur entschuldigen... das war mein Fehler....

So ist's nun richtig und auch logisch übereinstimmend mit den Angaben in meiner Doku:

Code: Alles auswählen

10.0.8.0/24 = VPN UDP                   10.8.0.0/24
10.0.9.0/24 = VPN TCP                   -

10.0.1.0/24 = das normale Hausnetz      192.168.0.0/24
10.0.1.1/24 = die Fritte                192.168.0.1/24
10.0.1.2/24 = der VPN-Server            192.168.0.112/24

Als Gateway für das VPN-Netz ist in der Routen-Tabelle der Fritte natürlich die lokale LAN-IP des VPN-Servers einzutragen:

Code: Alles auswählen

Statische IPv4-Route:
IPv4-Netzwerk       10.8.0.0
Subnetzmaske        255.255.255.0
Gateway             192.168.0.112
IPv4-Route aktiv    J

[Stefan]

Hallo TomL

du brauchst dich doch nicht zu entschuldigen, du hilfst mir doch und ich bin darüber sehr dankbar
Ich habe deine Angaben übernommen:

Statische IPv4-Route:
IPv4-Netzwerk 10.8.0.0
Subnetzmaske 255.255.255.0
Gateway 192.168.0.198
IPv4-Route aktiv J

Wobei mein OpenVPN Server unter der Adresse 192.168.0.198 läuft das habe ich geändert.
192.168.0.112 ist mein NAS.

Ich habe das jetzt einmal getestet. Habe mich mit meinem LinuxRechner in mein Freifunk eingewählt, openVPN gestartet und wollte dann auf die Netzwerkordner.
Leider ohne Erfolg.
Dann habe ich einmal Versucht von meinem Linux Rechner im VPN Modus meine Rechner anzupingen

ping 192.168.0.1 (Fritzbox)
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 Bytes von 192.168.0.1: icmp_seq=1 ttl=63 Zeit=210 ms
64 Bytes von 192.168.0.1: icmp_seq=2 ttl=63 Zeit=75.0 ms
64 Bytes von 192.168.0.1: icmp_seq=3 ttl=63 Zeit=73.6 ms

~]$ ping 192.168.0.112 (NAS)
PING 192.168.0.112 (192.168.0.112) 56(84) bytes of data.
64 Bytes von 192.168.0.112: icmp_seq=1 ttl=63 Zeit=60.8 ms
64 Bytes von 192.168.0.112: icmp_seq=2 ttl=63 Zeit=60.0 ms
64 Bytes von 192.168.0.112: icmp_seq=3 ttl=63 Zeit=53.2 ms

--- 192.168.0.112 ping statistics --- (OpenVPNServer)
3 Pakete übertragen, 3 empfangen, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 53.231/57.978/60.752/3.372 ms
[stefan@stefan-manjaro ~]$ ping 192.168.0.168
PING 192.168.0.168 (192.168.0.168) 56(84) bytes of data.
Von 192.168.0.198 icmp_seq=2 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=4 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=5 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=6 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=7 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=8 Zielhost nicht erreichbar
^C
--- 192.168.0.168 ping statistics ---
9 Pakete übertragen, 0 empfangen, +6 Fehler, 100% packet loss, time 8101ms
pipe 4

Meinen OpenVPN Server bekomme ich nicht angepinkt, ist das richtig????

Aus meiner Sicht kann es nun an mehreren Sachen liegen.

• VPN Routing läuft noch nicht richtig.
  Im Synology NAS wird interne VPN Verbindungen unterbunden
  Fehlerhafte Einstellungen beim SMB im NAS

Ich werde zusätzlich noch im Synologyforum diese Punkte einmal ansprechen.

[Stefan]

Hallo TomL

du brauchst dich doch nicht zu entschuldigen, du hilfst mir doch und ich bin darüber sehr dankbar
Ich habe deine Angaben übernommen:

Statische IPv4-Route:
IPv4-Netzwerk 10.8.0.0
Subnetzmaske 255.255.255.0
Gateway 192.168.0.198
IPv4-Route aktiv J

Wobei mein OpenVPN Server unter der Adresse 192.168.0.198 läuft das habe ich geändert.
192.168.0.112 ist mein NAS.

Ich habe das jetzt einmal getestet. Habe mich mit meinem LinuxRechner in mein Freifunk eingewählt, openVPN gestartet und wollte dann auf die Netzwerkordner.
Leider ohne Erfolg.
Dann habe ich einmal Versucht von meinem Linux Rechner im VPN Modus meine Rechner anzupingen

ping 192.168.0.1 (Fritzbox)
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 Bytes von 192.168.0.1: icmp_seq=1 ttl=63 Zeit=210 ms
64 Bytes von 192.168.0.1: icmp_seq=2 ttl=63 Zeit=75.0 ms
64 Bytes von 192.168.0.1: icmp_seq=3 ttl=63 Zeit=73.6 ms

~]$ ping 192.168.0.112 (NAS)
PING 192.168.0.112 (192.168.0.112) 56(84) bytes of data.
64 Bytes von 192.168.0.112: icmp_seq=1 ttl=63 Zeit=60.8 ms
64 Bytes von 192.168.0.112: icmp_seq=2 ttl=63 Zeit=60.0 ms
64 Bytes von 192.168.0.112: icmp_seq=3 ttl=63 Zeit=53.2 ms

ping 192.168.0.168 (OpenVPN)
PING 192.168.0.168 (192.168.0.168) 56(84) bytes of data.
Von 192.168.0.198 icmp_seq=2 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=4 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=5 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=6 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=7 Zielhost nicht erreichbar
Von 192.168.0.198 icmp_seq=8 Zielhost nicht erreichbar
^C
--- 192.168.0.168 ping statistics ---
9 Pakete übertragen, 0 empfangen, +6 Fehler, 100% packet loss, time 8101ms
pipe 4

Meinen OpenVPN Server bekomme ich nicht angepinkt, ist das richtig????

Aus meiner Sicht kann es nun an mehreren Sachen liegen.

• VPN Routing läuft noch nicht richtig.
  Im Synology NAS wird interne VPN Verbindungen unterbunden
  Fehlerhafte Einstellungen beim SMB im NAS

Ich werde zusätzlich noch im Synologyforum diese Punkte einmal ansprechen.

[TomL]

An dem Punkt wirds natürlich schwierig... und mein Vorgehen ist bei solchen Problemen immer eine systematische Diagnose durchzuziehen.

Das erste wäre, den Start von OpenVPN zu prüfen... und zwar nicht als Dienst, sondern manuell. Das heisst, der beim Start des Rechners erfolgte Start des VPN-Service muss im laufenden System beendet werden. Dazu musst Du herausfinden, wie OpenVPN maschinell gestartet wird... hier als Beispiel:

Code: Alles auswählen

# systemctl -l | grep -i vpn
   openvpn.service             loaded active exited    thlu:openvpn.service   Start OpenVPN-Daemons for TCP and UDP                   

# systemctl status openvpn.service
   ● openvpn.service - thlu:openvpn.service   Start OpenVPN-Daemons for TCP and UDP
   Loaded: loaded (/etc/systemd/system/openvpn.service; enabled; vendor preset: enabled)
   Active: active (exited) since Sun 2020-09-06 11:55:18 CEST; 1 months 3 days ago
   Process: 610 ExecStart=/bin/systemctl start openvpn@server_udp.service (code=exited, status=0/SUCCESS)
   Process: 742 ExecStart=/bin/systemctl start openvpn@server_tcp.service (code=exited, status=0/SUCCESS)
   Main PID: 742 (code=exited, status=0/SUCCESS)

# systemctl stop openvpn.service

Das wird bei Dir anders aussehen... aber das musst Du halt herausfinden. Als nächstes wird Openvpn auf dem Server manuell gestartet, natürlich mit dem Namen Deiner server.conf:

Code: Alles auswählen

# openvpn --config /etc/openvpn/server_udp.conf

Das gleiche auf dem Client-PC... der muss sich aber außerhalb des eigenen lokalen Netzwerks befinden... also via Smartphone-Tethering oder auch Freifunk.

Code: Alles auswählen

# openvpn --config /etc/openvpn/client_udp.conf

Ohne zunächst weiter etwas zu tun, solltest Du mal die beiden Anfangs-Ausgaben posten, um zu bestätigen, dass VPN auf beiden Seiten korrekt gestartet wird und das keine Fehler beim Start des Service oder beim Verbindungsaufbau berichtet werden.

[Stefan]

Hallo TomL,

ich habe gestern Abend im Synology Forum nach diesem Problem gesucht, leider sind wird das Thema Routing dort nicht aktiv bespielt.
Ich habe versucht einmal deine Idee umzusetzen.
Hier erst mal meine Ausgaben:

systemctl -l | grep -i vpn

openvpn.service loaded active exited OpenVPN service
openvpn@server.service loaded active running OpenVPN connection to server
system-openvpn.slice loaded active active system-openvpn.slice

systemctl status openvpn.service

● openvpn.service - OpenVPN service
Loaded: loaded (/lib/systemd/system/openvpn.service; enabled; vendor preset: enabled)
Active: active (exited) since Sat 2020-10-10 21:23:01 BST; 13h ago
Process: 17505 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 17505 (code=exited, status=0/SUCCESS)

Oct 10 21:23:01 raspberrypi systemd[1]: Starting OpenVPN service...
Oct 10 21:23:01 raspberrypi systemd[1]: Started OpenVPN service.

Danach habe ich versucht den Dienst zu beenden.

sudo systemctl stop openvpn.service

Dieser Befehl reicht nach deiner Meinung ja nicht aus.

sudo /etc/init.d/openvpn stop
[ ok ] Stopping openvpn (via systemctl): openvpn.service.

Ich habe dann mit

sudo openvpn --config /etc/openvpn/server.conf
^CRTNETLINK answers: Operation not permitted

versucht meinen OpenVPN zu starten - etc/openvpn/server.conf sind meine Daten.
Leider wird mir dann nichts angezeigt.
Auch wenn ich mich von einem Client aus anmelde.

VG Stefan

[TomL]

Danach habe ich versucht den Dienst zu beenden.

Code: Alles auswählen

sudo systemctl stop openvpn.service

Dieser Befehl reicht nach deiner Meinung ja nicht aus.

Code: Alles auswählen

sudo /etc/init.d/openvpn stop
[ ok ] Stopping openvpn (via systemctl): openvpn.service.

Doch, natürlich... "systemctl stop" reicht nicht nur aus, das ist imho sogar das richtige Vorgehen. Das alte init.d-Script und "service stop" ist seit 2015 eigentlich obsolet, obwohl auch das noch funktioniert. Ich verwende seit Jahren weder so ein unnötiges Script noch dieses veraltete Statement.

Ich habe dann mit

sudo openvpn --config /etc/openvpn/server.conf
^CRTNETLINK answers: Operation not permitted

versucht meinen OpenVPN zu starten - etc/openvpn/server.conf sind meine Daten. Leider wird mir dann nichts angezeigt.

Das ist ein weiteres Problem, bei dem ich einen Bedienungsfehler nicht ausschließen kann. Du solltest unter Debian diesen 'sudo'-Mist nicht verwenden. Unter Debian ist eigentlich eine andere Vorgehensweise empfohlen, Debian hat diesen aus der buntu-Szene kommenden Missbrauch von sudo nicht eingeführt. Hier an der Stelle kann ich nicht ausschließen, dass zwar 'openvpn' mit sudo gestartet wird, aber dass der Folgeprozess zur dynamischen Generierung des tun-Devices fehlschlägt, weil entweder /usr/sbin-Programme wegen sudo und möglicherweise fehlerhaften Environment nicht gefunden werden oder das das wirklich ein Rechteproblem ist.

Melde Dich also einfach als "root" an, mit einem echten Root-Password und dann kannst Du alle sudo-Berechtigungen entfernen.... zumal ich sudo sowieso für ein unkalkulierbares Sicherheitsrisiko halte. Gibt es bisher kein root-Password, musst Du es halt vergeben.

Wie sehen die Devices aus, nachdem Du openvpn manuell beendet hast ...?... und zwar alles OHNE sudo

Code: Alles auswählen

$ su - 
# systemctl stop openvpn.service
# ip a
# openvpn --config /etc/openvpn/server.conf 

Wenn das tun-Device nach dem manuellen Beenden des Services jetzt nicht mehr vorhanden ist und der manuelle Start im Vordergrund von OpenVPN dieses Device nicht wieder neu erzeugt, kein Problem, dann muss es eben einmal von Hand erstellt werden. Dann würde der vorherige letzte Schritt nun so aussehen:

Code: Alles auswählen

# openvpn --mktun --dev tun
# openvpn --config /etc/openvpn/server.conf 

Auch wenn ich mich von einem Client aus anmelde.

Auf solche Experimente mit wechselnden Systemen solltest Du bei der Fehlerdiagnose unbedingt verzichten. Zuerst wird EIN System (und zwar der Server) so hingestellt, dass der Start des Services keinerlei Fehlermeldungen mehr verursacht. Irgendein Client-System ist an dieser Stelle völlig unerheblich und vergrößert nur die Verwirrung. Wir müssen jetzt feststellen, ob der Server Fehler zeigt, was ein Client davon hält ist irrelevant.

[Stefan]

Hallo TomL,

wie ich in meinem ersten Post geschrieben habe, läuft der OpenVPN Server auf meinem Raspberry Pi.
Ich habe hier das Raspberry Pi OS (32-bit) Lite installiert, deshalb die ganzen sudo Befehle.
Als VPN Client habe ich meine Debian am laufen, sowie ein Windows 10 meiner Frau.

Sorry für die verwirrenden Informationen.
VG

[TomL]

...läuft der OpenVPN Server auf meinem Raspberry Pi. Ich habe hier das Raspberry Pi OS (32-bit) Lite installiert, deshalb die ganzen sudo Befehle.

Das ist durchaus eine gute Wahl für diesen Zweck. Ein Pi mit u.a. dieser Aufgabe hat bei mir mehrere Jahre perfekt und wirklich störungsarm gearbeitet. Und die Wahl auf 'lite' habe ich für mich immer als Wahl auf 'Debian für ARM' übersetzt, denn Du wirst dabei mit dem nackten Linux-OS vermutlich kaum irgendwelche Unterschiede zum richtigen Debian feststellen. Mir ist nur unerklärlich, warum die Maintainer diesen Sudo-Sch***ß mitmachen... Debian ist doch eine wirklich gute Vorlage, um es eigentlich besser machen zu können. Aber es hat keinen Einfluss auf die Feststellung, dass man 'lite' problemlos auch ohne sudo betreiben kann.

[Stefan]

Hallo TomL,

jetzt muss ich mich entschuldigen, ich habe auf dem Windows 10 meiner Frau die IP Adresse nicht statisch vergeben
Jetzt habe ich die IP über die fritzbox fest vergeben und siehe da es geht.
Ich danke dir sehr für deine Intensive und sehr nette Unterstützung. Das findet man heute im Netz leider immer weniger.

Ich hätte aber noch eine Frage und ich hoffe das du mir diese beantworten kannst .

Code: Alles auswählen

10.0.8.0/24 = VPN UDP                   10.8.0.0/24
10.0.9.0/24 = VPN TCP                   -

10.0.1.0/24 = das normale Hausnetz      192.168.0.0/24
10.0.1.1/24 = die Fritte                192.168.0.1/24
10.0.1.2/24 = der VPN-Server            192.168.0.112/24

Wie hast du diese Werte bekommen bzw. errechnet.
Das würde mich noch sehr interessieren.

VG Stefan

[TomL]

Wie hast du diese Werte bekommen bzw. errechnet. Das würde mich noch sehr interessieren.

Ich habe die Frage schon beim ersten Mal gelesen und war ratlos, was sie meinen könnte. Und jetzt beim zweiten Mal bin ich wieder ratlos, was sie meint.....

Das Netzwerk 192.168.0.0/24 ist das Netzwerk Deines DSL-Routers.... das ist vermutlich die Defaulteinstellung des Herstellers dieses Routers. Ich habe das bei mir manuell auf 10.0.1.0/24 geändert. Und das Netzwerk 10.8.0.0/24 ist das Default-Netzwerk von OpenVPN, default insofern, dass die meisten Tutorials dieses verwenden. Auch das habe ich hier bei mir passend zu meinen eigenen Namenskonventionen ebenfalls manuell geändert. Also gerechnet habe ich da nichts.... sind bei mir alles manuelle Vorgaben.

Und was Deine 192.168'er Adressen angeht... die kann man doch aus den Angaben in Deinen Postings herauslesen. Ob das bei Dir wirklich /24'er Netze sind...?....habe ich geraten, weil das eher die Regel ist ... sofern Fachleute sich nicht spezialkonfigurationen hinstellen. Was das alles mit der Subnet-Mask auf sich hat, kannst Du hier in diesem für IT-ferne Laien gedachten Umbau-Tutorial auf den ersten paar Seiten nachlesen. Das sind elementare Basics und wirkliches Laien-Niveau.

Wenn noch was unklar ist, frag ruhig.