OpenVPN-Server läuft nicht

  • Habs noch schnell an den Beitrag davor rangehängt gehabt:

    Code
    root@raspberrypi:/var/log# cat /etc/group | grep -iE 'openvpn|nogroup|nouser'
    nogroup:x:65534:

    Er hat anscheinend nur für nogroup eine GID

    OK, dann versuch mal mit dem user "nobody" und mit der group "nogroup":

    Code
    id nobody

    oder du erstellt den user und die group openvpn:

    Code
    sudo addgroup --system --no-create-home --disabled-login --group openvpn
    sudo adduser --system --no-create-home --disabled-login --shell /bin/false --ingroup openvpn openvpn 

    (oder gleichwertig). Und mit dem 10.8.0.0/24-er Subnetz.

    EDIT:

    "/bin/false" sollte in die "/etc/shells" eingetragen werden.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    2 Mal editiert, zuletzt von rpi444 (17. März 2019 um 15:15)

  • Mit

    user: nobody

    group: nogroup

    hat er sich aufgehängt. Hier das log nach dem Neustart:

    Und für "$systemctl status openvpn@server":

    Code
    root@raspberrypi:/home/pi# systemctl status openvpn@server
    ● openvpn@server.service - OpenVPN connection to server
       Loaded: loaded (/lib/systemd/system/openvpn@.service; disabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: man:openvpn(8)
               https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
               https://community.openvpn.net/openvpn/wiki/HOWTO

    Ich lege jetzt mal die Gruppen für openvpn an und schreibe das Ergebnis dann hier an diesen Beitrag gleich noch mit ran. Übrigens scheint er nen Zeitsprung gemacht zu haben von 15:13 auf 15:02 bei 308/309 im Log :))

  • Mit

    user: nobody

    group: nogroup

    hat er sich aufgehängt.

    Hast Du es auch mit dem 10.8.0.0/24-er Subnetz probiert?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ja, im Februar hab ich das zwischendurch auch probiert gehabt und ich erinner mich dass damit der Dienst zumindest gelauscht hat. Jetzt hat es aber auch mit dem 10.8.0.0/24 nicht geklappt... Ich würd gern das gleiche Netz wie mein LAN benutzen und irgendwie will mir nicht in den Kopf warum es mit dem 192er nicht auch gehen soll ...

    Aber jetzt hat wohl der PI gerade den Geist aufgegeben... Komme nicht mehr rauf. Ich werde den mal komplett neu aufsetzen und dann ganz von vorne beginnen...

  • Ja, im Februar hab ich das zwischendurch auch probiert gehabt und ich erinner mich dass damit der Dienst zumindest gelauscht hat. Jetzt hat es aber auch mit dem 10.8.0.0/24 nicht geklappt... Ich würd gern das gleiche Netz wie mein LAN benutzen und irgendwie will mir nicht in den Kopf warum es mit dem 192er nicht auch gehen soll ...

    Es hat nicht geklappt weil das mit user und group nicht OK war.

    Das 10.8.0.0/24-Netz ist ein Zwischen-Netz für die tun-Interfaces und aus diesem Zwischennetz wird ja in dein LAN geroutet.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ich hab jetzt den Raspberry neu aufgesetzt und OpenVPN auch ... und voila:

    Code
    Options error: --key fails with '/etc/openvpn/easy-rsa/keys/server.key': No such file or directory
    Options error: Please correct these errors.
    Use --help for more information.
    Options error: --dh fails with '/etc/openvpn/easy-rsa/keys/dh2048.pem': No such file or directory
    Options error: --ca fails with '/etc/openvpn/easy-rsa/keys/ca.crt': No such file or directory
    Options error: --cert fails with '/etc/openvpn/easy-rsa/keys/server.crt': No such file or directory
    Sun Mar 17 21:34:23 2019 WARNING: cannot stat file '/etc/openvpn/easy-rsa/keys/server.key': No such file or directory (errno=2)
    Options error: --key fails with '/etc/openvpn/easy-rsa/keys/server.key': No such file or directory
    Options error: Please correct these errors.
    Use --help for more information.

    Die keys-directory verschwindet zwischendurch und taucht dann wieder auf... Wird die Uhrzeit sein. Morgen nochmal ganz in Ruhe.

  • Ich hab jetzt den Raspberry neu aufgesetzt und OpenVPN auch ...

    Das neuaufsetzen deines PIs wäre nicht erforderlich gewesen.

    Was hast Du an deinem OpenVPN jetzt anders konfiguriert?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ich musste ihn neu aufsetzen, weil der PI nicht mehr hochgefahren ist.

    Ich habe jetzt das 10.8.0.0/24 Netz für das VPN genommen. Den Rest habe ich so gelassen. Habe entgegen meiner Ankündigung doch noch bissl weitergemacht und das mit den keys hat sich erledigt.

    Und er "lauscht":

    Mir will nur nicht in den Kopf, warum das nicht mit dem 192er - Netz funktioniert.

    Muss ich jetzt eigentlich noch was an den iptables ändern, weil mein LAN ein ganz anderes Netzadresse hat oder routet er das automatisch? Hier ist das Ergebnis von "$ route -n":

    Code
    Ziel            Router          Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.2.1     0.0.0.0         UG    202    0        0 eth0
    10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
    10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    192.168.2.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

    Sieht eigentlich so aus, als würde er das vom 10.8.0.0 ins 192.168.2.0 routen, oder?

    Na, ich schau morgen mal nach.

    Einmal editiert, zuletzt von chrisgu (17. März 2019 um 22:21)

  • Muss ich jetzt eigentlich noch was an den iptables ändern, weil mein LAN ein ganz anderes Netzadresse hat oder routet er das automatisch?

    Siehe im UU-Wiki (dessen link ich gepostet habe) die iptables-Regeln für masquerading (source-NAT).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Die hab ich im "rpivpn"-script schon drin gehabt:

    Code
    iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -t nat -F POSTROUTING
    iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

    was ich noch in die "openvpn.conf" eingefügt habe ist:

    Code
    push "route 192.168.2.0 255.255.255.0"

    Hier das Ergebnis von "$ systemctl status openvpn@openvpn":

    Soweit sieht es ganz gut aus. Hier ist der letzte Mitschnitt aus dem log:

    Ich habe einen Client angelegt gehabt, dem scheint er die 10.8.0.2 als Adresse gegeben zu haben (Zeile 10).

    $ ifconfig -a zeigt mir ein neues Interface:

    Code
    tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500 
    inet 10.8.0.1  netmask 255.255.255.255  destination 10.8.0.2
    inet6 fe80::d3cc:ab9b:64d1:bc7c  prefixlen 64  scopeid 0x20<link>
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100

    Das "tun0" lässt sich auch anpingen ($ ping 10.8.0.1)

    Und "$ route -n" zeigt:

    Code
           Ziel       Router         Genmask   Flags Metric  Iface
        
        0.0.0.0  192.168.2.1         0.0.0.0    UG   202  eth0
       10.8.0.0     10.8.0.2   255.255.255.0    UG     0  tun0
       10.8.0.2      0.0.0.0   255.255.255.255  UH     0  tun0
    192.168.2.0      0.0.0.0   255.255.255.0     U   202  eth0

    Als nächstes werde ich dann die Portweiterleitung auf meinem Router einrichten. DDNS lasse ich zum Testen erstmal weg (die IP ist ja mindestens 24 Stunden dieselbe, das genügt, um mal testweise aus einem WLAN draußen die Verbindung zu probieren) ... DDNS richte ich erst ein, wenn alles funktioniert.

    Danke dir für die Hilfe!

    Mal schauen, wie es weiter läuft, ich werde berichten...

    3 Mal editiert, zuletzt von chrisgu (19. März 2019 um 22:08)

  • Ein kurzes Update: Die Verbindung zum Server hat zwar geklappt, aber der TLS-Handshake nicht. Der Fehler, der angezeigt wird, ist:

    Code
    - VERIFY_ERROR: depth=1, error=self signed certificate in certificate chain: C=DE, ST=CA, L=SanFrancisco, O=Fort-Funston,  OU=MyOrganizationalUnit, CN=OpenVPN,  name=EasyRSA, emailAddress=me@myhost.mydomain
    
    -OpenSSL: error1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
    
    -TLS_ERROR: BIO read tls_read_plaintext error
    
    -TLS Error: TLS object -> incoming plaintext read error
    
    -TLS Error: TLS handshake failed

    Auf der Server-Seite zeigt "$ cat /var/log/openvpn-status.log":

    Die Verbindung kommt auf jeden Fall zustande, das zeigt auch der Client an.

    Aber der Client scheint das selbstsignierte Zertifikat der CA nicht zu akzeptieren... Hier sind die Details zu Aussteller und Empfänger von "ca.crt" und "smartphone.crt":

    >> openssl x509 -subject -issuer -noout -in /etc/openvpn/easy-rsa/keys/ca.crt

    Code
    subject=C = DE, ST = CA, L = SanFrancisco, O = Fort-Funston, OU = MyOrganizationalUnit, CN = OpenVPN, name = EasyRSA, emailAddress = me@myhost.mydomain
    issuer=C = DE, ST = CA, L = SanFrancisco, O = Fort-Funston, OU = MyOrganizationalUnit, CN = OpenVPN, name = EasyRSA, emailAddress = me@myhost.mydomain

    >> openssl x509 -subject -issuer -noout -in /etc/openvpn/easy-rsa/keys/smartphone.crt:

    Code
    subject=C = DE, ST = CA, L = SanFrancisco, O = Fort-Funston, OU = MyOrganizationalUnit, CN = smartphone, name = EasyRSA, emailAddress = me@myhost.mydomain
    issuer=C = DE, ST = CA, L = SanFrancisco, O = Fort-Funston, OU = MyOrganizationalUnit, CN = OpenVPN, name = EasyRSA, emailAddress = me@myhost.mydomain

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!