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
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.
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.
