Speed Drosselung durch ISP mit PP VPN

Alien2016

Freshly Joined Member
Hallo Zusammen,

habe eine 500 Mbit Leitung (Kabel Vodafone) und nach dem Verbinden mit PP VPN drosselt mein Provider auf ca 60-70 Mbit.
Das passiert auf jeden Server und auch auf jedem PC in meinem Netzwerk.

Es gibt die Funktion Stealth VPN in der PP Software unter Einstellungen.
- Stunnel (kann keine Verbindung aufbauen)
- SSH (keinen Einfluss auf die Drosselung)
- Obfsproxy3 (keinen Einfluss auf die Drosselung)

Leider kann ich das Problem nicht lösen.
Hat noch jemand eine andere Idee?

Danke und Grüße
 
  • Like
Reactions: WKV

Xulux

New Member
OpenVPN in der aktuellen Version 2.x untersützt kein MultiCore sondern ist ausnahmslos SingleCore.
Erst mit der noch ausstehenden Version 3 soll MultiCore implementiert sein.

Des weiteren ist die Performance von VPN-Verbindungen maßgeblich abhängig, ob CPU-Seitig HardwareEncryption unterstützt wird.
Bei regulären Dekstop-CPUs ist das der Fall (genant: AES-NI), bei Router-SoC/CPU nicht immer....was sich maßgeblich in der Routert-VPN-Performance niederschlägt. Daher sollte vor einem Routerkauf immer geprüft werden, ob der verbaute SoC HardwareEncryption untestützt.
Auch bei den gerne gekauften ASUS-Routern ist das nicht bei allen Modellen der Fall.

Bzgl. Verschlüsselung gilt der Cipher CBC als deprecated, also veraltet. GCM ist schon lange der neue Standard und i.d.R. auch spürbar schneller.
Leider sind immer noch viele OpenVPN Server so konfiguriert, das diese per Default CBC möchten.

Jedoch erlauben OpenVPN-Server in der Regel, dass der Client den Cipher wählen kann ("cipher negotiation" und muss konfiguriert werden).
Hier ist eigentlich 128-GCM absolut ausreichend, da 128-Bit bzgl. OpenVPN immer noch als unknackbar gilt und in Verbindung mit GCM eine gute Kombination aus Sicherheit und Geschwindigkeit bietet.

In der Summe bzgl. Speed reiht sich jedoch OpenVPN grundsätzlich am hinteren Ende ein, was derzeit logischerweise an der schon lange und noch fehlenden MultiCore-Unterstützung liegt.

Derzeit sind Wireguard und mit Abstand dahinter IPSec/IKEv2 die performantesten Protokolle.
Und Wireguard wird sich in auch mittelfristig als neuer Standard durchsetzen, da bin ich mir absolut sicher.

Da bedarf natürlich, dass die VPN-Anbieter sich bzgl. der Anonymität der User ein bisschen was einfallen lassen müssen (bspw. NordLynx).
Das liegt aber schlicht daran, dass VPN-Protokolle ja nicht "Virtuelle Anonyme Netze" sind, sondern "Virtuelle private Netze".
Der Ur- als auch heutige Zweck ist die Anbindung von Netzen (bspw. Zuhause mit Firma, Firma zu Firma,...)...darin muss keiner Anonym sein, warum auch.
Die VPN-Anbieter nutzen diese Technologie jedoch für einen anderen Andwendungszweck, als wofür VPN eigentlich gedacht war/ist.

Abschließend sollte auch immer mit bedacht gewählt werden, ob man TCP oder UDP verwendet.
Während TCP bei Absenden eines Datenpaketes auf die Bestätigung des Erhalts vom Empfänger wartet (ung dieses ggf. nochmals schickt), so "ballert" UDP einfach ohne Rückantwort die Pakete an den Empfänger.
Daher macht UDP bspw. bei Livestreams durchaus Sinn, wenn Pakete nicht ankommen dann ist das egal...dann hat man kurz ein Artefakt im Bild und weiter gehts. Oder auch bei VoIP,etc.
Aber bei bspw. Dateiübertragungen habe ich ein großes Interesse daran, dass meine gesendeten Datenbakete auch vollständig und korrekt am Ziel ankommen....mit UDP wäre das nicht gewährleistet.
 

FAN

Junior Member
OpenVPN in der aktuellen Version 2.x untersützt kein MultiCore sondern ist ausnahmslos SingleCore.
Erst mit der noch ausstehenden Version 3 soll MultiCore implementiert sein.
Wäre natürlich wünschenswert, aber moderne HT Prozessoren können sehr gut unterstützend wirken, auch wenn die Anwendung nicht explizit MultiCore gecoded wurde. Hab bei mir bei 100mbit Down gerade mal 6% Auslastung der VPNdaemnos bei ner 4er Kaskade mit 256_AES_GCM.
Das wären bei einer einfachen Verbindung 1.5% CPU Auslastung. Da geht noch was ;)
Dennoch ist OpenVPN durch den Aufbau und die Protokolle an sich schon etwas langsamer als andere und ressourcenintensiver.
Des weiteren ist die Performance von VPN-Verbindungen maßgeblich abhängig, ob CPU-Seitig HardwareEncryption unterstützt wird.
Bei regulären Dekstop-CPUs ist das der Fall (genant: AES-NI), bei Router-SoC/CPU nicht immer....was sich maßgeblich in der Routert-VPN-Performance niederschlägt. Daher sollte vor einem Routerkauf immer geprüft werden, ob der verbaute SoC HardwareEncryption untestützt.
Auch bei den gerne gekauften ASUS-Routern ist das nicht bei allen Modellen der Fall.
Beim Routerbetrieb eines VPN sollte man natürlich nicht gerade auf den cent schauen, da muss Leistung her und bestmögliche Unterstützung. Ist aber auch nur sinnvoll wenn man die ganze Bude mit Router und VPN versorgen will. Mit Kaskaden ist dann wohl auch Routermäßig nix drin.
Für Otto Normal reicht der Client aufm Rechner mehr als aus.
Bzgl. Verschlüsselung gilt der Cipher CBC als deprecated, also veraltet. GCM ist schon lange der neue Standard und i.d.R. auch spürbar schneller.
Leider sind immer noch viele OpenVPN Server so konfiguriert, das diese per Default CBC möchten.
Das stimmt und ist leichter angreifbar, aber man kann ja bei PP selber umstellen und wählen. Warum das per default auf CBC statt GCM eingestellt ist ....?!
Bei CBC das kein Counter hat wird z.b. ein nicht benutzer Block jedesmal aufgefüllt und weitergeleitet. da ist z.b. ein Ansatz zum knacken was beim counter mode bzw. dem darauf basierenden GCM so nicht passieren kann da hier ein couter gesetzt wird der hoch zählt. Nur so mal als Beispiel. GCM hat den Nachteil als Beispiel da wird der Key im RAM gehalten was natürlich auch etwas unschön ist aber dennoch besser als CBC. Meiner Meinung nach.
Jedoch erlauben OpenVPN-Server in der Regel, dass der Client den Cipher wählen kann ("cipher negotiation" und muss konfiguriert werden).
Hier ist eigentlich 128-GCM absolut ausreichend, da 128-Bit bzgl. OpenVPN immer noch als unknackbar gilt und in Verbindung mit GCM eine gute Kombination aus Sicherheit und Geschwindigkeit bietet.
Genau. Ich glaube der 128er AES hat sogar Sicherheitsvorteile gegenüber dem 256er. Hab ich mal gelesen das der nen Stückchen sicherer ist, was man so ja eigentlich nicht erwartet. Aber das ganze Krypto-gedöns habe ich mir nicht komplett reingezogen :D
In der Summe bzgl. Speed reiht sich jedoch OpenVPN grundsätzlich am hinteren Ende ein, was derzeit logischerweise an der schon lange und noch fehlenden MultiCore-Unterstützung liegt.
Vielleicht bei richtig dicken Leitungen merkbar, aber was so Homeleitungen betrifft geht das vollkommen in Ordnung.
Derzeit sind Wireguard und mit Abstand dahinter IPSec/IKEv2 die performantesten Protokolle.
Und Wireguard wird sich in auch mittelfristig als neuer Standard durchsetzen, da bin ich mir absolut sicher.
IpSec/IKEv2 sind perfomant das ist richtig, aber auch mit diversen Methoden angreifbar was es für dauerhafte Verbindungen/Übertragungen mit öffentlicher IP eher als ungeeigneter darstellt.
Wireguard ist noch viel zu neu. Da kommen noch die Leaks, denn die Gdienste und cracker sind da mit dabei. Aber ich will da nicht dabei sein. :D
Da bedarf natürlich, dass die VPN-Anbieter sich bzgl. der Anonymität der User ein bisschen was einfallen lassen müssen (bspw. NordLynx).
Das liegt aber schlicht daran, dass VPN-Protokolle ja nicht "Virtuelle Anonyme Netze" sind, sondern "Virtuelle private Netze".
Der Ur- als auch heutige Zweck ist die Anbindung von Netzen (bspw. Zuhause mit Firma, Firma zu Firma,...)...darin muss keiner Anonym sein, warum auch.
Die VPN-Anbieter nutzen diese Technologie jedoch für einen anderen Andwendungszweck, als wofür VPN eigentlich gedacht war/ist.
Verschleiert/Anonymisiert wird ja über fremde Server bzw. deren IP und die Verschlüsselung schützt vor neugierigen Blicken. Dann gibts noch die Stealth option wärs braucht. Was soll man denn noch machen ? Der ISP weiß sowieso dass mit einem VPN Dienst verbunden ist erstmal.
Wer dann noch so tolle billig Logginganbieter hat, der brauch auch nicht wirklich nen VPN. Der erste Schutz ist erstmal nen absolut toller anbieter. Da kenne ich leider nur zwei: PP ........ und als alternative der "alte Schwede" ;)
Abschließend sollte auch immer mit bedacht gewählt werden, ob man TCP oder UDP verwendet.
Während TCP bei Absenden eines Datenpaketes auf die Bestätigung des Erhalts vom Empfänger wartet (ung dieses ggf. nochmals schickt), so "ballert" UDP einfach ohne Rückantwort die Pakete an den Empfänger.
Daher macht UDP bspw. bei Livestreams durchaus Sinn, wenn Pakete nicht ankommen dann ist das egal...dann hat man kurz ein Artefakt im Bild und weiter gehts. Oder auch bei VoIP,etc.
Aber bei bspw. Dateiübertragungen habe ich ein großes Interesse daran, dass meine gesendeten Datenbakete auch vollständig und korrekt am Ziel ankommen....mit UDP wäre das nicht gewährleistet.
TCP ist im Vergleich sehr lahm. UDP sehr schnell. Es gibt Programme wie z.B. TFTP oder P2P (Torrent/emule) usw. die UDP verwenden und das so implementiert haben, das wenn Pakete nicht ankommen, dass es gecheckt wird und diese einfach wieder neu angefordert werden. Klappt super.
Wenn man eine instabile Leitung hat sollte man besser auf UDP verzichten, ansonsten Feuer frei.
Hab da noch keinen groben Aussetzer erlebt.
 

Xulux

New Member
OpenVPN 2.X ist nicht Multi-Threading fähig...was HT folglich mit einbezieht. Hier geht es auch nicht um CPU-Auslastung...

Ich merkte an, dass sich OpenVPN aufgrund der u.a. fehlender Multi-Core-Untersütztung am hinteren Ende einreiht.
Dene Antwort war, dass sich das vielleicht bei richtig dicken Leitungen bemerkbar mache, aber was Homeleitungen betrifft so ginge das in Ordnung....da ist ein Gedankenfehler:
Der möglich VPN-Durchsatz wird durch die eingesetzte Hardware bestimmt.
Wir machen ein sehr simples Beispiel: Ein Raspberry Pi 4 (Multi-Core) würde an einem VDSL 100 einen deutlich geringeren Durchsatz erzeugen, als wenn mit OpenVPN durch Multi-Core alle Kerne genutzt werden könnten....ich denke du verstehst was ich meine.

Stellt man sich hingegen bspw. einen ASUS RT-AX86U in die Wohnung, kann dieser das durch den für eine SoC sehr hohen SingleCore-Takt kompensieren, so dass das bis zu einer gewissen Bandbreite (bis teils gut in den dreistelligen Bereich hinein) nicht auffällt.

IPSec/IKEv2 ist Industriestandard und kann (ja ich weiß, bei manchen kommt der Aluhut-Alarm) als sicher bewertet werden.
Und Wireguard ist auditiert, schon länger im Linux-Kernel-Space integriert und gilt als "prooved". Darum steigen mittlerweile auch im Prinzip alle VPN-Anbieter auf WIreguard um oder bieten es zusätzlich an. Auch bspw. AVM wird beim nächsten FritzOS-Releases fest Wireguard als VPN-Möglichkeit integriert haben.
Soooo neu ist das auch wieder nicht ;-) De fakto erleben wir seit geraumer Zeit überall eine massive Umstiegwelle in allen Bereichen von VPN auf Wireguard.

Meine Aussage zu VPN und Anonymität war in meinem Kommentar auf Wireguard bezogen, nicht auf allgemein VPN.
Wireguard ermöglich "per Design" keine Anonymität auf dem VPN/Wireguard-Server...was für den eigentlichen Einsatzzweck eines VPN auch nicht tragisch ist (Site-to-Site-VPN,etc.)
Nur Anbieter wie PP, Mullvad und Co. (die einen anderen Anwendungszweck von VPN verfolgen) müssen sich hier etwas einfallen lassen. Daher nutzt NordVPN bspw. das genannte NordLynx mit NAT über Wireguard um bei sich intern auf den VPN-Servern die Anonymität zu wahren.

Natürlich ist TCP "langsamer", da auch die Bestätigung des Paketempfanges gewartet wird...was die Gegenstelle ja senden muss.
Und da grundsätzlich Paketverluste immer auf Leitungen auftreten, werden da bei den Abermillionen Bits und Bytes auch etliche Pakete mehrmals versendet.
Deine Aussage bzl. "P2P verwendet UDP aber haben das so implementiert, dass Pakete einfach neu angefordert werden" ist mir zu schwammig.
UDP ist ein standardisiertes Protokoll. Wird etwas über UDP gesendet, so wird per Design nicht auf die Antwort gewartet...und der Empfänger hat per Design auch nicht den Auftrag eine Bestätigung zu senden.
Das von dir beschriebene Verhalten wäre wieder wie TCP...mit allen Vor- und Nachteilen.
Hier würde mich eine technische Erläuterung interessieren, wie auf Basis von UDP trotzdem(!) ohne Performanceverlust die Fehlerkorrektur von TCP zustandekommt....dafür würde es den goldenen Oscar in der IT geben...und den Friedensnobelpreis dazu.

Und beim Rest...nimm es mir bitte nicht böse. Aber das ist unzweckmäßig, wenn andere User andere Usere kommentieren...und eigentlich genau das gleiche sagen, weil sie den Drang haben sich rechtfertigen zu müssen oder es (um eigene Kompezenz darzulegen) nochmals anders bestätigen.

Mein ganzer vorheriger Kommentar ging weder an dich, noch sollte er irgendeine Aussage von dir korrigieren.
 
  • Like
Reactions: FAN

FAN

Junior Member
Hi, ich fühle mich auch nicht angesprochen. Ich wollte nur meine Sicht der Dinge aufschreiben, denn dazu ist ein Forum da. Meinungsfreiheit und dann darf man Kommentare von anderen kommentieren. So das Prinzip.

Zu Rechnenpower, ja OPENVPN braucht halt mehr power aber ich finde das es auf heutigen Systemen weniger ein Problem als vor einigen Jahren. Wer top speed braucht soll halt nehmen was er will.

Was als vermeintlich sicher "proof" angepriesen wird, muss es aber nicht immer sein wie die Vergangenheit gezeigt hat.
IPSec/IKEv2, wireguard, pptp, blaaaah, da gibts genug krytoforen und tests dazu die die Schwachstellen aufzeigen. Ob das standard ist interessiert nicht die Bohne. Wireguard ist erst ein paar Jahre auf dem Markt und wenn eine disti oder kernel-mantainer meinen es müsse oder könne rein dann ist das so.
PP unterstützt es eben NICHT und das aus gutem Grund und darüber hinaus unterstützt Wireguard nur UPD und kein TCP ;)

Ich habe nicht behauptet UDP checkt irgendwas, sondern die Apps, in dem die Gegenstelle die Chunks/Blöcke prüft welch eingegangen sind die z.b. unterteilt sind in 10mb, 5mb, 1mb Stückchen. sollte der Hashwert nicht stimmen wird der kaputte Teil wieder neu angefordert. Klappt schon seit 20 Jahren und mehr so :D

Das geht jetzt nicht gegen DICH sondern ist MEINE Meinung.

Cheers
 

BerndDieBrot

Freshly Joined Member
Bin bei Deutsche Glasfaser und bei O2. Funktioniert 1A!
Ich habe immer selbe geschwindkeit ändert sich kaum. Nur Ping ein bisschen und das erhöht sich nur 2-3ms mehr. Sonst ist alles in Ordnung. Andere VPN Anbieter können sich das ganze abschmieren.


PP ON TOP. Weiter so PP!
 
Top