Peter1 Geschrieben 3. November 2011 Teilen Geschrieben 3. November 2011 Hallo zusammen, sorry für die 2 Themen innerhalb zur kurzer Zeit, aber mein Ausgangsproblem hat mit dem nichts mehr zu tun. Also beim Versuch mich mit dem OpenVPN-Server zu verbinden, kommen folgende Fehler: VERIFY ERROR: depth=1, error=self signed certificate in certificate chain TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed TLS Error: TLS object -> incoming plaintext read error TLS Error: TLS handshake failed Nun habe ich im Netz zwei Ursachen gefunden: Zertifikate falsch erstellt: Kann ich prinzipiell ausschließen, da ich es zweimal sehr gewissenhaft mittels XCA gemacht habe (Schlüsselverwaltung mit XCA). Provider ist Schuld: Kann ich eigentlich auch ausschließen, denn ich habe selbiges auch über den Zugang mein Mobiltelefons versucht (heute Abend folgt noch ein dritter Versuch über einen anderen DSL Anschluss). Den ersten Versuch habe ich im übrigen aus der Uni heraus gemacht. Weitere Fehler fallen mir nicht ein...kann mir jemand helfen? config: client dev tun proto udp remote xxxxxxxxxxx pull resolv-retry infinite nobind persist-key persist-tun pkcs12 "C:\\Program Files (x86)\\OpenVPN\\config\\VPN_clientChristoph.p12" pkcs12 "C:\\Program Files (x86)\\OpenVPN\\config\\VPN_CA.p12" ns-cert-type server Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 3. November 2011 Teilen Geschrieben 3. November 2011 Nach der Fehlermeldung zu urteilen hat der Server nicht das richtige CA-Zertifikat um die Signatur zu verifizieren, oder das Client-Zertfikat wurde nicht ordentlich/mit einer anderen CA signiert. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Peter1 Geschrieben 3. November 2011 Autor Teilen Geschrieben 3. November 2011 Ich habe es gerade noch alles kontrolliert. Das müsste eigentlich stimmen. Kann sein, dass der Fehler in der config liegt? Ich habe vorher noch nie mit diesen p12-Dateien gearbeitet. Diese habe ich ja wie oben geschrieben mit pkcs12 [Pfad] in die Config eingebunden. Jetzt fällt mir aber gerade auf, dass der Server oder auch der Client gar nicht wissen in welcher von beiden Dateien sich das CA bzw. das Server/Client Zertifikat befindet. Fehlt da noch ein Befehl z.B. "ca pcks12 [Pfad]"? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 3. November 2011 Teilen Geschrieben 3. November 2011 Das CA-Zertifikat muss ebenfalls im PKCS12-Container stecken. Das pkcs12-Kommando darfst du auch nur einmal benutzen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Peter1 Geschrieben 3. November 2011 Autor Teilen Geschrieben 3. November 2011 Das war auf jeden Fall schon mal ein sehr guter Hinweis, allerdings gibt es jetzt wieder einen Fehler: Server-Log: TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SLL3_GET_CLIENT_CERTIFICATE:no certificate returned TLS Error: TLS handshake failed Client-Log: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) TLS Error: TLS handshake failed Also irgendwie kommt kein Client Zertifikat zurück, wenn ich das richtig interpretiere. Ich habe die Server und Client config entsprechend den Hinweisen bzgl. pcks12 angepasst. Es steht jetzt nur noch einmal in jeder Config. Den Fehler in der Client-Log erkläre ich mir dadurch, dass der Server aus Sicherheitsgründen wahrscheinlich nicht mehr antwortet. Noch eine Idee? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 3. November 2011 Teilen Geschrieben 3. November 2011 Nimm mal "ns-cert-type server" raus, das ist optional. Dann setz mal auf dem Client sicherheitshalber "tls-client". Wenn das nicht hilft, dreh mal das Loglevel über verbose X hoch. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Peter1 Geschrieben 3. November 2011 Autor Teilen Geschrieben 3. November 2011 Super "ns-cert-type server" wars! Was genau bedeutet das? Ich habe in die Server Config nun "push route "192.168.2.0 255.255.255.0"" mit aufgenommen, damit ich auf die Freigaben des NAS (auf dem der VPN Server läuft) zugreifen kann. Das ich das eintragen muss, damit es funktioniert habe ich durchs googlen herausgefunden aber was genau bedeutet dieser Befehl netzwerktechnisch? (Die NAS sitzt hinter einem Router) Ist es nun auch möglich andere Rechner hinter dem Router zu erreichen? Ich vermutet die NAS müsste dann einige Routing Aufgaben übernehmen? Ich möchte jetzt einen zweiten Rechner den Zugriff auf das VPN ermöglichen (auch gleichzeitig). Ist das jetzt ohne weiteres möglich oder müsste ich da die configs verändern? Ich habe schonmal was von bridged und peer-to-peer gehört. Dafür müsste ich auf bridged umstellen oder? Danke für eure Hilfe:-) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 3. November 2011 Teilen Geschrieben 3. November 2011 Super "ns-cert-type server" wars! Was genau bedeutet das? Bei einem X.509 Zertifikat kannst du den Verwendungszweck setzen (z.B. für Webseiten oder Code). "ns-cert-type server" verlangt, das das Zertfikat vom Server auch das Attribut "Server" hat, was bei dir wohl nicht der Fall ist. Ich habe in die Server Config nun "push route "192.168.2.0 255.255.255.0"" mit aufgenommen, damit ich auf die Freigaben des NAS (auf dem der VPN Server läuft) zugreifen kann. Das ich das eintragen muss, damit es funktioniert habe ich durchs googlen herausgefunden aber was genau bedeutet dieser Befehl netzwerktechnisch? (Die NAS sitzt hinter einem Router) Ist es nun auch möglich andere Rechner hinter dem Router zu erreichen? Ich vermutet die NAS müsste dann einige Routing Aufgaben übernehmen? Mit diesem Kommando sagst du dem Client nur, das er das Netzwerk 192.168.2.0/24 über das VPN erreicht, wenn er verbunden ist. Was du sonst noch alles erreichen kannst lässt sich schwer sagen, ohne dein Netzwerk zu kennen. Grundsätzlich gilt, du brauchst immer Hin- und Rückroute. Dem VPN-Client musst du also, z.B. über dieses Push, mitteilen, das das Netz über das VPN zu erreichen ist, aber auch die Systeme in deinem Netz, müssen wissen, wie sie die VPN-Clients, die ja in einem eigenen Subnetz sind, erreichen können. Ich möchte jetzt einen zweiten Rechner den Zugriff auf das VPN ermöglichen (auch gleichzeitig). Ist das jetzt ohne weiteres möglich oder müsste ich da die configs verändern? Ich habe schonmal was von bridged und peer-to-peer gehört. Dafür müsste ich auf bridged umstellen oder? Nein. Bridged und Peer-to-Peer unterscheidet nur, ob du auf Layer 2 (Ethernet) oder auf Layer 3 (IP) eine VPN-Verbindung aufbaust. Normalerweise will man Layer 3, weil das besser zu managen ist, aber manchmal brauch man Layer 2 (bridged). Du kannst in beiden Modi als Server für mehrere Clients konfigurieren. Dazu müsstest du aber mal die gute Doku auf OpenVPN - Open Source VPN lesen, denn das habe ich noch nicht gemacht. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.