NFS über OpenVPN

soul_rebel

soul_rebel

ist immer auf der flucht
Ich habe seit kurzem OpenVPN-Zugang nach Hause.
Ich hab sauch geschafft NFS über OpenVPN einzurichten aber es ist richtig langsam, noch viel langsamer als SFTP :(
Bei SFTP kriege ich ca.l 140KiB/s, mit NFS < 30KiB/s. (theoretisch "könnten" es 400KiB/s sein was wohl aber durch andere Faktoren wie CPU begrenzt wird).

Die Verbindung ist zimelich mies:
Laptop ----> WLAN -----> Router ---> ISP1 ----> ISP2 -----> WLAN ----> SERVER

Trotzdem kriege ich ja mit SFTP 140KiB/s, damit wäre ich zufrieden (ein genügend großer Puffer könnte beim Videogucken ja ruckeln verhindern). Wie kriege ich den Druchsatz auch bei NFS? Eigentlich müsste die Kombo NFS-OVPN ja schneller sein, da NFS die CPU kaum belastet und OpenVPN's SSL auf jeden Fall weniger als SSH...

Momentan laufen OpenVPN und NFS über UDP. TCP soll für verlustreiche Umgebungen besser ja sein, aber andere Quellen behaupten die Performanceeinbußen durch TCP würden den Bonus (im schlechten Sinne) kompensieren.
Was meint ihr dazu? In jeden Fall sollte man bei beiden dasselbe Protokoll verwenden oder ist das egal (NFS kriegt ja nichts von VPN mit)?

Und wie sollte ich rsize und wsize bei NFS wählen und welche anderen Optionen (-a4 ist im moment noch dabei)?

Wie groß würdet ihr dann z.B. den mplayer-cache machen?

Danke für eure Hilfe!

PS.: OpenVPn meldet noch
Code: 
Replay Window backtrack occurred
aber das soll ja normal sein, der NFS-Client bescwert sich zwischendurch öfter das der Server garnicht reagiert...
 
soul_rebel schrieb:
Und wie sollte ich rsize und wsize bei NFS wählen
Zum Vergrößern anklicken....

Also rsize und wsize sollten beim Client etwas kleiner als die MTU sein und eine 2er-Potenz. Ich wähle immer bei beiden 1024 und es klappt ganz gut. Wenn Du das testen willst, dann reicht ein "find" auf einen remote gemountetes /usr/src. Wenn das durchläuft, dann ist meistens alles ok. Da sind nämlich große Verzeichnisse mit vielen Dateien und es entstehen ziemlich große UDP-Pakete, wenn readdir auf dem nfs-Subsystem ausgeführt wird.
 
Probier mal auf Client und Server
link-mtu 1500
fragment 1300
mssfix

und poste mal genauere Angaben.
Also wie bist du unterwegs angebunden? WLAN über WEP2-PSK->Router?
Config von openvpn client und server.

Und prüf mal, ob dein server daheim eine andere mtu hat, als dein NIC unterwegs. Hier sollten allerdings die Configurationsparameter von oben helfen.

nfs würd ich in nem udp-Tunnel definitiv mit tcp nutzen.
 
Also bezüglich des netz-setups, das ist eigentlich komplizierter:
Code: 
Laptop ----> WLAN (offen) -----> Router1 ---> ISP1 ----> ISP2 -----> WLAN ----> Router2 --> SERVER
                                                          |--------OpenVPN1-------|
|------------------------------------OpenVPN2-----------------------------------------------------|
(hoffentlich erkennbar)
Vom Ziel-ISP zum Ziel-Router geht also noch ein zweites VPN, was der ISP zur authentifizierung und Sicherung des WLANS nimmt.

Bezüglich MTUs:
Die MTUs sind überall 1500, außer auf dem Tunnel von OpenVPN1, also zwischen ISP2 und Router2, wo die MTU 1454 beträgt, allerdings läuft auf dem Router2 auch PF mit "scrub".
Soll ich andere MTUs anpassen? Wenn ja, welche? (das sind ja ziemlich viele: client_physisch, client_tunnel, router1, router2_phys, server)


Ich habe jetzt mal das OpenVPN2 komplett auf tcp umgestellt und NFS auch, außerdem bei NFS die rsize und wisze auf 1024 gesetzt. Die Übertragung ist jetzt aber noch viel schlechter :( , vielleicht 13KiB/s.

Ich versuchs jetzt nochmal mit UDP-OpenVPN und tcp-NFS.
 
Hm... mit UDP-OpenVPN kriege ich jetzt wieder timeouts und schlimmeres :(
Code: 
Dec 21 12:41:17 fbsdlap kernel: nfs server server:/mnt/data2/audio: not responding                                  
Dec 21 12:41:18 fbsdlap kernel: nfs send error 35 for server server:/mnt/data2/audio                                
Dec 21 12:41:33 fbsdlap last message repeated 15 times                                                              
Dec 21 12:41:33 fbsdlap kernel: nfs/tcp clnt: Error 60 reading socket, tearing down TCP connection

Ich versuch gleich noch die von Troll vorgeschlagenen Optionen. Sollte ich da jetzt auch eine MTU von 1500 nehmen, obwohl das ganze ja noch über die andere OpenVPN-Verbindung mit niedriger MTU muss?
 
Die MTU der Rechner kannst du einfach so lassen.
OpenVPN udp und nfs tcp ist aber schon das, was ich am sinnvollsten finde. Ich Tunnel damit teilweise durch EDGE wenn nix anderes verfügbar ist und das läuft sauber.
 
Kannst Du nicht SSHFS oder so verwenden? SFTP mit FUSE?

Mit NFS ueber OpenVPN und WLAN hab ich bisher nur Probleme gehabt, inklusive kaputter Files. NFS wuerde ich nur ueber stabile Verbindungen wie ein LAN verwenden.

Empfehlen koennte ich Dir da eher Coda. Da wird zwar extrem lokal gecached, aber das Netz und der Server werden wenig belastet.

Just my 2 cent...
 
Hast du NFS über SSH mal ausprobiert?
Ich habe das vor ca. nem halben Jahr mal getestet weil mir OpenVPN für den zweck zu aufwändig war. Der Durchsatz war eigentlich gut. Auf die CPU Last meiner 166Mhz Gegenstelle habe ich allerdings nicht sehr geachtet.
 
Also mit allem hin und her und auch mit Trolls empfehlungen erreiche ich mit NFS über VPN immernoch nur ca 30=KiB/s (im besten Fall). Da stimmt doch was nicht :(

Ich habe mal schnell sshfs aufegesetzt, und mit SSHFS über OpenVPN (der SSH-Port ist ja nicht öffentlich) ohne sonstige Optimierungen erhalte ich direkt 140KiB/s. Das reicht schon um niedrig-kodierte Filme zu gucken, Dolphin und Konqueror stottern beim lesen des Dateisystem aber schon ziemlich vor sich hin.

Und sshfs ist ja auch keine schöne Lösung. Ich wollte NFS und OpenVPN weil die Kombination eigentlich richtig gut ist:
OpenVPN macht schlüsselbasierte Authentifizierung+Verschlüsselung, weist dann eine IP zu, und der NFS-Server gibt frei anhand der IP
=> schön transparentes Sicherheitskonzept, niedrige CPU-Last, platformunabhängig(auch OpenBSD, DfBSD..)

Mit SSHFS wird das alles komplizierter :(

edit: Coda dürfte da auch wesentlich komplizierter werden.
 
Zuletzt bearbeitet:
Ich versuche jetzt Schritt für Schritt die Slowdowns auszumachen:

Erster Schritt: OpenVPN

OpenVPN scheint auf jeden Fall eine Verlangsamung.
Habe mal einen SSH-Port nach außen aufgemacht, ohne VPN kriege ich mit SCP ~190KiB/s, über den VPN-Tunnel mit SCP ~130KiB/s.

An der extra-CPU-Last durch OpenVPN liegt es definitv nicht.
Die OpenVPN-Configs sind identisch mit den examples[1], zusätzlich noch die Optionen von Troll.

[1] http://openvpn.net/howto.html#server
 
tcpdump tun0
Und dann nfstraffic via tcp. Sorry, um so ne Analiese wirst du wohl nicht drumrumkommen.
Die 130kb/s vs 190kb/s sind zu langsam. Soviel Overhead macht OpenVPN nicht. lzo reisst das wieder raus.
Was macht die CPU-Last auf den beiden Kisten während du kopierst?

Bist du hundertprozentig sicher, dass du nicht nen Bock in der Netzwerktopologie hast?
Eine Kollision der gepushten Route und dem Netz, in dem sich der Client befindet?

Welche IP/Netmask hat der Server?
Welche IP/Netmask hat der Client?
Welche IPs haben die tun-Interfaces der beiden Kisten?
Welche Route wird gepusht?
Sprichst du den OpenVPN-Server über die IP des tun-Interfaces an, oder über die IP seiner Netzwerkkarte?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben