ubuntuusers.de

OpenVPN: TLS handshake failed

Status: Ungelöst | Ubuntu-Version: Server 11.04 (Natty Narwhal)
Antworten |

alias5000

Anmeldungsdatum:
26. Dezember 2006

Beiträge: 51

Hallo zusammen,

ich versuche derzeit, einen OpenVPN-Zugang zu meinem Server(-netzwerk) zu schaffen. Dabei habe ich die Anleitung ausm Wiki 1:1 genutzt, allerdings mit dieser Abweichung: ich habe einen anderen Port gesetzt.

Wenn ich nun auf dem Client openvpn aktivieren möchte (

1
openvpn pfad/zur/client.conf

), bekomme ich folgende Logeinträge in die syslog-Datei geschrieben:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
Tue Sep 13 22:38:28 2011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Sep 13 22:38:28 2011 TLS Error: TLS handshake failed
Tue Sep 13 22:38:28 2011 TCP/UDP: Closing socket
Tue Sep 13 22:38:28 2011 SIGUSR1[soft,tls-error] received, process restarting
Tue Sep 13 22:38:28 2011 Restart pause, 2 second(s)
Tue Sep 13 22:38:30 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Sep 13 22:38:30 2011 Re-using SSL/TLS context
Tue Sep 13 22:38:30 2011 LZO compression initialized
Tue Sep 13 22:38:30 2011 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Sep 13 22:38:30 2011 Socket Buffers: R=[114688->131072] S=[114688->131072]
Tue Sep 13 22:38:30 2011 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Sep 13 22:38:30 2011 Local Options hash (VER=V4): '41690919'
Tue Sep 13 22:38:30 2011 Expected Remote Options hash (VER=V4): '530fdded'
Tue Sep 13 22:38:30 2011 UDPv4 link local: [undef]
Tue Sep 13 22:38:30 2011 UDPv4 link remote: [AF_INET]XXX.XXX.XXX.XXX:50050

Google-Ergebnisse sagen mir, ich sollte die Verbindung zwischen den PCs kontrollieren (ping, hostname, NAT, Firewall), was ich, soweit ich das nachvollziehen kann, getan habe:

  • hostname + port stimmt auf client und server überein

  • ping geht

  • die NAT hat ein Port-Forwarding für den betreffenden udp-Port gesetzt

  • die Firewall des Netzwerkes sollte den Traffic durchlassen. Gibt es eine Möglichkeit, das auch wirklich Ende-zuEnde zu testen?

  • netstat -tulpn sagt mir, dass mein openvpn-Daemon korrekt horcht.

Hätte jemand einen Tipp für mich?

Vielen Dank alias5000

Bearbeitet von barabbas:

IP entfernt

Spelter

Anmeldungsdatum:
10. Januar 2008

Beiträge: 130

Wohnort: Hof

Verdammt, mein erster Text ist weg. Muss jetzt nochmal alles runterrasseln.

Kurzform:

Es sieht aus als ob dein *wo du wohnst* Packete verschluckt. Melde dich auf dem Server per SSH an und starte mal tcpdump:

tcpdump -w server.pcap -i $INTERFACE

Hier musst du das Interface eth0 oder eth1 nehmen, was eben zum öffentlichen Netz hinzeigt.

Auf dem Client das selbe, mit entsprechenden Interface und eine client.pcap.

Diese kannst du vergleichen in Wireshark und nachsehen ob Packete von der Firewall gefiltert wurden.

Unter [1] Seite 28 findest du den Grundlegenden Aufbau eines TLS Handhshakes, unter [2] die Bildform. Es sieht aus als ob nicht genug Informationen ausgetauscht werden konnten um das Hello von Client und Server als sicher anzusehen. Danach käme der Cipher Change und sollte nicht abgehört werden durch eine MITM Attacke.

Zertifikate verwendest du sicherlich wie im Wiki.

In der client.conf von Openvpn kannst du auch mit verb = 5 mal das Debugging einschalten, und bei bedarf am Server. Der Server und Client sollten dafür kein IPTables Regeln laufen haben, sowas kann stören.

Dein Frage zum Ende2Ende Prinzip ist berechtigt, aber schwer zu testen. Man kann es nur an der TTL erkennen das ein Router dazwischen ist, ansonsten keine Chance ohne Zugriff auf die Firewall. Da das *wo du wohnst* dir wohl kaum Zugriff auf den Router/die Firewall geben wird, ist das schwierig und nur durch Netztraffic Analyse zu ermitteln. Um Grundlegend ein Configproblem aus zu schliessen, verbinde dich im LAN mal mit dem Server mit der Internen IP.

Sorry, mein erster Text war länger und ausführlicher um Frage vorzubeugen, aber ich hatte da locker 30 min. dran geschrieben, das geht nicht nochmal ☺ Poste mal die Ausgabe vom Debugging und deine Configs anonymisiert.

Das "Ping geht" bezog sich auf die öffentliche IP?

[1] http://www.ietf.org/rfc/rfc2246.txt [2] http://extendedsubset.com/Renegotiating_TLS_pd.pdf

Bearbeitet von barabbas:

Hinweise auf Standort des Rechners des TEs dezent entfernt.

alias5000

(Themenstarter)

Anmeldungsdatum:
26. Dezember 2006

Beiträge: 51

Spelter, vielen Dank für deinen engagierten Text! Ich bin im Moment noch ein bisschen anderweitig eingespannt, aber ich wollte diese Antwort nicht mit Stille ruhen lassen. Sobald ich mich wieder damit beschäftige, komme ich mit Details.

P.S.: Und ich wundere mich noch, woher du den Standort hast - IP gepostet - autsch! Danke für den Hinweis

Spelter

Anmeldungsdatum:
10. Januar 2008

Beiträge: 130

Wohnort: Hof

Naja, ich dachte mir schon "Warum hat er die IP nicht maskiert?" ☺ Naja, finde es nicht schlimm wenn das jemand weiß, hab ja nicht die genaue Adresse mit Namen reingeschrieben.

Schon weitergekommen mit dem VPN?

barabbas hat den "standort" ja sehr dezent *räusper* entfernt *G* Hätte ich vorher reingesehen, hätte ich es selbst raus. Egal, is draussen und gut isses

alias5000

(Themenstarter)

Anmeldungsdatum:
26. Dezember 2006

Beiträge: 51

Hehe, *wo du wohnst* ☺

Debugging mit Verb = 6 (hatte ich vorher mal so eingeschaltet, bevor du's vorgeschlagen hast) deutet glaube ich auf Kommunikationsprobleme im Netzwerk-Layer hin (es kommen viele Resets). Bin gerade aber viel unterwegs und kann v.a. auch nicht von innen testen. Werde das erst in 1-3 Wochen weiter angehen können, wie es aussieht. Bis dahin ...

P.S.: Soweit ich die Konfiguration der Firewall im Kopf habe, sollte die da in meinem Fall *eigentlich* kein Problem darstellen. Trotz allem wäre es eh keine Option, für mich eine Sonderwurst zu braten 😉

Antworten |