OpenVPN geringe Leistung. Habe ich MTU-Probleme? Dumps drinnen

13

Ich habe Probleme mit einem OpenVPN-Tunnel, der die Leitungsgeschwindigkeit nicht erreicht. Das Gateway ist ein virtueller Debian Jessy-Server, der bei OVH gehostet wird. Der Client ist entweder mein freebsd 10.2 Homeserver (Intel I3 Ivy Bridge) oder mein RaspberryPI2. Ich habe die Verschlüsselung und Authentifizierung deaktiviert. Ich habe eine symmetrische FTTH-Verbindung mit 100 MBit / s, aber der Tunnel erreicht nur eine Geschwindigkeit von 20-40 MBit / s. Direkte Verbindung (ohne Tunnel) liefert immer die 100 MBit / s, die ich erwarte. Ich habe die Leistung mit iperf3 getestet. Ich habe es zuerst mit meinem freebsd homeserver versucht. Ich habe alle empfohlenen Einstellungen für mssfix, fragment usw. ausprobiert. Nichts hat geholfen.

Dann dachte ich, vielleicht ist es meine Freebsd-Maschine. Also habe ich einen frischen Raspbian Jessy auf meinem RPI2 installiert und einige weitere eingehende Tests durchgeführt:

Zuerst habe ich alle MTU-Einstellungen aus den OpenVPN-Konfigurationen entfernt und die Pfad-MTU (hoffentlich) damit umgehen lassen. Da auf beiden Rechnern keine Firewall aktiv ist, sollte dies funktionieren. Dies sind meine VPN-Konfigurationen:

server 10.8.0.0 255.255.255.0
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0

user nobody
group nogroup
persist-key
persist-tun
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1"
status openvpn-status.log
verb 3

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.theissen.io.crt
key /etc/openvpn/easy-rsa/keys/vpn.theissen.io.key
dh /etc/openvpn/easy-rsa/keys/dh4096.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher none
auth none
comp-lzo no



client
proto udp
dev tun12
remote xxx.io 1194
resolv-retry infinite
sndbuf 0
rcvbuf 0

nobind
user nobody
group nogroup
persist-key
persist-tun
verb 3

pkcs12 /etc/openvpn/vpn.theissen.io/alex.p12
tls-auth /etc/openvpn/vpn.theissen.io/ta.key 1
ns-cert-type server
cipher none
auth none
comp-lzo no

Zunächst einmal der Test ohne Tunnel, um zu zeigen, dass die Verbindung zum Server tatsächlich fast 100 MBit / s beträgt:

iperf3 -c vpn.theissen.io
Connecting to host vpn.theissen.io, port 5201
[  4] local 192.168.1.253 port 34512 connected to 149.202.58.183 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  10.8 MBytes  90.5 Mbits/sec    0    335 KBytes       
[  4]   1.00-2.00   sec  11.4 MBytes  95.7 Mbits/sec    0    335 KBytes       
[  4]   2.00-3.00   sec  11.1 MBytes  93.0 Mbits/sec    0    352 KBytes       
[  4]   3.00-4.00   sec  11.2 MBytes  94.0 Mbits/sec    0    369 KBytes       
[  4]   4.00-5.00   sec  11.5 MBytes  95.9 Mbits/sec    0    390 KBytes       
[  4]   5.00-6.00   sec  11.0 MBytes  92.5 Mbits/sec    0    390 KBytes       
[  4]   6.00-7.00   sec  11.4 MBytes  95.2 Mbits/sec    0    390 KBytes       
[  4]   7.00-8.00   sec  11.2 MBytes  94.3 Mbits/sec    0    390 KBytes       
[  4]   8.00-9.00   sec  11.1 MBytes  93.3 Mbits/sec    0    390 KBytes       
[  4]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec    0    390 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  93.9 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  93.5 Mbits/sec                  receiver

iperf Done.

Die Pakete dieser Verbindung habe ich mit tcpdump auf dem Server gespeichert. Sie können sie hier herunterladen (Sie müssen sie extrahieren, um sie mit wireshark zu öffnen): dumpraw.cap.xz

So sieht also ein "OK" -Dump aus. Die maximale Rahmengröße, die ich entdeckt habe, beträgt 1514. Dump von iperf3 ohne tunnel

Jetzt habe ich den Test über den Tunnel gefahren:

iperf3 -c 10.8.0.1
Connecting to host 10.8.0.1, port 5201
[  4] local 10.8.0.14 port 36388 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  5.96 MBytes  50.0 Mbits/sec  127    133 KBytes       
[  4]   1.00-2.00   sec  5.19 MBytes  43.5 Mbits/sec    6    120 KBytes       
[  4]   2.00-3.00   sec  5.80 MBytes  48.7 Mbits/sec    0    151 KBytes       
[  4]   3.00-4.00   sec  4.27 MBytes  35.9 Mbits/sec   23   96.5 KBytes       
[  4]   4.00-5.00   sec  4.89 MBytes  41.0 Mbits/sec    0    129 KBytes       
[  4]   5.00-6.00   sec  6.11 MBytes  51.2 Mbits/sec   26    111 KBytes       
[  4]   6.00-7.00   sec  5.50 MBytes  46.1 Mbits/sec    0    143 KBytes       
[  4]   7.00-8.00   sec  5.25 MBytes  44.1 Mbits/sec   15    126 KBytes       
[  4]   8.00-9.00   sec  5.80 MBytes  48.7 Mbits/sec    0    158 KBytes       
[  4]   9.00-10.00  sec  3.97 MBytes  33.3 Mbits/sec   22    105 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  52.7 MBytes  44.2 Mbits/sec  219             sender
[  4]   0.00-10.00  sec  52.3 MBytes  43.8 Mbits/sec                  receiver

iperf Done.

Hoppla. Nicht mehr so ​​schön. Vor allem diese "Retr" -Spalte sieht nicht so gut aus. Ich ging davon aus, dass dies die tcp-Neuübertragung ist und es dann etwas im Dump geben sollte. Wir werden sehen, dass dies nicht der Fall ist:. Die CPU ist hier nicht der Engpass, da ich die Verschlüsselung und Authentifizierung deaktiviert habe. Die CPU ist während des Tests zu 20% auf dem Server und zu 50% auf dem PI.

So sieht der OpenVPN-Verkehr des Tests aus: OpenVPN-Verkehr auf der physischen Schnittstelle

Für mich sieht das okay aus. Aber ich weiß nicht, wonach ich suchen soll. Bitte schauen Sie sich den Dump mit wireshark an: dump_physical.cap.xz

Der Verkehr auf der Tunnelschnittstelle sieht auch für mich gut aus. Es scheint, dass er die Framegröße korrekt gesenkt hat (auf 1444, wie es scheint): iperf3-Verkehr auf der Tunnelschnittstelle

Hier ist der Dump: dump_tunnel.cap.xz

Für mich sieht das alles gut aus, aber ich habe wirklich keine Ahnung, wonach ich genau suchen soll. Ich habe wirklich alles mit den OpenVPN-Einstellungen ausprobiert. Vielleicht kann mir jemand sagen, ob der Verkehr in Ordnung aussieht.

Was ich als Antwort erwarte

Zumindest eine Erklärung, was hier passiert und warum es scheinbar unabhängig von der von mir verwendeten VPN-Software ist. Alles, was ich im Internet gefunden habe, handelte von MTU-Problemen, aber das sollte einfach durch Reduzieren der Tunnel-MTU oder der anderen Parameter von OpenVPN behoben werden können. Für mich ändert sich daran wenig. Wenn Sie sich den Speicherauszug ansehen, sehen Sie, dass er die TCP-Segmentgröße verringert und Pakete nicht fragmentiert werden. Es muss noch etwas anderes geben. Ich mag es wirklich zu wissen, was .

Aktualisieren

Ich habe das mit strongswan und sogar mit softether getestet. Es ist eigentlich das gleiche Problem (vergleichbare Geschwindigkeit, kein CPU-Engpass). Ich bin wirklich verwirrt, was das Problem hier ist. Ich habe auch versucht, ein anderes Gateway (RaspberryPi2 auf Freunde 100/100 Heimverbindung).

Update 2

Ich habe bemerkt, dass iperf3 TCP-Retransmits (retr) meldet, aber es gibt keine Retransmits im Dump (Wireshark sollte sie hervorheben). Was ist los?

Ich habe sogar OpenVPN in meinem lokalen Netzwerk (RaspberryPi2 bis FreebsdServer) ausprobiert. Auch dort habe ich viele Retransmits (im LAN ?!):

Connecting to host 192.168.222.11, port 5201
[  4] local 192.168.222.10 port 46196 connected to 192.168.222.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  9.19 MBytes  77.0 Mbits/sec    8    141 KBytes       
[  4]   1.00-2.00   sec  8.71 MBytes  73.1 Mbits/sec    3    130 KBytes       
[  4]   2.00-3.00   sec  8.59 MBytes  72.0 Mbits/sec    3    120 KBytes       
[  4]   3.00-4.00   sec  8.65 MBytes  72.5 Mbits/sec    4    108 KBytes       
[  4]   4.00-5.00   sec  8.65 MBytes  72.5 Mbits/sec    4   95.6 KBytes       
[  4]   5.00-6.00   sec  8.52 MBytes  71.5 Mbits/sec    2   80.5 KBytes       
[  4]   6.00-7.00   sec  8.83 MBytes  74.1 Mbits/sec    0    141 KBytes       
[  4]   7.00-8.00   sec  8.59 MBytes  72.0 Mbits/sec    7    106 KBytes       
[  4]   8.00-9.00   sec  8.71 MBytes  73.1 Mbits/sec    3   94.2 KBytes       
[  4]   9.00-10.00  sec  8.59 MBytes  72.0 Mbits/sec    3   79.2 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec   37             sender
[  4]   0.00-10.00  sec  86.8 MBytes  72.8 Mbits/sec                  receiver

Im umgekehrten Modus habe ich ein wirklich seltsames Überlastungsfenster (wtf?):

Accepted connection from 192.168.222.10, port 46197
[  5] local 192.168.222.11 port 5201 connected to 192.168.222.10 port 46198
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec  8.90 MBytes  74.7 Mbits/sec    3   1.48 GBytes       
[  5]   1.00-2.00   sec  8.45 MBytes  70.9 Mbits/sec    2   1.59 GBytes       
[  5]   2.00-3.00   sec  8.66 MBytes  72.7 Mbits/sec  518    214 MBytes       
[  5]   3.00-4.00   sec  7.96 MBytes  66.8 Mbits/sec   37    703 MBytes       
[  5]   4.00-5.00   sec  8.09 MBytes  67.9 Mbits/sec    0    719 MBytes       
[  5]   5.00-6.00   sec  8.04 MBytes  67.5 Mbits/sec    0    734 MBytes       
[  5]   6.00-7.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   7.00-8.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   8.00-9.00   sec  7.99 MBytes  67.1 Mbits/sec    2    693 MBytes       
[  5]   9.00-10.00  sec  8.06 MBytes  67.6 Mbits/sec    1    693 MBytes       
[  5]  10.00-10.09  sec   684 KBytes  64.5 Mbits/sec    0    695 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.09  sec  83.0 MBytes  69.0 Mbits/sec  565             sender
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec                  receiver

Update 3

Die Verwendung von iperf mit udp führt zu einer vorübergehenden Sperrung dieses Ports (sie senden mir eine E-Mail, die mich über einen Angriff informiert) und einem massiven Paketverlust:

-----------------------------------------------------------
Server listening on 1194
-----------------------------------------------------------
Accepted connection from 185.22.143.160, port 15906
[  5] local 149.202.58.183 port 1194 connected to 185.22.143.160 port 4355
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.89 MBytes  24.2 Mbits/sec  0.727 ms  1017/1387 (73%)  
iperf3: OUT OF ORDER - incoming packet = 1409 and received packet = 1470 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1410 and received packet = 1471 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1411 and received packet = 1472 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1445 and received packet = 1473 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1463 and received packet = 1473 AND SP = 5
[  5]   1.00-2.00   sec  3.29 MBytes  27.6 Mbits/sec  0.716 ms  1110/1526 (73%)  
[  5]   2.00-3.00   sec  3.30 MBytes  27.7 Mbits/sec  0.732 ms  1103/1526 (72%)  
[  5]   3.00-4.00   sec  3.27 MBytes  27.4 Mbits/sec  0.717 ms  1108/1526 (73%)  
[  5]   4.00-5.00   sec  1.56 MBytes  13.1 Mbits/sec  0.837 ms  546/746 (73%)  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]  10.00-10.06  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec   118 MBytes  98.5 Mbits/sec  0.837 ms  4884/6711 (73%)  
[SUM]  0.0-10.1 sec  4884 datagrams received out-of-order
vpn  performance  openvpn  mtu 
— Alexander Theißen
quelle
1
Wenn Sie noch nicht getan haben, können Sie es versuchen: tun-mtu 9000 fragment 0 mssfix 0(Optionen müssen in drei verschiedenen Zeilen hinzugefügt werden)
— Diamant
Das habe ich schon getestet. Aber ich habe nochmal getestet. Was passiert ist, dass es mit der gleichen Geschwindigkeit startet, aber dann die Verbindungen zum Stillstand kommen. Was übrigens immer passiert, wenn ich die OpenVPN-Paketfragmentierung deaktiviere. Diese Anleitung community.openvpn.net/openvpn/wiki/Gigabit_Networks lässt Sie glauben, dass das Betriebssystem damit umgehen sollte, aber offensichtlich nicht.
— Alexander Theißen
Oh wow. Ich sehe auf meinen VPNs genau dasselbe Verhalten und ich habe auf beiden Seiten leistungsfähige Hardware und eine langsamere Internetverbindung. Ich werde weiter nachforschen. Wenn ich etwas Konkretes finde, poste ich hier zurück.
— Harald
1
Wenn ich meinen Test auf UDP umstelle (iperf3 -u -b 25m), bekomme ich sowohl innerhalb als auch außerhalb des OpenVPN-Tunnels die volle Geschwindigkeit. Ich habe bestätigt, dass es bei Verwendung von TCP keine Fragmentierung gibt - openvpn meldet korrekterweise eine kleine MSS, meine TCP-Pakete im Tunnel haben alle 1354 Byte und die UDP-Pakete kommen unfragmentiert an. Ich sehe dasselbe Phänomen wie Sie - die CWND-Werte im Tunnel sind ungefähr halb so hoch wie außerhalb des Tunnels, und der Durchsatz ist auch halb so hoch, aber ich weiß nicht, warum . Faszinierend.
— Harald
1
Okay, ich entschuldige mich dafür, dass ich falsche Hoffnungen gemacht habe. Um eine ganze Reihe von Variablen zu eliminieren, richte ich ein OpenVPN mit denselben Konfigurationsparametern ein, das in meinem lokalen LAN ausgeführt wird. Außerhalb des Tunnels 750 Mbit / s. Innerhalb des Tunnels 117 Mbit / s. Aber - openvpn hat auf beiden Endpunkten 100% eines einzelnen CPU-Kerns verbraucht. Also habe ich den Home-Endpunkt meines Internet-Tunnels auf einen "echten" Server verschoben und die erwarteten 25 Mbit / s durch meinen Tunnel gesehen. OpenVPN auf beiden Endpunkten verbrauchte ungefähr 20% der CPU. Lange Rede kurzer Sinn - in meinem Fall ist das Problem, dass mein Tunnelendpunkt auf der Startseite CPU-gebunden ist. Es tut uns leid!
— Harald

Antworten:

2

Für den Anfang sollte Ihr "normaler" externer Tunnel-Iperf-Lauf UDP / 1194 als der Fluss sein, auf dem Sie das Problem haben, und nicht TCP / 5201. Versuchen Sie es zunächst mit -b 100M, aber denken Sie daran, dass dies Datagramme mit maximaler Größe erzeugt, die nicht für Ihren VPN-Verkehr repräsentativ sind (die Datagrammgröße sollte zufällig sein). Stellen Sie die Datagrammgröße mit der Option -l ein und überprüfen Sie die Ergebnisse. Wenn die Ergebnisse nicht gut sind (ich würde sagen> 15 oder 20% Verlust), können Sie einen überlasteten Internet-Router vermuten, der Ihre (wahrscheinlich als Best-Effort gekennzeichneten) Pakete fallen lässt.

Es könnte auch interessant sein zu sehen, welche Leistung Sie erhalten, wenn Sie Ihren VPN-Tunnel entweder auf einen UDP-Port der EF-Klasse umschalten (ich würde sagen 5061 wegen RTP, aber nicht wirklich sicher, ob alle Internet-Router QoS korrekt konfiguriert haben) oder auf einen TCP-Port.

Für mich stimmt nichts mit Ihrem Setup und Ihre Diagnose zeigt nichts Seltsames. Probieren Sie auch eine andere Version von OpenVPN oder einer anderen VPN-Software aus.

— 30gd4n
quelle
Tat dies. Schau dir update3 an. Warten Sie, bis OVH den Port freigegeben hat, um weitere Tests durchzuführen.
— Alexander Theißen
Aww, sorry, habe das letzte Update nicht gesehen. Während Sie auf OVH warten, versuchen Sie, Ihr VPN über TCP zu mounten. Was sind die Ergebnisse? Auch über Ihre zweite Bearbeitung und die erneute Übertragung von * BSD nach PI; Hast du mit den Server-Puffern von iperf gespielt? Die Standardeinstellung ist 8 KB, ich weiß nicht, wie der Stack unter ARM und Linux erstellt wird, aber ich glaube, eine Erhöhung könnte helfen.
— 30gd4n
Ich meinte, ich habe es hinzugefügt, nachdem du es mir gesagt hast :). Ergebnisse über TCP sind schlechter. TCP 443 macht keinen Unterschied. Das Lustige ist, dass wenn ich dieses github.com/sivel/speedtest-cli zum Testen benutze , es 95 m nach unten und 75 m nach oben meldet. Ich vertraue iperf mehr, aber es hängt wirklich von der Art des Verkehrs ab, so scheint es. Das Herunterladen von Spielen oder Patches über den Tunnel dauert für Playstation4 auch länger. Wenn ich zu Hause bin, werde ich einen Tunnel direkt zwischen zwei Rbps erstellen, die sich an verschiedenen Orten befinden, aber denselben ISP verwenden. Ich habe das schon mal gemacht und die Ergebnisse waren fast gleich. Aber ich versuche, weitere Tests durchzuführen.
— Alexander Theißen
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.