openVPN unter Stretch IMO viel zu langsam - was tun?

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von mat6937 » 15.11.2018 10:42:22

dirk11 hat geschrieben: ↑ zum Beitrag ↑
15.11.2018 10:33:01
Ich kenne kein iperf für Android?
Dann hast Du nicht gesucht:

https://apkpure.com/iperf-for-android/c ... apps.iperf

BTW: Wenn Du diese Zeilen brauchst, dann ist das ein Android-Problem, denn mit einem Linux-OpenVPN-Server und einem Linux-OpenVPN-Client gibt es überhaupt kein Problem bzgl. Bandbreite via VPN-Tunnel, ohne diese Zeilen.

dirk11
Beiträge: 2812
Registriert: 02.07.2013 11:47:01

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von dirk11 » 15.11.2018 16:25:15

eggy hat geschrieben: ↑ zum Beitrag ↑
15.11.2018 10:41:57
Abgesehen davon, dass ich KEINEN Link gepostet habe.
Ups, entschuldige bitte, da habe ich tatsächlich etwas verwechselt! Mal davon abgesehen, dass Dein "geteiltes Wissen" sich auf eine Gegenfrage beschränkt hat... :roll: Aber das bekommst Du ja sowieso nicht mehr mit... :facepalm: :mrgreen:
Willkommen auf meiner Ignoreliste.
Irgendwie merkwürdig, daß es immer der gleiche Typ "Forist" ist, der zwar exakt gar nix zum Thema beitragen kann, aber meint, über einen (selbst intendierten) "Ton" meckern zu können... :facepalm:
Zuletzt geändert von dirk11 am 15.11.2018 16:36:40, insgesamt 2-mal geändert.

dirk11
Beiträge: 2812
Registriert: 02.07.2013 11:47:01

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von dirk11 » 15.11.2018 16:30:43

mat6937 hat geschrieben: ↑ zum Beitrag ↑
15.11.2018 10:42:22
Dann hast Du nicht gesucht:
Korrekt. :oops: Ich schrieb ja, ich kenne kein iperf für Android. 8)
BTW: Wenn Du diese Zeilen brauchst, dann ist das ein Android-Problem, denn mit einem Linux-OpenVPN-Server und einem Linux-OpenVPN-Client gibt es überhaupt kein Problem bzgl. Bandbreite via VPN-Tunnel, ohne diese Zeilen.
Also die sndbuf- und rcvbuf-Zeilen beziehen sich definitiv auf Einstellungen am Server. Das hat wohl was mit dem Kernel zu tun, ich erinnere mich nicht mehr genau, was ich da vor einem Jahr gelesen habe.
Und es kann durchaus sein, daß das Problem auch aus Android stammt - ich nutze dort den "offiziellen" (?) openVPN-Client und importiere die Daten als .ovpn. Wie gesagt, die Verbindung funktioniert auf Anhieb, nur gab bzw. gibt es Geschwindigkeits-Probleme.
Warum z.B. ein mtu-mismatch entsteht, das verstehe ich nicht. Genausowenig verstehe ich aber, warum ich überhaupt eine mtu einstellen muss, ich bin eigentlich davon ausgegangen, dass opnVPN solcherlei Dinge z.B. beim handshake aushandelt. Macht es offensichtlich nicht, wieder was gelernt. Dennoch besteht noch das Problem des mismatch zwischen Server und Client, dessen Entstehung ich nicht verstehe.

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von mat6937 » 15.11.2018 18:33:00

dirk11 hat geschrieben: ↑ zum Beitrag ↑
15.11.2018 16:30:43
Genausowenig verstehe ich aber, warum ich überhaupt eine mtu einstellen muss, ich bin eigentlich davon ausgegangen, dass opnVPN solcherlei Dinge z.B. beim handshake aushandelt. Macht es offensichtlich nicht, wieder was gelernt.
Doch, macht es. Du musst keine mtu für das tun-Interface einstellen. Z. B. hier die mss beim handshake (ohne Konfiguration der mtu in den config-Dateien):

Code: Alles auswählen

18:21:14.540430 ip: (tos 0x0, ttl 64, id 41270, offset 0, flags [DF], proto TCP (6), length 56)
    10.4.0.6.46742 > 10.4.0.1.5001: Flags [S], cksum 0xa66e (correct), seq 2253365147, win 29200, options [mss 1460,sackOK,TS val 605869 ecr 0], length 0
    
18:21:14.563431 ip: (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 48)
    10.4.0.1.5001 > 10.4.0.6.46742: Flags [S.], cksum 0x474e (correct), seq 4134588235, ack 2253365148, win 29200, options [mss 1358,nop,nop,sackOK], length 0

dirk11
Beiträge: 2812
Registriert: 02.07.2013 11:47:01

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von dirk11 » 15.11.2018 22:07:05

mat6937 hat geschrieben: ↑ zum Beitrag ↑
15.11.2018 18:33:00
Doch, macht es. Du musst keine mtu für das tun-Interface einstellen.
Mhmmja, aber wie passt das zu meinem log? Wieso ist die link-mtu erst dann auf beiden Seiten identisch, wenn ich am Server link-mtu und am Client tun-mtu einstelle? Andere Varianten haben nicht funktioniert.

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von mat6937 » 15.11.2018 22:48:43

dirk11 hat geschrieben: ↑ zum Beitrag ↑
15.11.2018 22:07:05
Mhmmja, aber wie passt das zu meinem log?
Das passt gar nicht zu deinem log und das ist auch gut so, denn Du hast ja in deinen configs, link-mtu bzw. tun-mtu konfiguriert und ich nicht.

dirk11
Beiträge: 2812
Registriert: 02.07.2013 11:47:01

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von dirk11 » 15.11.2018 23:35:35

Vielleicht stehe ich ja gerade auf der Leitung, aber die Antwort verstehe ich nicht.

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von mat6937 » 16.11.2018 09:06:53

dirk11 hat geschrieben: ↑ zum Beitrag ↑
15.11.2018 23:35:35
Vielleicht stehe ich ja gerade ...
Hast Du zum testen, einen OpenVPN-Linux-Client, statt den Android? Wenn ja, dann teste mal ohne mtu-Eintrag und ohne die Zeilen:

Code: Alles auswählen

fast-io
push "sndbuf 393216"
push "rcvbuf 393216"
in den configs.

dirk11
Beiträge: 2812
Registriert: 02.07.2013 11:47:01

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von dirk11 » 16.11.2018 09:29:52

Nein, zur Zeit leider nicht. Würde mir genau was bringen, außer Erkenntnisgewinn zu einer anderen Geräteklasse? Ich benötige das VPN ja genau für die Android-Geräte.

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von mat6937 » 16.11.2018 09:39:15

dirk11 hat geschrieben: ↑ zum Beitrag ↑
16.11.2018 09:29:52
Würde mir genau was bringen, außer Erkenntnisgewinn zu einer anderen Geräteklasse? Ich benötige das VPN ja genau für die Android-Geräte.
Dann kannst Du explizit darauf hinweisen, dass es _nur_ um Android-Geräte geht und es zwischen 2 Linux-Geräten (bzgl. Bandbreite) keine Probleme gibt.

dirk11
Beiträge: 2812
Registriert: 02.07.2013 11:47:01

Re: openVPN unter Stretch IMO viel zu langsam - was tun?

Beitrag von dirk11 » 18.11.2018 01:46:43

Ich bin mit dem Thema leider immer noch nicht weiter. Mit den zuletzt genannten Settings sieht eine Verbindung aus dem Ausland zur Zeit so aus:

Code: Alles auswählen

Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 VERIFY OK: [Rest entfernt]
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 Validating certificate key usage
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 ++ Certificate has key usage  0080, expects 0080
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 VERIFY KU OK
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 Validating certificate extended key usage
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 VERIFY EKU OK
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 VERIFY OK: [Rest entfernt]
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 peer info: IV_GUI_VER=OC30Android
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 peer info: IV_VER=3.2
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 peer info: IV_PLAT=android
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 peer info: IV_NCP=2
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 peer info: IV_TCPNL=1
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 peer info: IV_PROTO=2
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 TLS: Username/Password authentication succeeded for username 'AAAA' 
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1464', remote='link-mtu 1431'
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher AES-256-GCM'
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 18 00:40:23 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 18 00:40:24 server ovpn-server-udp[3544]: fon/123.211.21.1:39140 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Eine Verbindung in Deutschland hingegen so:

Code: Alles auswählen

Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1343)
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 TLS: Initial packet from [AF_INET]80.187.11.1:28505, sid=xxxxxx
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 VERIFY OK: [Rest entfernt]
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 Validating certificate key usage
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 ++ Certificate has key usage  0080, expects 0080
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 VERIFY KU OK
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 Validating certificate extended key usage
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 VERIFY EKU OK
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 VERIFY OK: [Rest entfernt]
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 peer info: IV_GUI_VER=OC30Android
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 peer info: IV_VER=3.2
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 peer info: IV_PLAT=android
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 peer info: IV_NCP=2
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 peer info: IV_TCPNL=1
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 peer info: IV_PROTO=2
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 TLS: Username/Password authentication succeeded for username 'BBBB' 
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Nov 18 01:24:02 server ovpn-server-udp[3544]: 80.187.11.1:28505 [gnote] Peer Connection Initiated with [AF_INET]80.187.11.1:28505
Nov 18 01:24:02 server ovpn-server-udp[3544]: note/80.187.11.1:28505 OPTIONS IMPORT: reading client specific options from: ccd/note
Nov 18 01:24:02 server ovpn-server-udp[3544]: note/80.187.11.1:28505 MULTI: Learn: 10.2.0.3 -> gnote/80.187.11.1:28505
Nov 18 01:24:02 server ovpn-server-udp[3544]: note/80.187.11.1:28505 MULTI: primary virtual IP for gnote/80.187.11.1:28505: 10.2.0.3
Nov 18 01:24:02 server ovpn-server-udp[3544]: note/80.187.11.1:28505 PUSH: Received control message: 'PUSH_REQUEST'
Nov 18 01:24:02 server ovpn-server-udp[3544]: note/80.187.11.1:28505 SENT CONTROL [note]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,topology subnet,sndbuf 393216,rcvbuf 393216,route-gateway 10.2.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.2.0.3 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Nov 18 01:24:02 server ovpn-server-udp[3544]: note/80.187.11.1:28505 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 18 01:24:02 server ovpn-server-udp[3544]: note/80.187.11.1:28505 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Warum fehlt denn da jetzt die Push-Config im ersten log? Und wieso wurde die entferntere Verbindung aus dem ersten log so merkwürdig fehlerhaft aufgebaut, während die hierzulande aufgebaute Verbindung problemlos und gemäß config aufgebaut wurde?

Antworten