Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Das geht zur Zeit nur per SFTP (Android Total Commander). Grobe Schätzung nur anhand des gkrellm von meinem Router:
- Download vom Server ca. 3,3M
- Upload vom Handy auf den Server ähnlich, ging im letzten Drittel auf 5,2M hoch.
Ich habe keine Ahnung, wie ich das in Total Commander anzeigen lassen könnte, aber auch so ist ein signifikanter Unterschied erkennbar.
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich sagte ja, nur mit hohem Aufwand, wozu ich einen Owncloud Server aufsetzen (falls man ihn nicht schon hat) zähle, nur um eine Datei sicher auf mein Smartphone zu bekommen, steht in keinem Verhältnis und kann man niemandem zumuten.
Ich hab dazu weder Mail, noch iCloud (was ich sowieso nicht nutze bzw. so weit es geht deaktiviert habe), noch iTunes gebraucht. USB an PC, .ovpn-Profil draufkopiert, per OpenVPN App gesucht und eingebunden.
Also Stand vor einem Jahr konnte ich ohne iTunes keine Dateien von PC auf iOS Geräte kopieren da diese ja nicht als Wechsellaufwerk eingebunden werden können, sprich um Daten zu kopieren ist zwingen iTunes erforderlich. Oder wie machst du das?
Ich sagte ja, nur mit hohem Aufwand, wozu ich einen Owncloud Server aufsetzen (falls man ihn nicht schon hat) zähle, nur um eine Datei sicher auf mein Smartphone zu bekommen, steht in keinem Verhältnis und kann man niemandem zumuten.
Es hat sich einiges an den Vorgaben geändert. Die Verbindungsgeschwindigkeit hat sich durch eine Vertragsänderung (von 50/10 auf 100/40) erhöht, und die Gegenstelle ist nicht mehr im Ausland.
Mein Draytek Vigor 130 meldet folgende Verbindung: Down Stream : 98338Kbps / Up Stream : 34367Kbps
Ich habe für einen Test eine ca. 127MB große mp4-Datei genommen und kopiere die hin- und her.
Wenn ich die Datei von meinem Server auf das Handy kopiere (4G+-Verbindung):
Mein gkrellm auf dem Router sagt 1,1 - 1,3M; das openVPN auf dem Handy meint ca. 9MBit/s für die Datei.
Die Auslastung des DualCore-Prozessor meines Server liegt dabei auf unter 10% in der Spitze (beide Kerne), er macht sonst nix.
Wenn ich die Datei vom Handy zurück auf den Server kopiere:
Mein gkrellm auf dem Router sagt ca. 2,3M; das openVPN geht auf ca. 16-18MBit/s hoch, die Übertragung ist dementsprechend fast doppelt so schnell.
Die Auslastung des DualCore-Prozessor meines Server liegt hierbei unter 14% (beide Kerne), er macht sonst nix.
Hier noch ein paar Meldungen aus der syslog des Server:
Code:
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'
Vollständig:
Code:
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1343)
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 TLS: Initial packet from [AF_INET]80.187.101.2:26469
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 Validating certificate key usage
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 ++ Certificate has key usage 0080, expects 0080
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 Validating certificate extended key usage
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_VER=2.5_master
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_PLAT=android
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_PROTO=2
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_NCP=2
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_LZ4=1
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_LZ4v2=1
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_LZO=1
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_COMP_STUB=1
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_COMP_STUBv2=1
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_TCPNL=1
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.8
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Aug 5 12:10:08 server ovpn-server-udp[19538]: 80.187.101.2:26469 [note] Peer Connection Initiated with [AF_INET]80.187.101.2:26469
Aug 5 12:10:08 server ovpn-server-udp[19538]: note/80.187.101.2:26469 OPTIONS IMPORT: reading client specific options from: ccd/note
Aug 5 12:10:08 server ovpn-server-udp[19538]: note/80.187.101.2:26469 MULTI: Learn: 10.1.0.38 -> note/80.187.101.2:26469
Aug 5 12:10:08 server ovpn-server-udp[19538]: note/80.187.101.2:26469 MULTI: primary virtual IP for note/80.187.101.2:26469: 10.1.0.38
Aug 5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 PUSH: Received control message: 'PUSH_REQUEST'
Aug 5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 SENT CONTROL [gnote]: 'PUSH_REPLY,route 192.168.4.0 255.255.255.0,topology subnet,sndbuf 393216,rcvbuf 393216,route
-gateway 10.1.0.1,topology subnet,ping 40,ping-restart 90,ifconfig 10.1.0.38 255.255.255.0,peer-id 0,cipher AES-128-CBC' (status=1)
Aug 5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug 5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug 5 12:10:10 server ovpn-server-udp[19538]: note/80.187.101.2:26469 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Also Stand vor einem Jahr konnte ich ohne iTunes keine Dateien von PC auf iOS Geräte kopieren da diese ja nicht als Wechsellaufwerk eingebunden werden können, sprich um Daten zu kopieren ist zwingen iTunes erforderlich. Oder wie machst du das?
??
iPhone mit USB-Kabel verbinden, "Diesem Computer vertrauen", evtl. noch den Freischaltcode eingeben, und schon kann ich in die verschiedenen Apps Dinge reinkopieren, in den Inbox Folder z.B. das .ovpn Profil.
Das ganze unter Fedora 30 (ging aber auch schon mit älteren Versionen).
Ein Buffalo Airstation wzr-hp-ag300h. Schon was älter, läuft mit openWRT. Und läuft als reiner Router, das WLAN ist seit geraumer Zeit inaktiv, weil eine Fritzbox im Client-Betrieb das besser erledigt.
Das openVPN läuft wie gesagt auf meinem Heimserver. Einen Einfluss des Router halte ich für unwahrscheinlich, weil ansonsten ja die mögliche Geschwindigkeit auf diesem DSL-Anschluß erreicht wird.
Ein Buffalo Airstation wzr-hp-ag300h. Schon was älter, läuft mit openWRT. Und läuft als reiner Router, das WLAN ist seit geraumer Zeit inaktiv, weil eine Fritzbox im Client-Betrieb das besser erledigt.
Das openVPN läuft wie gesagt auf meinem Heimserver. Einen Einfluss des Router halte ich für unwahrscheinlich, weil ansonsten ja die mögliche Geschwindigkeit auf diesem DSL-Anschluß erreicht wird.
Naja es kann schon der Auslöser sein. Beim normalen Surfen muss der Router keine IPTables abarbeiten. Bei eingehendem Verkehr schon.
Dann kommen faktoren hinzu, wieviel Firewall regeln du definiert hast.
Kurzum ersetze das ding mit 400Mhz durch ein Gerät mit stand der Technik.
Ich weiß nicht ob du eventuell ein alten PC hast, wo du einmal zum test PFsense installieren kannst, zum testen.
Naja es kann schon der Auslöser sein. Beim normalen Surfen muss der Router keine IPTables abarbeiten. Bei eingehendem Verkehr schon.
Dann kommen faktoren hinzu, wieviel Firewall regeln du definiert hast.
Ich denke schon seit geraumer Zeit darüber nach, auch die Funktion des Routers auf die Fritzbox zu migrieren. Leider funktioniert die Fritzbox so gar nicht so, wie ich das gerne hätte.
Ich weiß nicht ob du eventuell ein alten PC hast, wo du einmal zum test PFsense installieren kannst, zum testen.
Aber nochmal zur Auslastung des Buffalo:
Darauf läuft ja ein gkrellmd. Den passenden gkrellm habe ich auf meinem Desktop laufen, daher auch die Geschwindigkeitswerte von oben. In keinem dieser Fälle sehe ich eine nennenswerte Auslastung der CPU. Selbst ein "top" auf dem Router liefert mir als höchste Belastung tatsächlich den gkrellmd mit 2%.
Auch verstehe ich Deinen Satz "Beim normalen Surfen muss der Router keine IPTables abarbeiten. Bei eingehendem Verkehr schon." in Hinsicht darauf nicht, daß es sich ja um einen durchgeleiteten Tunnel handelt. Der openVPN-Server endet ja nicht auf dem Router, sondern auf meinem Server. Ich verstehe nicht, wieso Du der Meinung bist, daß es einen Unterschied in der Auswirkung des Router zwischen einer VPN- und einer sftp-Verbindung gibt, welche beide "nur" durchgeleitet werden als Port-Weiterleitung. Für mich klingt das nicht logisch.
Zusätzlich kaum welche, in erster Linie wird für drei Geräte outgoing-traffic verhindert, und es gibt halt einige Port-Weiterleitungen.
Ich denke schon seit geraumer Zeit darüber nach, auch die Funktion des Routers auf die Fritzbox zu migrieren. Leider funktioniert die Fritzbox so gar nicht so, wie ich das gerne hätte.
Nein, dafür ist gerade kein Gerät vorhanden.
Der Vigor ist nur Modem, ja.
Aber nochmal zur Auslastung des Buffalo:
Darauf läuft ja ein gkrellmd. Den passenden gkrellm habe ich auf meinem Desktop laufen, daher auch die Geschwindigkeitswerte von oben. In keinem dieser Fälle sehe ich eine nennenswerte Auslastung der CPU. Selbst ein "top" auf dem Router liefert mir als höchste Belastung tatsächlich den gkrellmd mit 2%.
Auch verstehe ich Deinen Satz "Beim normalen Surfen muss der Router keine IPTables abarbeiten. Bei eingehendem Verkehr schon." in Hinsicht darauf nicht, daß es sich ja um einen durchgeleiteten Tunnel handelt. Der openVPN-Server endet ja nicht auf dem Router, sondern auf meinem Server. Ich verstehe nicht, wieso Du der Meinung bist, daß es einen Unterschied in der Auswirkung des Router zwischen einer VPN- und einer sftp-Verbindung gibt, welche beide "nur" durchgeleitet werden als Port-Weiterleitung. Für mich klingt das nicht logisch.
Da sagt das Android-Device: Options-Error: --txqueuelen not supported on this OS.
Es hat beim Download vom Server auf das Endgerät keinerlei Änderung gebracht, dass ich den Parameter in die Server-Config eingesetzt habe, es bleibt bei ca. 8,6MBit/s laut openVPN-Daten auf dem Android-Gerät.
Beim Zurücksenden vom Android-Gerät zum Server ist die Geschwindigkeit erst ähnlich langsam, fällt nach 5-10s noch weiter ab, um dann auf ca. 16MBit/s anzusteigen. Im Grunde exakt genauso wie vorher. Leider.
Da sagt das Android-Device: Options-Error: --txqueuelen not supported on this OS.
Es hat beim Download vom Server auf das Endgerät keinerlei Änderung gebracht, dass ich den Parameter in die Server-Config eingesetzt habe, es bleibt bei ca. 8,6MBit/s laut openVPN-Daten auf dem Android-Gerät.
Beim Zurücksenden vom Android-Gerät zum Server ist die Geschwindigkeit erst ähnlich langsam, fällt nach 5-10s noch weiter ab, um dann auf ca. 16MBit/s anzusteigen. Im Grunde exakt genauso wie vorher. Leider.
jetzt haben wir aber langsam alles durch ... was noch fehlt ist das Android gerät auszuschließen.
Hast du die möglichkeit von einem anderen Rechner aus einen Geschwindkeits test zu machen ?
Mich irritiert nach wie vor der tun-mtu-Fehler, den ich oben genannt habe. Wieso kommt der trotz meiner hier genannten config-Daten? Was ist daran noch falsch?
Mich irritiert nach wie vor der tun-mtu-Fehler, den ich oben genannt habe. Wieso kommt der trotz meiner hier genannten config-Daten? Was ist daran noch falsch?
deswegen : WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'
nimm den wert einmal komplett raus.
auf server und client seite
Auf einen schnellen blick habe ich etwas in der Server als auch Client config mit MTU gesehen. Auch wenn es der link-mtu parameter ist. nimm ihn bitte einmal raus.
Ich probiere das später auf jeden Fall auch noch aus, jetzt gibt es erstmal geänderte Voraussetzungen:
Ich habe DSL-Modem und openWRT-Router rausgeschmissen und alles auf die Fritzbox migriert.
Erstaunlich, dass das a) überraschend probemlos funktioniert (innerhalb der wenigen Dinge, die so eine Fritte kann) und b) den Durchsatz im Download vom Server auf das Android-Gerät verdoppelt hat. Umgekehrt hat sich kaum etwas geändert.
Mich erstaunt es, dass Du mit dieser Vermutung Recht hattest, da es sich ja, wie gesagt, um einen Tunnel handelt, eigentlich sollte sich da der openWRT-Router überhaupt nicht auswirken, sondern nur durchleiten.
Danke, schlussendlich bin ich vorwiegend durch Deine Mithilfe so weit gekommen - ich hatte mich fast schon damit abgefunden, dass ich bei mir die Ursachen niemals finden werde
Ich habe mich jahrzehntelang gegen eine Fritz!Box gewehrt, weil ich von dem Teil nichts halte. Kann vieles, aber nichts richtig. Das ist auch leider immer noch so, auch wenn sie sich weiter entwickelt haben. Mein Problem ist nur, daß die Komplexität, wenn man es "anders" machen will, mittlerweile exponentiell ansteigt und ich mich mittlerweile schlicht weigere, die extrem überbordende Lebenszeit in "IT" und ihre Wartung & Pflege zu stecken. Alle möglichen und unmöglichen Geräte in meinem Umfeld verlangen ständig und immer mehr nach updates, updates, updates. War jetzt auch einer der Gründe, openWRT rauszuschmeissen. Da lief noch ein white-russian, das ist jetzt nicht mehr sooo optimal, und für die Hardware, die ich dort laufen hatte, war eine Aktualisierung nur noch mit hohen Anstrengungen möglich. Lohnte einfach nicht. Die Fritz war eh' schon da und hat den WLAN- und DECT-Teil erheblich besser als die alte Airstation gemacht, was aber auch kein Wunder ist mit den Jahren an Entwicklung, die dazwischen lagen.
Ich werde, wenn ich dazu komme, die o.g. Parameter nochmal kurz rausnehmen und dann kurz testen, aber was soll ich mit TCP? Ich habe für UDP und für TCP zwar je eine Instanz openVPN laufen, aber TCP war bei den Androiden immer schon spürbar sehr viel inperformanter. Ich kann mir eigentlich kaum vorstellen, dass sich das jetzt geändert haben soll.
Nachtrag:
Gerade getestet und völlig krass:
Entferne ich link-mtu und tun-mtu aus Server-Config und Client-Config, so bricht die Übertragungsgeschwindigkeit in den kB-Bereich ab bzw. kommt gar nicht darüber hinaus.
Ich habe dann link-mtu 1464 in der Server-config wieder hinzugefügt, dann erreiche ich wieder die üblichen Übertragunsraten. Ob der Wert optimal ist, weiß ich aber nicht.
Nachtrag:
Gerade getestet und völlig krass:
Entferne ich link-mtu und tun-mtu aus Server-Config und Client-Config, so bricht die Übertragungsgeschwindigkeit in den kB-Bereich ab bzw. kommt gar nicht darüber hinaus.
Ich habe dann link-mtu 1464 in der Server-config wieder hinzugefügt, dann erreiche ich wieder die üblichen Übertragunsraten. Ob der Wert optimal ist, weiß ich aber nicht.
Ich hab jetzt mal eine Config von einem Freund bekommen der auch über Andorid tunnelt.
setzte mal bitte diese 2 Werte in Client und Server und entferne alles andere was mit MTU zu tun hat.
tun-mtu 1500
mssfix 1420
und bitte nochmal das komplette log vom verbindungsaufbau posten.
Ok, gemacht:
Keine MTU-Fehlermeldungen mehr!
Geringfügige Steigerung im Download vom Server auf das Android-Device auf ca. 17,5MBit/s,
geringfügige Steigerung im Upload vom Android-Device auf den Server auf ca. 19MBit/s.
Hier der komplette /var/log/syslog Eintrag vom Start des openVPNd über Verbindungsaufbau des Client bis zur Unterbrechung nach Test:
Code:
Aug 9 11:30:56 server ovpn-server-udp[8089]: OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 14 2018
Aug 9 11:30:56 server ovpn-server-udp[8089]: library versions: OpenSSL 1.0.2s 28 May 2019, LZO 2.08
Aug 9 11:30:56 server ovpn-server-udp[8095]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 9 11:30:56 server ovpn-server-udp[8095]: Diffie-Hellman initialized with 2048 bit key
Aug 9 11:30:56 server ovpn-server-udp[8095]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 9 11:30:56 server ovpn-server-udp[8095]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 9 11:30:56 server ovpn-server-udp[8095]: TUN/TAP device tun0 opened
Aug 9 11:30:56 server ovpn-server-udp[8095]: TUN/TAP TX queue length set to 100
Aug 9 11:30:56 server ovpn-server-udp[8095]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Aug 9 11:30:56 server ovpn-server-udp[8095]: /sbin/ip link set dev tun0 up mtu 1500
Aug 9 11:30:56 server ovpn-server-udp[8095]: /sbin/ip addr add dev tun0 10.1.0.1/24 broadcast 10.1.0.255
Aug 9 11:30:56 server ovpn-server-udp[8095]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Aug 9 11:30:56 server ovpn-server-udp[8095]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Aug 9 11:30:56 server ovpn-server-udp[8095]: UDPv4 link local (bound): [AF_INET][undef]:1194
Aug 9 11:30:56 server ovpn-server-udp[8095]: UDPv4 link remote: [AF_UNSPEC]
Aug 9 11:30:56 server ovpn-server-udp[8095]: MULTI: multi_init called, r=256 v=256
Aug 9 11:30:56 server ovpn-server-udp[8095]: IFCONFIG POOL: base=10.1.0.2 size=252, ipv6=0
Aug 9 11:30:56 server ovpn-server-udp[8095]: Initialization Sequence Completed
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 TLS: Initial packet from [AF_INET]80.187.100.11:15205, sid=584d5c7a 493e7724
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 VERIFY OK:
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 Validating certificate key usage
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 ++ Certificate has key usage 0080, expects 0080
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 VERIFY KU OK
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 Validating certificate extended key usage
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 VERIFY EKU OK
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 VERIFY OK:
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_VER=2.5_master
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_PLAT=android
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_PROTO=2
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_NCP=2
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_LZ4=1
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_LZ4v2=1
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_LZO=1
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_COMP_STUB=1
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_COMP_STUBv2=1
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_TCPNL=1
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.8
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 TLS: Username/Password authentication succeeded for username 'test'
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Aug 9 11:31:32 server ovpn-server-udp[8095]: 80.187.100.11:15205 [note] Peer Connection Initiated with [AF_INET]80.187.100.11:15205
Aug 9 11:31:32 server ovpn-server-udp[8095]: note/80.187.100.11:15205 OPTIONS IMPORT: reading client specific options from: ccd/note
Aug 9 11:31:32 server ovpn-server-udp[8095]: note/80.187.100.11:15205 MULTI: Learn: 10.1.0.38 -> note/80.187.100.11:15205
Aug 9 11:31:32 server ovpn-server-udp[8095]: note/80.187.100.11:15205 MULTI: primary virtual IP for note/80.187.100.11:15205: 10.1.0.38
Aug 9 11:31:33 server ovpn-server-udp[8095]: note/80.187.100.11:15205 PUSH: Received control message: 'PUSH_REQUEST'
Aug 9 11:31:33 server ovpn-server-udp[8095]: note/80.187.100.11:15205 SENT CONTROL [note]: 'PUSH_REPLY,route 192.168.4.0 255.255.255.0,topology subnet,sndbuf 393216,rcvbuf 393216,route-gateway 10.1.0.1,topology subnet,ping 40,ping-restart 90,ifconfig 10.1.0.38 255.255.255.0,peer-id 0,cipher AES-128-CBC' (status=1)
Aug 9 11:31:33 server ovpn-server-udp[8095]: note/80.187.100.11:15205 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug 9 11:31:33 server ovpn-server-udp[8095]: note/80.187.100.11:15205 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 9 11:31:33 server ovpn-server-udp[8095]: note/80.187.100.11:15205 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug 9 11:31:33 server ovpn-server-udp[8095]: note/80.187.100.11:15205 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 9 11:33:12 server ovpn-server-udp[8095]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]185.200.118.6:58817
Das Android-Device meldet immer noch einen Fehler:
"WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead."
Da ich das sowieso überall mache (mehrfach kontrolliert), gehe ich von einem Fehler der App aus und ignoriere diese Meldung weiterhin.
Nachtrag: Selbst die 19MBit/s liegen ja immer noch weiter unter den 36MBit/s, die der Anschluß laut Modem-Daten liefert. Ist da so viel Protokoll-Overhead drin, welches das so einschränkt?
Nachtrag: Selbst die 19MBit/s liegen ja immer noch weiter unter den 36MBit/s, die der Anschluß laut Modem-Daten liefert. Ist da so viel Protokoll-Overhead drin, welches das so einschränkt?
Also, es geht hier ja nur um den uplink der Leitung. Wenn ich z.B. eine ssh-Verbindung zu einer passend schnellen Gegenstelle aufbaue und etwas rüber sende, so kann ich meine Leitung durchaus gut auslasten.
Auch bei Speedtests kann ich die Leitung auslasten.
Kannst du mal in ein WLAN vom Nachbarn und das über eine andere Internet verbindung testen ?
IPSec ist aber ua. nativ in iOS integriert und zumindest für mich komfortabler einzurichten.
Was meinst du mit Loadbalancing ? RSS ? Mehrere OpenVPN Instanzen parallel ?
Für mich wäre es genau anders. Ich nutze Debian und Android, gar kein iOS. Ist eine Installation eines IPSec-VPN-Server auf Debian einfacher als openVPN? Ein deutschsprachiges HowTo wäre da schon toll. Wie sieht es bei Androiden aus? Ich überlege, ob es da nicht sogar sinnig wäre, sich direkt mal mit wireguard zu beschäftigen.
