Stündliche Trennung vom OpenVPN-Server

Ich habe ein ziemlich seltsames Problem mit meiner OpenVPNKonfiguration. Ich verbinde mich Windows 7mit dem offiziellen neuesten OpenVPNClient mit meinem OpenVPNServer ( OpenVPN 2.1.4 i386-redhat-linux-gnu).

Das Problem ist, dass ich OpenVPNgenau nach 1 Stunde von meinem Server getrennt werde und nicht verstehen kann, welche Direktive / Option dafür verantwortlich ist. Vielleicht ist es ein Kundenproblem? Ich habe verschiedene WindowsSysteme und Windows VPNClients ausprobiert . Die LinuxClients arbeiten wie erwartet ohne Unterbrechungen.

Könnten Sie mir bitte helfen, dieses Problem zu beheben? Ich habe versucht, Bücher zu lesen und zu googeln, und einige Leute raten, mit keepaliveund reneg-secAnweisungen zu spielen . Das scheint aber nicht zu helfen.

OpenVPN-Serverkonfiguration

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 192.168.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.0.0.0 255.0.0.0"
client-config-dir ccd
route 192.168.51.0 255.255.255.0
keepalive 60 600
reneg-sec 5000
hand-window 15
tls-auth ta.key 0
comp-lzo
max-clients 50
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
crl-verify crl.pem
management localhost 11111
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login
push "dhcp-option DNS 192.168.2.1"
push "dhcp-option DOMAIN example.com"
push "dhcp-option SEARCH example.com"

Serverprotokoll (ist das Problem nicht in reinit_src = 1?)

Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
Oct  9 07:24:53 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS key negotiation failed to occur within 15 seconds (check your network connectivity)
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 [UNDEF] Inactivity timeout (--ping-restart), restarting
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 SIGUSR1[soft,ping-restart] received, client-instance restarting

Client-Protokoll

RwrWRwRwRwRwTue Oct 09 07:26:39 2012 us=796000 TLS: soft reset sec=0 bytes=7405621/0 pkts=9459/0
Tue Oct 09 07:26:39 2012 us=600000 ERROR: could not read Auth username from stdin
Tue Oct 09 07:26:39 2012 us=600000 Exiting
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 192.168.2.1 MASK 255.255.255.255 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 10.0.0.0 MASK 255.0.0.0 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 Closing TUN/TAP interface

Vielen Dank.

Der Schuldige scheint Ihre Authentifizierungskonfiguration zu sein. Sie verwenden plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login, für die der Client eine gültige Kombination aus Benutzername und Kennwort angeben muss, um eine Verbindung herzustellen. Anscheinend ist dies auch beim erneuten Eingeben erforderlich, und Ihr OpenVPN-Client scheint nicht in der Lage zu sein, den Benutzernamen von stdin( ERROR: could not read Auth username from stdin) anzufordern .

Der Grund, warum das Erhöhen von reneg-sec in Ihrer Serverkonfiguration nicht hilfreich ist, liegt darin, dass der Parameter sowohl in der Server- als auch in der Clientkonfiguration angegeben werden muss, um effektiv über den Standardwert von 3600 Sekunden angehoben zu werden (was passiert) verursachen die eine Stunde - trennen Sie die Verbindung, die Sie sehen).

Ihre Optionen wären also zu

• Verwenden Sie eine Authentifizierungsmethode, für die keine Benutzereingaben erforderlich sind (Zertifikate sind in den Sinn gekommen).
• Problembehandlung, warum Ihr Client nach dem Verbindungsaufbau nicht nach der Kombination aus Benutzername und Kennwort fragen kann
• Erhöhen Sie die Wiederholungszeit oder deaktivieren Sie die Neuverschlüsselung vollständig (was die Sicherheit Ihrer Verbindung schwächt, sodass dies sicherlich nur eine minderwertige Problemumgehung für Ihr Problem darstellt).

Sie können versuchen, reneg-sec 0in Ihrem server.conf:

https://duo.com/docs/openvpn

https://tldrify.com/m80

es ist wirklich ganz einfach. Da OpenVPN standardmäßig alle 3600 Sekunden versucht, eine neue TLS-Sitzung neu zuzuordnen, müssen Sie sich jedes Mal mithilfe eines neuen OTP erneut authentifizieren. Um diese Art von Verhalten zu vermeiden, muss openvpn lediglich angewiesen werden, eine TLS-Sitzung niemals neu zu verknüpfen und die vorhandene Sitzung am Leben zu erhalten, wenn Sie die keepaliveDirektive kombinieren und reneg-sec 0eine stabile Verbindung ohne jegliche Neuzuordnung herstellen.

Ein ähnlicher Effekt trat auf, als ich meiner Client-Konfiguration die Option 'auth-nocache' hinzufügte. Ich benutze Zertifikate UND eine Kombination aus Benutzername und Passwort, um mich zu authentifizieren.

Einige Male habe ich in den Verbindungsprotokollen festgestellt, dass openvpn die folgende Warnung gemeldet hat:

WARNUNG: Diese Konfiguration kann Kennwörter im Speicher zwischenspeichern. Verwenden Sie die Option auth-nocache, um dies zu verhindern

Also dachte ich, ich füge einfach diese Option hinzu und sehe, was passiert. Nun, die obige Warnung verschwindet, aber nach einer Stunde tauchte ein Dialogfeld auf, in dem ich nach meinem Benutzernamen und Passwort gefragt wurde.

Ich habe festgestellt, dass die obige Konfiguration von Andrew diese Option nicht enthält, daher bin ich ein wenig verwirrt darüber, warum das Passwort nicht zwischengespeichert wird. Möglicherweise liegt dies daran, dass ich eine neuere Version von openvpn verwende, oder es kann in der Serverkonfiguration festgelegt werden, um diese Option auf den Client zu übertragen.

Dies wurde gesehen auf: OpenVPN 2.2.1-8 + deb7u2 mit OpenVPN GUI v5 für Windows.