OpenVPN tuning

[h^2]

Hallo Leute,

Ich verwende schon seit einer Weile OpenVPN, vor allem im Zusammenhang mit NFS. Leider ist die Performance nicht so wirklich gut. Das liegt z.T. auch an NFS, aber auch so bekomme ich mit scp über openvpn weniger als die Hälfte des Durchsatzes von scp direkt.

Ich habe nun oft gelesen, dass es an MTU-Konflikte liegen kann. Also, dass alle Daten zwei Mal zerhackt werden, einmal für das tun-device, dann nochmal fürs physische Gerät.
Dafür (bzw. dagegen) gibts jetzt ganz viele unterschiedliche Parameter:
tun-mtu
link-mtu
fragment
mssfix
mtu-disc

Manche Quellen behaupten, man solle auf jeden Fall fragment setzen, andere behaupten, das würde in jedem Fall die Performance schlechter machen. mtu-disc(overy) funktioniert unter FreeBSD leider nicht.
Andere Quellen [1] behaupten das sei alles mist, ich bin ein bisschen ratlos.

Momentan ist die MTU auf allen devices 1500 (physisch + tunnel, auf clients und server).

[1] http://serverfault.com/questions/272...fs-performance

[h^2]

Ich habe jetzt tun-mtu auf 1400 gesetzt um sicher zu geheh, dass die pakete zwischen tunnel-geraet und physischem nicht nochmal verkleinert werden. Bringt aber nichts. Die Durchsatz ist immernoch zwischen 30-40% vom Durchsatz ohne vpn. Die CPU-load auf beiden Seiten des Tunnels ist vernachlaessigbar...

Woran kann das liegen?

[Columbo0815]

Vielleicht OT: Ich hatte vor ein paar Jahren mal nfs über OpenVPN getestet. Die Performance war grauselig.

Ich hatte damals (iirc) die rsize und wsize (Parameter am nfs-client) auf 8096 gesetzt und hatte damit die besten Ergebnisse (akzeptable).

An den VPN-MTU-Werten hatte ich nichts verändert.

Vielleicht hilft es dir ja?

Gruß

[h^2]

NFS hat Performanceprobleme, aber ich kann das auch vollstaendig mit sftp reproduzieren. Hat also nichts mit den OpenVPN-Problemen zu tun.

OT: bei NFS habe ich uebrigens unabhaengig von VPN tatsaechlich festegestellt, dass TCP das schnellste ist.

[Crest]

Das Problem dürfte die mehrfach Fragmentierung sein. Ein Blick in den Traffic mit tcpdump sollte helfen diesen Verdacht zu prüfen. Diese mehrfache Fragmentierung ist nur dann nötig, wenn die PMTU nicht korrekt ermittelt werden kann. Wie wäre es damit einfach mal die MTU des Tunnels auf < 1500 zu reduzieren und ICMP durch zu lassen?

[h^2]

Zitat von h^2

Ich habe jetzt tun-mtu auf 1400 gesetzt um sicher zu geheh, dass die pakete zwischen tunnel-geraet und physischem nicht nochmal verkleinert werden. Bringt aber nichts. Die Durchsatz ist immernoch zwischen 30-40% vom Durchsatz ohne vpn. Die CPU-load auf beiden Seiten des Tunnels ist vernachlaessigbar...

Woran kann das liegen?

Zitat von Crest

Das Problem dürfte die mehrfach Fragmentierung sein. Ein Blick in den Traffic mit tcpdump sollte helfen diesen Verdacht zu prüfen. Diese mehrfache Fragmentierung ist nur dann nötig, wenn die PMTU nicht korrekt ermittelt werden kann. Wie wäre es damit einfach mal die MTU des Tunnels auf < 1500 zu reduzieren

Habe ich doch gemacht, siehe oben.

und ICMP durch zu lassen?

pings mit size 1300 :

50 packets transmitted, 50 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 380.378/529.510/2229.806/359.840 ms

ping mit size 1600

50 packets transmitted, 50 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 866.826/1233.702/2175.933/267.361 ms

ABer ich dachte das ist normal
[die hohen Pingzeiten leigen daran, dass ich in Asien bin gerade]

[Illuminatus]

ich habe von diversen WAN Optimierungen mittels Appliances von Bluecoat und f5 gehört, welche auch NFS beschleunigen sollen. Ob jetzt http://www.trafficsqueezer.org/ für dich interessant ist kann ich leider nicht beurteilen