VPN und Zwangstrennung Provider

[mat6937]

...
Mon Feb 8 20:19:11 2016 WARNING: file '/etc/openvpn/vusoloms.key' is group or others accessible
Mon Feb 8 20:19:11 2016 WARNING: file '/etc/openvpn/ta.key' is group or others accessible
...

Bei solchen Warnungen musst Du:

Code: Alles auswählen

chmod 600 /etc/openvpn/vusoloms.key

und auf Server und Client:

Code: Alles auswählen

chmod 600 /etc/openvpn/ta.key

ausführen.

[grosser]

hab ich alles gemacht, auch mit Änderung der MTU Werte
Leider ohne Erfolg, nach der Zwangstrennung kommt keine neue Verbindung zu stande.

EDIT: außer den Vorschlag mit dem Port auf dem Router der Clientseite, das kann ich mit der mobilen Anbindung nicht wirklich realisieren.

[orcape]

außer den Vorschlag mit dem Port auf dem Router der Clientseite, das kann ich mit der mobilen Anbindung nicht wirklich realisieren.

Portweiterleitung auf Clientseite ist nicht notwendig.
Du hast "immer noch" einen TLS-Fehler.
Zertifikate überprüfen, evtl. noch mal neu, TLS-Einstellungen prüfen evtl. ändern.
Etwas anderes kannst Du getrost ausschließen.
Der erste Tunnel ? ...ist immer der schwerste.
Da spreche ich aus Erfahrung.

TLS Error

kenne ich.
Gruß orcape

[grosser]

Also scheint es an dem TLS Error zu liegen.

Die Zertifikate komplett überprüfen?
Also für den Server die server.crt, server.csr und die server.key
und beim client die vusoloms.crt, vusoloms.csr und die vusoloms.key

was ist mit der ta.key???

Die hab ich nachträglich, nach den Zertifikaten erstellt. Vielleicht hab ich im Ablauf der Erstellung der Zertifikate einen Fehler gemacht?

[mat6937]

Also scheint es an dem TLS Error zu liegen.

Wenn es ein "TLS-Error" ist, warum dann erst nach der Zwangstrennung und nicht schon vorher? Oder lt. deinen Beiträgen, gibt es auch keinen "TLS-Error", wenn Du nach der Zwangstrennung den openvpn-Client neu startest?

EDIT:

Wenn Du die TTL für deinen ddns-Account bei deinem ddns-Provider anzeigen willst, dann kannst Du z. B.:

Code: Alles auswählen

dnstracer "-4vc" <hostname>.<domian>.<tld> | grep -i ttl

nutzen.

Z. B.:

Code: Alles auswählen

:~$ dnstracer "-4vc" heise.de | grep -i ttl
- TTL:                  2532 (42m12s)

oder:

Code: Alles auswählen

:~$ dnstracer "-4vc" debianforum.de | grep -i ttl
- TTL:                  34933 (9h42m13s)

[grosser]

Das ist eine wirklich gute Frage. Erst nach der Zwangstrennung kommt der TLS Error, da hast du recht.

wollte eben deinen Befehl ausführen

Code: Alles auswählen

dnstracer "-4vc" .......

Da bekomme ich ne Fehlermeldung

Code: Alles auswählen

-bash: dnstracer: Kommando nicht gefunden.

[mat6937]

Da bekomme ich ne Fehlermeldung

Code: Alles auswählen

-bash: dnstracer: Kommando nicht gefunden.

Wie sind die Ausgaben von:

Code: Alles auswählen

which dnstracer
apt-cache policy dnstracer

?

[grosser]

Code: Alles auswählen

root@Debian-MS:~# which dnstracer
root@Debian-MS:~# apt-cache policy dnstracer
dnstracer:
  Installiert:           (keine)
  Installationskandidat: 1.9-4
  Versionstabelle:
     1.9-4 0
        500 http://ftp.de.debian.org/debian/ jessie/main i386 Packages

[mat6937]

Code: Alles auswählen

root@Debian-MS:~# apt-cache policy dnstracer
dnstracer:
  Installiert:           (keine)
  Installationskandidat: 1.9-4
  Versionstabelle:
     1.9-4 0
        500 http://ftp.de.debian.org/debian/ jessie/main i386 Packages

Versuch mal mit:

Code: Alles auswählen

apt-get install dnstracer

[orcape]

Hi,
nur mal ein Versuch. Ändere mal die Authentifikation..

auth SHA1
cipher 'BF-CBC'

Testweise mal den "auth" Eintrag auskommentieren.

[grosser]

folgendes wird ausgegeben

Code: Alles auswählen

dnstracer "-4vc" meinedyndns.biz | grep -i ttl
- TTL:                  30 (30s)

@orcape
Hab beides versucht, damit kommt der TLS Error schon bevor überhaupt die erste verbindung zustande kommt.

[mat6937]

folgendes wird ausgegeben

Code: Alles auswählen

dnstracer "-4vc" meinedyndns.biz | grep -i ttl
- TTL:                  30 (30s)

Ein sehr guter Wert für TTL, aber Du hast ja auch einen kostenpflichtigen ddns-Account.

..., damit kommt der TLS Error schon bevor überhaupt die erste verbindung zustande kommt.

Hast Du auth und cipher, beim Client und beim Server geändert oder nur beim Client? BTW: SHA1 und BF-CBC sind die default-Werte, für auth und cipher.

EDIT:

Für welche Uhrzeit genau, hast Du in der FritzBox (Router des Servers) die Zwangstrennung konfiguriert?

Zum updaten der neuen externen IPv4-Adresse beim ddns-Provider, wird der ddns-Client der FritzBox verwendet. Gibt es evtl. im Log der FritzBox, irgendwelche Eintragungen betr. Unregelmäßigkeiten/Probleme, in Bezug auf das updaten der IPv4-Adresse durch den ddns-Client der FritzBox?

[grosser]

Habe auth und chiper beim Server als auch beim Client jeweils geändert und neu gestartet.

Die Zwangstrennung der FritzBox erfolgt zwischen 4 und 5 Uhr Morgens.
Also laut dem Log scheint alles ohne Probleme zu verlaufen

Code: Alles auswählen

13.02.16	04:04:14	Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 91.38.149.60, DNS-Server: 217.0.43.65 und 217.0.43.81, Gateway: 217.0.118.70, Breitband-PoP: COTX42-erx
13.02.16	04:04:12	Internetverbindung wurde getrennt.
13.02.16	04:04:09	Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.

Macht es vielleicht Sinn alles noch mal von einzustellen, also komplett leere Configs an beiden Geräten und dann langsam mit den wichtigsten Settings die Configs am Server und am Client aufbauen?

[mat6937]

Code: Alles auswählen

13.02.16	04:04:14	Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 91.38.149.60, DNS-Server: 217.0.43.65 und 217.0.43.81, Gateway: 217.0.118.70, Breitband-PoP: COTX42-erx
13.02.16	04:04:12	Internetverbindung wurde getrennt.
13.02.16	04:04:09	Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.

Welche Uhrzeit hast Du in deiner FritzBox, für die Zwangstrennung konfiguriert?

Schau mal bei deinem ddns-Provider nach, um welche Uhrzeit dort das Updaten der "neuen" IPv4-Adresse statt gefunden hat.

[grosser]

Die Zwangstrennung ist zwischen 4:00 und 5:00 Uhr Morgens eingerichtet in der Fritzbox.

Hier die Daten vom ddns Provider

Code: Alles auswählen

2016-02-13 04:04:19        91.38.149.60          Fritz!Box DDNS/1.0.1

Das war heut Morgen, ging also recht schnell wie ich finde

[mat6937]

Das war heut Morgen, ging also recht schnell wie ich finde

Ja, das ist OK.

Versuch mal jetzt temporär und als Test, in der config-Datei des openvpn-Clienten, mit:

Code: Alles auswählen

script-security 3 system

Evtl. hat der daemon des Clienten mit der default-Konfiguration (script-security 1), auf seinem System nicht alle erforderlichen Rechte, für eine Wiederverbindung nach der Zwangstrennung des Servers.

[grosser]

Hab den Befehl mal eingebaut in die config. Aber heut um 4 Uhr Morgens war der Spaß wieder vorbei.

Bis zur Zwangstrennung keine TLS Errors, sofort nach der Zwangstrennung geht es damit los.

Log Client

Code: Alles auswählen

Sun Feb 14 01:51:22 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 14 01:51:22 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sun Feb 14 02:51:21 2016 TLS: tls_process: killed expiring key
Sun Feb 14 02:51:22 2016 TLS: soft reset sec=0 bytes=12390/0 pkts=236/0
Sun Feb 14 02:51:22 2016 VERIFY OK: depth=1, C=DE, ST=CA, L=Slepo, O=Fort-Knox, OU=MyOrganizationalUnit, CN=come-on.takealookarround.biz, name=EasyRSA, emailAddress=me@myhost.mydomain
Sun Feb 14 02:51:22 2016 VERIFY OK: nsCertType=SERVER
Sun Feb 14 02:51:22 2016 VERIFY OK: depth=0, C=DE, ST=CA, L=Slepo, O=Fort-Knox, OU=MyOrganizationalUnit, CN=come-on.takealookarround.biz, name=EasyRSA, emailAddress=me@myhost.mydomain
Sun Feb 14 02:51:23 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1574'
Sun Feb 14 02:51:23 2016 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
Sun Feb 14 02:51:23 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 14 02:51:23 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 14 02:51:23 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 14 02:51:23 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 14 02:51:23 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sun Feb 14 03:51:22 2016 TLS: tls_process: killed expiring key
Sun Feb 14 03:51:23 2016 TLS: soft reset sec=0 bytes=12390/0 pkts=236/0
Sun Feb 14 03:51:23 2016 VERIFY OK: depth=1, C=DE, ST=CA, L=Slepo, O=Fort-Knox, OU=MyOrganizationalUnit, CN=come-on.takealookarround.biz, name=EasyRSA, emailAddress=me@myhost.mydomain
Sun Feb 14 03:51:23 2016 VERIFY OK: nsCertType=SERVER
Sun Feb 14 03:51:23 2016 VERIFY OK: depth=0, C=DE, ST=CA, L=Slepo, O=Fort-Knox, OU=MyOrganizationalUnit, CN=come-on.takealookarround.biz, name=EasyRSA, emailAddress=me@myhost.mydomain
Sun Feb 14 03:51:24 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1574'
Sun Feb 14 03:51:24 2016 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
Sun Feb 14 03:51:24 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 14 03:51:24 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 14 03:51:24 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 14 03:51:24 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 14 03:51:24 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sun Feb 14 04:12:38 2016 [meinedyndns.biz] Inactivity timeout (--ping-restart), restarting
Sun Feb 14 04:12:38 2016 SIGUSR1[soft,ping-restart] received, process restarting
Sun Feb 14 04:12:38 2016 Restart pause, 2 second(s)
Sun Feb 14 04:12:40 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sun Feb 14 04:12:40 2016 UDPv4 link local: [undef]
Sun Feb 14 04:12:40 2016 UDPv4 link remote: [AF_INET]91.38.137.124:4624
Sun Feb 14 04:13:40 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Feb 14 04:13:40 2016 TLS Error: TLS handshake failed
Sun Feb 14 04:13:40 2016 SIGUSR1[soft,tls-error] received, process restarting
Sun Feb 14 04:13:40 2016 Restart pause, 2 second(s)
Sun Feb 14 04:13:42 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sun Feb 14 04:13:43 2016 UDPv4 link local: [undef]
Sun Feb 14 04:13:43 2016 UDPv4 link remote: [AF_INET]91.38.137.124:4624
Sun Feb 14 04:14:43 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Feb 14 04:14:43 2016 TLS Error: TLS handshake failed
Sun Feb 14 04:14:43 2016 SIGUSR1[soft,tls-error] received, process restarting
Sun Feb 14 04:14:43 2016 Restart pause, 2 second(s)
Sun Feb 14 04:14:45 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sun Feb 14 04:14:45 2016 UDPv4 link local: [undef]
Sun Feb 14 04:14:45 2016 UDPv4 link remote: [AF_INET]91.38.137.124:4624
Sun Feb 14 04:15:45 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Feb 14 04:15:45 2016 TLS Error: TLS handshake failed
Sun Feb 14 04:15:45 2016 SIGUSR1[soft,tls-error] received, process restarting
Sun Feb 14 04:15:45 2016 Restart pause, 2 second(s)
Sun Feb 14 04:15:47 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sun Feb 14 04:15:47 2016 UDPv4 link local: [undef]
Sun Feb 14 04:15:47 2016 UDPv4 link remote: [AF_INET]91.38.137.124:4624
Sun Feb 14 04:16:47 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Feb 14 04:16:47 2016 TLS Error: TLS handshake failed
Sun Feb 14 04:16:47 2016 SIGUSR1[soft,tls-error] received, process restarting
Sun Feb 14 04:16:47 2016 Restart pause, 2 second(s)

Die MTU Warnung hab ich eben gesehen, und hab beim Client irgendwie vergessen den Wert einzutragen, ist aber jetzt angepasst.

[orcape]

Hi,

Sun Feb 14 01:51:22 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

...da passt was nicht. ???

Sun Feb 14 03:51:24 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

...und...

Sun Feb 14 02:51:23 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1574'
Sun Feb 14 02:51:23 2016 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'

MTU-Wert viel zu hoch.

Sun Feb 14 04:16:47 2016 TLS Error: TLS handshake failed

Wie sieht die Ausgabe in der Konsole aus, wenn der Tunnel vom Client händisch gestartet wird?

[mat6937]

Hi,

Sun Feb 14 01:51:22 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

...da passt was nicht. ???

Sun Feb 14 03:51:24 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

...

Das passt schon. Man muss unterscheiden zwischen der cipher für Control-Channel und den ciphern (en-/decrypt bzw. authentication) für Data-Channel. Z. B. hier auch so:

Code: Alles auswählen

Feb 14 14:01:48 xxxxxx daemon.notice ovpn-client[21355]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Feb 14 14:01:48 xxxxxx daemon.notice ovpn-client[21355]: Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication

Feb 14 14:01:48 xxxxxx daemon.notice ovpn-client[21355]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Feb 14 14:01:48 xxxxxx daemon.notice ovpn-client[21355]: Data Channel Decrypt: Using 512 bit message hash 'SHA512' for HMAC authentication

Feb 14 14:01:48 xxxxxx daemon.notice ovpn-client[21355]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

[grosser]

Wie sieht die Ausgabe in der Konsole aus, wenn der Tunnel vom Client händisch gestartet wird?

Puh Jungs, ich bin ja noch auf Neuland für mich unterwegs, we bekomme ich in der Konsole die Ausgabe dafür angezeigt, also mit welchem Befehl?

[mat6937]

..., we bekomme ich in der Konsole die Ausgabe dafür angezeigt, also mit welchem Befehl?

Entweder in der log-Datei des Clienten oder in der /var/log/syslog-Datei. Mit z. B.:

Code: Alles auswählen

service openvpn restart

auf dem Client. Was für ein Gerät ist dein Client? Hast Du ssh- oder evtl. nur telnet-Zugang zu deinem Client-Gerät?

[orcape]

Auf der Konsole als "su" eingeben...

Code: Alles auswählen

openvpn /Pfad zur Client.conf

so z.B. bei einer DD-WRT Client Installation...

Code: Alles auswählen

openvpn /tmp/openvpncl/openvpn.conf

unter Debian dann..

Code: Alles auswählen

openvpn /etc/openvpn/client.conf

Ausgabe sollte dann ungefähr so aussehen, wenn der Tunnel OK ist.

Code: Alles auswählen

root@schrotti:/#openvpn /etc/openvpn/client.conf
Sun Feb 14 15:57:51 2016 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 21 2016
Sun Feb 14 15:57:51 2016 library versions: OpenSSL 1.0.2f  28 Jan 2016, LZO 2.08
Sun Feb 14 15:57:51 2016 WARNING: file '/etc/openvpn/client.key' is group or others accessible
Sun Feb 14 15:57:51 2016 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1432)
Sun Feb 14 15:57:51 2016 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Feb 14 15:57:51 2016 UDPv4 link local: [undef]
Sun Feb 14 15:57:51 2016 UDPv4 link remote: [AF_INET]85.182.xx.yy:1196
Sun Feb 14 15:57:51 2016 TLS: Initial packet from [AF_INET]85.182.xx.yy:1196, sid=7a4d9c4b c31ce9c6
Sun Feb 14 15:57:51 2016 VERIFY OK: depth=1, C=DE, ST=Sachsen, L=ortsteil, O=privat, emailAddress=xxxxx@freakmail.de, CN=ikarus-CA
Sun Feb 14 15:57:51 2016 VERIFY OK: nsCertType=SERVER
Sun Feb 14 15:57:51 2016 VERIFY OK: depth=0, C=DE, ST=Sachsen, L=ortsteil, O=privat, emailAddress=xxxxx@freakmail.de, CN=OpenVPN-Server
Sun Feb 14 15:57:52 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 14 15:57:52 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 14 15:57:52 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Feb 14 15:57:52 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Feb 14 15:57:52 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sun Feb 14 15:57:52 2016 [OpenVPN-Server] Peer Connection Initiated with [AF_INET]85.182.xx.yy:1196
Sun Feb 14 15:57:54 2016 SENT CONTROL [OpenVPN-Server]: 'PUSH_REQUEST' (status=1)
Sun Feb 14 15:57:54 2016 PUSH: Received control message: 'PUSH_REPLY,route 192.168.155.0 255.255.255.0,route 172.16.7.0 255.255.255.0,route 10.10.8.0 255.255.255.0,route 10.12.7.0 255.255.255.0,route 10.211.53.0 255.255.255.0,route 192.168.55.0 255.255.255.0,route 192.168.18.0 255.255.255.0,route 192.168.33.0 255.255.255.0,route 192.168.219.0 255.255.255.0,route 10.15.8.1,topology net30,ping 10,ping-restart 60,ifconfig 10.15.8.2 10.15.8.1'
Sun Feb 14 15:57:54 2016 OPTIONS IMPORT: timers and/or timeouts modified
Sun Feb 14 15:57:54 2016 OPTIONS IMPORT: --ifconfig/up options modified
Sun Feb 14 15:57:54 2016 OPTIONS IMPORT: route options modified
Sun Feb 14 15:57:54 2016 ROUTE_GATEWAY 192.168.219.1/255.255.255.0 IFACE=wlan0 HWADDR=00:26:c6:44:ca:42
Sun Feb 14 15:57:54 2016 TUN/TAP device tun0 opened
Sun Feb 14 15:57:54 2016 TUN/TAP TX queue length set to 100
Sun Feb 14 15:57:54 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sun Feb 14 15:57:54 2016 /sbin/ip link set dev tun0 up mtu 1432
Sun Feb 14 15:57:54 2016 /sbin/ip addr add dev tun0 local 10.15.8.2 peer 10.15.8.1                                       
Sun Feb 14 15:57:54 2016 /sbin/ip route add 192.168.155.0/24 via 10.15.8.1                                               
Sun Feb 14 15:57:54 2016 /sbin/ip route add 172.16.7.0/24 via 10.15.8.1                                                  
Sun Feb 14 15:57:54 2016 /sbin/ip route add 10.10.8.0/24 via 10.15.8.1                                                   
Sun Feb 14 15:57:54 2016 /sbin/ip route add 10.12.7.0/24 via 10.15.8.1
Sun Feb 14 15:57:54 2016 /sbin/ip route add 10.211.53.0/24 via 10.15.8.1
Sun Feb 14 15:57:54 2016 /sbin/ip route add 192.168.55.0/24 via 10.15.8.1
Sun Feb 14 15:57:54 2016 /sbin/ip route add 192.168.18.0/24 via 10.15.8.1
Sun Feb 14 15:57:54 2016 /sbin/ip route add 192.168.33.0/24 via 10.15.8.1
Sun Feb 14 15:57:54 2016 /sbin/ip route add 192.168.219.0/24 via 10.15.8.1
Sun Feb 14 15:57:54 2016 /sbin/ip route add 10.15.8.1/32 via 10.15.8.1
RTNETLINK answers: File exists
Sun Feb 14 15:57:54 2016 Initialization Sequence Completed

Gruß orcape

[mat6937]

Log Client

Code: Alles auswählen

...
Sun Feb 14 04:12:40 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
...

Versuch mal in der config des Clienten, mit angepasster Puffergröße:

Code: Alles auswählen

sndbuf 65536
rcvbuf 65536

Das ist auch der default Wert.

EDIT:

Log Client

Code: Alles auswählen

Sun Feb 14 04:12:38 2016 SIGUSR1[soft,ping-restart] received, process restarting

Evtl. gibt es auch eine "Unverträglichkeit" mit SIGUSR1, in deiner Konstellation:

SIGUSR1
Like SIGHUP, except don't re-read configuration file, and possibly don't close and reopen TUN/TAP device, re-read key
files, preserve local IP address/port, or preserve most recently authenticated remote IP address/port based on --persist-
tun, --persist-key, --persist-local-ip, and --persist-remote-ip options respectively (see above).

This signal may also be internally generated by a timeout condition, governed by the --ping-restart option.


Note that the behavior of SIGUSR1 can be modified by the --persist-tun, --persist-key, --persist-local-ip, and --persist-remote-ip options.

Lass mal in der config des Clienten und des Servers:

Code: Alles auswählen

persist-key
persist-tun

weg.

[MSfree]

Lass mal in der config des Clienten und des Servers:

Code: Alles auswählen

persist-key
persist-tun

weg.

persist-tun würde ich drin lassen, sonst ändert sich die Schnittstelle mit jedem Neuaufbau der Verbindung. Beim ersten Mal lauet die Netzwerkschnittstelle tun0, dann tun1, dann tun2... Am Ende baumeln jede Menge tun-Devices im System. Zumindest hatte ich so ein Phänomän mal mit OpenVPN in früheren Versionen.

[mat6937]

persist-tun würde ich drin lassen, sonst ändert sich die Schnittstelle mit jedem Neuaufbau der Verbindung. Beim ersten Mal lauet die Netzwerkschnittstelle tun0, dann tun1, ...

Es geht hier ja nur um einen Test, betr. das Verhalten vom openvpn-Client bei einem "SIGUSR1". D. h., "persist-tun" soll ja nicht für immer/permanent aus der config entfernt werden.


@grosser:

Für weitere Testzwecke/Reproduzierbarkeit kannst Du das Signal "USR1" auch mit kill an den openvpn-Client senden (... ohne eine Zwangstrennung der FritzBox des openvpn-Servers machen zu müssen). Z. B. auf deinem Client:

Code: Alles auswählen

kill -s USR1 $(pidof openvpn)

ausführen. Das ist dann ein SIGUSR1 hard, statt soft.