Fritzbox 7490 / Asus Router RT-AC 88U

B

Balu66

Neuling
Thread Starter
Mitglied seit
05.11.2017
Beiträge
2
Hallo zusammen!

Ich habe folgendes Problem und zwar habe ich eine Fritzbox sowie einen Asus Router RT-AC 88U mit ASUS WRT Merlin aufgesetzt. Auf diesen läuft OPENVPN als Client eingerichtet mit fertigen Config Datein ( VPN Anbieter). Nun zu dem Problem ich habe eine 100Mbit/s Leitung diese läuft auch schnell wenn der vpn client aus ist mit erreiche ich grade mal 17,50 Mbits Down / UP 28,80 Mbits es spielt auch keine Rolle ob ich nun Germany oder Niederlande oder so nutze liegt ein Defekt an dem Asus vor? Schalte ich VPN aus erreicht der Asus 95Mbits ? Verbunden ist die Fritz und der Asus per Lan Kabel und alle anderen Geräte auch .
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Die Wahrscheinlichkeit, dass der Router bremst, ist gering, da der ja ohne den VPN-Anbieter (welcher auch immer das ist...) 95 Mbit/s erreicht. Somit gehe ich davon aus, dass das der VPN-Anbieter ist.

Gibt es bei diesem ominösen VPN-Anbieter auch die Möglichkeit, einen Client auf einem PC zu installieren? Falls ja und das ergibt das selbe Bild, ist das eindeutig der VPN-Anbieter.
 
Ja habs mit dem client direkt versucht genau das selbe problem. Es liegen jetzt nurnoch 9000 im down an egal zu welcher zeit oder ob der server gewechselt wird.
 
Eye-Q schrieb:
Die Wahrscheinlichkeit, dass der Router bremst, ist gering, da der ja ohne den VPN-Anbieter (welcher auch immer das ist...) 95 Mbit/s erreicht. .
Zum Vergrößern anklicken....

Hast du eine Begründung für diese Annahme?
Es gibt einen Grund, warum es die "Maßeinheit" namens "IPSEC Performance" bei z.B. Routern gibt.

Ist jetzt die frage, wie genau das VPN gemacht wird, insbesondere die Verschlüsselung ist dabei ein wirkliches Problem.
Es wird auf jeden Fall so sein, dass der TE nicht die volle Bandbreite nutzen können wird, da die Plasterouter idR <50mbit IPSEC zumachen.
Der ASUS mag zwar potent sein, aber auch ne DC CPU ist jetzt nicht der Knaller bei sowas, je nach Situation.

Allerdings muss man sagen, dass in dem Fall der Speed symmetrisch begrenzt ist, da die Verschlüsselung ja UL und DL gleich funktioniert.
Bei der Abweichung würde ich im Moment auch von einem Serverproblem ausgehen.
 
Hier geht's nicht um IPsec. Im ersten Post steht doch OpenVPN.

OpenVPN ist ein Userspace-VPN, d.h. jedes Paket muss durch ein tun(4)-Interface in den Kernel und wieder zurück, was massiv Kontextswitche verursacht. Das kann auf diesen Embedded-Plattformen sehr schnell zum Engpass werden. 30 Mbps klingt plausibel für diese Kisten, mehr wird's nicht werden.

Was man testen kann: den OpenVPN-Client auf einem PC installieren, um den Server als Flaschenhals auszuschließen.
 
Ich kann lesen. ;)
Ob nun IPSEC oder OpenVPN ist eigentlich völlig Bratwurst, das Problem ist, dass Verbindungen verschlüsselt werden und das kostet Zeit und limitiert damit die Verbindung.

Eine gänzlich unverschlüsselte, weil dann nur geroutete Verbindung, hat die maximale Performance.

Und Verschlüsselung ist nunmal einiges an Rechenleistung und daher ein Problem für die GurkenCPUs in den Plasteroutern.
Ich könnte wetten,eine OpenVPN "Distri" würde auf einem normalem x86-System würde bei den Bandbreiten nur müde lächeln. (analog zu deinem Vorschlag)

Ich könnte wetten, wenn er nen PPTP-Tunnel aufbaut, sieht der Speed anders aus.
Aber bitte PPTP nicht betreiben, da es mehr als anfällig ist. Nur zum Testen.

Das Userspace-Thema mag auch ein Punkt sein, ist aber im Verhältnis zur reinen Rechenarbeit zu vernachlässigen, meine Meinung. (würde man ja mit dem PPTP-Thema ggf. auch rausbekommen, denn die Kontextswitche wäre gleichviel)
 
Zuletzt bearbeitet:
Das sieht "der" Macher von OpenVPN etwas anders.
RE: [Openvpn-users] Re: Why in user space

In my own benchmarks, I've found that OpenVPN spends a vast
majority of its processor time doing low-level crypto operations, and the
context switching time between user and kernel space is probably only a
few percent on modern OSes.
Zum Vergrößern anklicken....

Kann man ja gerne benchmarken was das Conextswitching tatsächlich bedeutet im Vergleich zur Verschlüsselung bei den Plasteroutern.
Ich kann nur aus Erfahrung sagen, dass Verschlüsselung ein ernstes Problem ist (unabhängig von OpenVPN). Daher gibt es ja auch die Hardwarebeschleunigung dafür.
Klar ist, je besser die Verschlüsselung läuft, desto stärker wirkt der Contextswitch. Aber die Plasterouter sind wohl weit entfernt von gut laufen @Verschlüsselung.
Das mag auf einer aktuellen x86 Plattform und ggf. 10GBE anders aussehen. Da muss man dem Contextswitch mit der MTU-Size begegnen, das gilt aber eh schon für den TCP-Offload.
 
Zuletzt bearbeitet:
ZeroTier | Connect All The Things

Wobei auf einer Kiste mit AES-NI der Einfluss von Crypto nicht so stark sein sollte. D.h. die Unterschiede da sind mehr oder weniger die durch die Kontextswitche verursachten. Auf einem Embedded-Gerät kann man dann noch davon ausgehen, dass bei weitem nicht dieselbe Speicherbandbreite zur Verfügung steht. Also fallen die Kopieroperationen bei einem Kontext-Switch gleich noch mehr ins Gewicht.
 
Zuletzt bearbeitet:
Genau das AES-NI ist doch genau das Thema. Wenns der CPU "egal" was die Verschlüsselung macht, wird das Contextswitch tatsächlich ein Faktor.
Rechnet sich die CPU aber am AES (oder sonstwas) zu Tode, ist es egal ob sie nun Daten umladen muss oder nicht.

Solange auf den Plasteroutern keine AES-Beschleunigung vorhanden ist, ist das eben der bestimmende Faktor.
Sollen den Benchmark mal auf nem alten Prossi laufen lassen, dann kann man das abschätzen, was mit und ohne AES geht.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh