SSH wird nach Sekunden sehr langsam

dernettehans schrieb:
Wenn du Wireguard nutzt teste mal ein MTU von 1360 zb anstatt 1420. Oder mach genauere Ping tests bezüglich MTU über die VPN, öffne CMD und mach am Client hinter dem VPN:

ping -f -l 1400 1.1.1.1
ok, Verständnisfrage - ich baue die VPN Verbindung auf (aktuell MTU 1380) - connecte mich über ssh auf die andere Seite. Dort führe ich dann dein ping aus .. aber dann nimmt der doch seine lokale Verbindung auf seiner Seite zu seinem Router und dort ins internet und nicht über die VPN Verbindung ? Oder komme ich durcheinander und deine 1.1.1.1 cloudflare DNS IP war nur ein beispiel und ich sollte meinen wireguard client anpingen ?
 
probiert doch mal testweise einen schlichten p2p filetransfer mit syncthing oder croc von einem großen "unpersönlichen" file.
z.b. eine linux-iso oder ähnliches. und zwar ohne vpn/opnsense bzw. abseits eurer speziellen aufbauten.
einfach direkt mit einem client raus, der am hauptrouter hängt.

wenn es durchgehend schnell läuft, ist es wahrscheinlich weder der isp (peering, drosselung bzw. zu niedrig priorisierter traffic...) noch ein grundsätzliches netzwerkproblem, sondern es liegt wohl an der speziellen konfiguration eures vpn tunnels und allem was da noch "custom" ist.

wenn dieselbe symptomatik wie beanstandet auftritt, wisst ihr, dass es nichts mit dem vpn oder euren besonderen sicherheitsvorkehrungen ist, sondern ein übergeordnetes problem, also entweder auf netzwerkebene bei einem oder (unwahrscheinlicher) beiden von euch oder eben isp.
 
JumpingCat schrieb:
nein, der shaper hat keine Einträge und habe wie gesagt nur 2x NAT eingerichtet.
1725648712635.png
 
Ne du sollst erst mal nur den Wireguard Tunnel testen auf korrekten MTU Wert, was durch gerouted wirst weisst ja du also ip adresse anpassen.
 
Redundanz schrieb:
probiert doch mal testweise einen schlichten p2p filetransfer mit syncthing oder croc von einem großen "unpersönlichen" file.
habe beide seiten kurz syncthing eingerichtet .. das kopiert nur mit 1-12 mbit stark schwankend, habe mal verbindungen 0 - und 2 getestet beidseitig.. damit komme ich wohl nicht weiter. evtl. bei meinen eltern ein notebook morgen hinstellen und wireguard verbindung nach dort machen um schonmal eine seite auszuschließen :)
Ergänzung ()

dernettehans schrieb:
Ne du sollst erst mal nur den Wireguard Tunnel testen auf korrekten MTU Wert, was durch gerouted wirst weisst ja du also ip adresse anpassen.
ping -f -l 1320 10.253.1.2
--- 10.253.1.2 ping statistics ---
51429 packets transmitted, 48878 received, 4.96024% packet loss, time 1958ms
rtt min/avg/max/mdev = 13.093/47.894/111.969/18.468 ms, pipe 1321, ipg/ewma 0.038/58.114 ms

ping -f -l 1380 10.253.1.2
--- 10.253.1.2 ping statistics ---
141461 packets transmitted, 136827 received, 3.27581% packet loss, time 5023ms
rtt min/avg/max/mdev = 13.793/47.942/85.851/14.041 ms, pipe 1381, ipg/ewma 0.035/67.940 ms

ping -f -l 1420 10.253.1.2
--- 10.253.1.2 ping statistics ---
185408 packets transmitted, 180982 received, 2.38717% packet loss, time 6545ms
rtt min/avg/max/mdev = 13.442/49.533/109.991/14.364 ms, pipe 1421, ipg/ewma 0.035/47.476 ms

die Wireguardverbindung läuft konfiguriert auf 1380 .. und syncthing läuft noch mit ca. 5mbit upload
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Redundanz
Erm........ 4.96024% packet loss, time 1958ms !? Da hast du doch dein Problem? Die Leitung hat ja scheinbar packet loss daher drosselt das TCP receive window runter. und das ist doch kein windows client oder doch?
 
  • Gefällt mir
Reaktionen: Redundanz
die time ist die laufzeit .. der pingbefehl mit -f ist endlos .. soll ich das ne woche laufen lassen und dann wäre die latenz 1 woche ? :) anhand deiner letzten Antwort würde ich sagen du hast es selber noch nie gemacht, sonst wüsstest du das
 
  • Gefällt mir
Reaktionen: Redundanz
groover schrieb:
2.38717% packet loss, time 6545ms

Hast du kein Traffik Shaper aktiv und deswegen Packet Loss? 😉

btw syncthing sollte die Leitung problemlos auslasten können. Darfst aber halt nicht 100% als Speed angeben, dann hast du Packetloss. Und du darfst nicht in die GUI schauen, weil aus Performance gründen ist die nicht aktuell / korrekt bein Durchsatz.

Faustregel: Entweder limitierst du auf 85% den Upload und Download oder sogar noch stärker bis der ping sich so verhält als wäre kein Traffik. OpnSense ist hierfür das ideale Tool für den SoHo Bereich weil es eine so granulare und vielfältige Konfiguration anbietet.

btw habe aus Gründen meine OpnSense durch ein Ubiquiti Cloud Gateway Ultra ersetzt. Mit dem Wissen von pfSense und OpnSense über die Jahre war der Setup dort sehr einfach.
 
  • Gefällt mir
Reaktionen: Redundanz
groover schrieb:
die time ist die laufzeit .. der pingbefehl mit -f ist endlos
Nö. Die command line argumente sind ja OS spezifisch bzw welches Ping genutzt wird. Ich hatte extra gefragt ob es Windows ist. "ping -f" heisst dass die Pakete nicht fragmentiert werden sollen bei dem Windows Ping, "-t" ist unter dem Windows Ping endlos. Am besten googelst du mal wie du den MTU jetzt richtig misst über das Ping von deinem OS, welches das auch sein mag mit den korrekten attributen.
 
ok .. ping andere parameter unter windows als macos und linux .. was gelernt. danke

shaper von opnsense ist also QoS .. ok .. wüsste nicht warum es ohne QoS auf 20% der Leitung einbrechen sollte (oder 10% bei syncthing) wenn sonst nichts los ist im Netz .. aber kann man ja mal machen.
 
mh, also folgende Tests durchgeführt. Ein Freund hat auf seinem windows up wireguard installiert und mir einen share gegeben zum upload -> gleiches Ergebnis. Problem also auf meiner Seite.
Dann mit meinem Windows Client verbunden .. kein Problem, Speed bleibt nahe am Maximum und damit Problem mit Unraid.
Nachdem die Unraid 7.0.0 beta 2 auch mit dem Routertausch zeitlich sehr nah war ... mein Unraid mal downgraded auf 6.13. Empfängerseite habe ich auf 7.0.0 beta 2 gelassen ... Transfergeschwindigkeit sieht wieder gut und stabil aus. Mal die Nacht laufen lassen ob es doch noch kommt, aber bisher war die Drosselung in unter 1 Minute immer da.
 
OK, Backup lief ganze Nacht durch:
188GB durch in grob 10 Stunden
5,25 MB/s im Schnitt, also ca 42Mbit

Also ist ein Fehler in der aktuellen Unraid Beta die Ursache.. mal gemeldet. Danke an alle die Hilfsbeiträge leisteten.
 
Zurück
Oben