Ich habe den Eindruck, daß da noch ein Begrenzer wirkt.
Ich kenne (zumindest bei der 7490) keinen ... was AVM m.E. damals eingebaut hatte, war die generelle Begrenzung für allen Traffic, sowie ein Telefongespräch geführt wird - siehe "TelephonyReduce" unter "/proc/net/avm_pa/status"; das wird vom "telefon"-Daemon automatisch eingeschaltet, wenn ein Telefonat startet. Man kann sicherlich den Wert an dieser Stelle noch etwas weiter reduzieren, bei den heute üblichen DSL-Leitungen ... es gibt im Freetz-NG m.W. einen Patch dahingehend. Nur sollte dieser eben auch nur dann angewendet werden (ich weiß nicht, wie es heute ist, früher war der "unconditionally"), denn für Leitungen mit eher kleinem Upload (ADSL in blühenden Landschaften, wie der Heide) sind 10% Reduktion etwas anderes, als für eine 100/40-Leitung. Andererseits wirkt das ohnehin nur dann, wenn gerade telefoniert wird und spielt ansonsten keine Geige.
Ich glaube auch deshalb nicht an eine "Bremse" (außer in Form von schlecht geschriebenem Code vielleicht, aber den sähe man für den "kdsldmod.ko" von AVM ja auch nicht, selbst wenn es so wäre), weil bei ausgelastetem VPN auch mind. ein Kern des Prozessors ausgelastet ist ... auch wenn das nicht seinen Ausdruck in den Werten bei "usr" oder "sys" findet. Aber mit der Behandlung von Software-Interrupts (sirq) läuft dieser eine Core am Anschlag (diese Interrupt-Behandlung erfolgt wohl innerhalb des "kdsldmod.ko" und es dürfte darauf hinauslaufen, daß da die eigentlichen Crypto-Operationen stattfinden) und nun ann es ja durchaus sein, daß AVM da Verarbeitungswege geändert hat, beim Versuch diese (für "nicht-VPN-Traffic") zu optimieren und es damit tatsächlich schlimmer/schlechter wurde.
Schon die Änderungen am Netzwerk-Code (die dann mit den zurückgebliebenen "BUG_ON"-Statements endeten, die OpenVPN (bzw. alles, was "tun" benutzt) ohne Patches abstürzen lassen), die auf andere Nutzung von Buffern hinausliefen (ich bleibe ja dabei, daß vieles für die Einbeziehung des "CBM" (Central Buffer Manager) von Lantiq geändert wurde von AVM), könnten (! - mehr als spekulieren kann man halt ohne Quellen nicht) auch dazu führen, daß VPN-Verbindungen nun besonders ineffizient gehandhabt werden (wie gesagt, die müssen (im Moment) am Ende IMMER durch die CPU zur Verarbeitung und profitieren von der MPPE (oder auch dem "avm_pa") praktisch gar nicht), weil die Daten vielleicht noch öfter im Speicher hin- und hergeschoben werden (und durch den Switch-Port zur CPU müssen), als das früher der Fall war und die Priorität der Behandlung solcher "software managed buffers" ggf. auch niedriger angesetzt wird (wenn ein HW-Interrupt die Behandlung von Software-Interrupts unterbrechen darf).
=============================================================================
Nun ist eben VPN auch nicht ausschließlich die Anwendung von AES128 auf die Daten ... auch wenn das der größte Teil des Ressourcenverbrauchs sein sollte, solange das nicht hardware-seitig ausgeführt wird (einfach weil es die meisten Rechenoperationen und die meisten Speicherzugriffe sind, wenn mehrere Verschlüsselungsrunden (10 bzw. 11 bei AES128) auf dieselben Daten angewendet werden).
Code:
[...]
Doing aes-128-cbc for 3s on 1024 size blocks: 20692 aes-128-cbc's in 3.00s
[...]
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 5919.15k 6729.17k 7003.14k 7062.87k 6993.24k
20692 * 1024 Byte / 3 s = 21.188.608 Byte / 3 s = 7.062.896 Byte/s
Auf "Bits" umgerechnet, ist das mit 7.062.896 * 8 Bit / 1 s = 56.503.168 Bit/s dann sogar deutlich mehr, als die meisten Leitungen im Upstream haben ... die Ansage mit "1000s" sicherlich deshalb, weil es keine Vielfachen von 2 (also 2**10) sind, sondern von 10 (also 10**3) sind.
Das ist aber auch das "rohe" Ergebnis, bei dem die gesamte Umgebung bereits eingerichtet ist und es wird nur noch die Anzahl der Iterationen in den drei Sekunden gezählt:
https://github.com/openssl/openssl/blob/master/apps/speed.c#L761 - das "AES_cbc_encrypt" besteht aus der CBC-Implementierung (welche die Keys sichert und "schiebt" für die nächsten Aufrufe) und der eigentlichen, ohnehin immer in 16-Byte-Blöcken (= 128 Bit) ablaufenden AES-Verschlüsselung.
Aber man sieht schon bei diesen Zahlen deutlich, daß bei 16 Byte-Blöcken (wir erinnern uns, daß AES128 auch immer in 16 Byte-Blöcken verschlüsselt), alleine der Overhead beim Aufruf der "AES_cbc_encrpyt()"-Funktion (wenn also für die Verschlüsselung von 1.024 Byte am Ende 64-mal die Funktion mit 16 Byte-Blöcken aufgerufen wird) mit mehr als 16 % zu Buche schlägt ... werden die Blöcke dann wieder größer (also der Test mit 8192 Byte-Blöcken), wirkt sich vermutlich die Größe von Prozessor-Caches für Speicherzugriffe aus (wobei das ja auch vergleichsweise gering ist mit ~1% - die Zahlen (6.993,24 / 7.062,87 => 0,9901) "betrügen" hier das menschliche Auge auch schnell, wobei wieder der "call overhead" nur bei 1/8 liegt im Gegensatz zur 64 bei 16 vs. 1024), wo dann weitere Speicherzugriffe auf die "hinten liegenden" Daten die zuerst im Cache liegenden verdrängen.
Aber die absoluten Werte dieses Speed-Tests aus OpenSSL kann man ohnehin nicht ohne weiteres auf die "Praxis" übertragen - die dienen eher nur als Vergleich zwischen verschiedenen Plattformen (so, wie ich es versucht habe zu zeigen). Schon die Frage, wieviel da parallel noch lief zum Zeitpunkt so einer Messung, verfälscht dieses Ergebnis deutlich - das OpenSSL wäre auf einer (einigermaßen ausgelasteten) Maschine ja in den drei Sekunden auch nicht pausenlos die aktive Task im Scheduling.
=============================================================================
Ich will noch einmal festhalten, daß vieles zum AVM-WAN-Stack und auch zur VPN-Implementierung auch falsch sein könnte ... das basiert eben nicht auf der Kenntnis konkreter Quellen, sondern nur auf Quervergleichen mit den verfügbaren Kernel-Quellen von AVM, den Quell-Paketen anderer Hersteller, die ebenfalls Lantiq-/Intel-SoCs einsetzen und ein paar allgemeinen Prinzipien bzw. Überlegungen. Wo es (vergleichbare und öffentlich zugängliche) Quellen gibt, verlinke ich ja auch desöfteren dorthin, damit sich jeder Leser einen eigenen Eindruck verschaffen kann.
=============================================================================
wir setzen ziemlich breit Draytek 2925/2926 ein, die unterstützen Hardware-VPN.
[...]
Draytek 2926 etwa 200€ brutto
Ja, das sind nette Devices ... nur eben eine andere Zielgruppe. Ich habe oben vielleicht etwas unglücklich formuliert ... ich meinte damit SOHO-Router mit Crypto-Hardware (m.W. basiert die Draytek Vigor 2925-Serie ebenfalls auf Lantiq-SoCs - bei der 2926 weiß ich es nicht und ich finde auch gerade keine (verläßliche) Quelle, was da verbaut ist, nur ein Bild vom PCB:
https://www.mbreviews.com/draytek-vigor2926-review/), die in derselben AIO-Liga spielen, wie die FRITZ!Boxen.
Den Widerstreit in den AVM-Boxen zwischen den vielen Funktionen und der beschränkten Leistungsfähigkeit der Hardware, hatte ich letztens erst irgendwo anders (iirc) ... hier haben natürlich die Hersteller, die einerseits weniger Funktionen implementieren und andererseits dabei auch noch auf die "originalen" Lantiq-Quellen setzen und das aus der Hardware herausholen, was sie hergibt an "special processing", dann die Nase vorne und man staunt immer wieder, wie leistungsfähig so etwas (angesichts der Architektur, die natürlich auch ihre Vorteile hat und das geht vom Preis bis zum Energiebedarf) am Ende sein kann.
Wer sich tatsächlich eine Installation aufbauen will, bei der weder Telefonie (der 2926Vac kostet dann wieder ab 350 EUR, mit 2x RJ-11 für analogen Anschluß, keine DECT-Basis) noch Smart-Home eine Rolle spielen (und auch die anderen "Zusatzfunktionen" wie (schlechtes) NAS usw. nicht benötigt werden, wobei die 2926 auch USB2-Ports haben, an denen FTP und SMB (mit einer eigenen SMB-Implementierung) genutzt werden können), sondern das Hauptaugenmerk auf der (eigentlichen) Aufgabe der Internet-Anbindung liegt (wo der Vigor dann nur Edge-Router ist bzw. vielleicht noch WLAN-APs managed - wenn der WAN-Zugang nicht per se schon Ethernet ist, braucht's auch dafür noch irgendein Modem, dafür kann der Router das dann aber auch gleich "doppelt"), der ist mit den Vigor-Modellen (inzwischen ja auch mit WLAN - wobei die 200 EUR eben auch nur für das "Basismodell" ohne WLAN gelten) tatsächlich gut bedient ... nur sollte man dafür auch ausreichend Ahnung von Netzwerken haben und wie es am Ende bei der Sicherheit der Firmware generell aussieht, mag ich auch nicht beurteilen.
Immerhin ist hier Draytek auch nur ein (meinetwegen mittelgroßer, wobei ich keine Zahlen für die Marktanteile von Draytek im SOHO- bzw. SMB-Router-Segment kenne) Fisch von vielen, die sich im Teich dieses Marktes tummeln und so, wie Cisco oder Juniper oder wer auch immer für andere Knoten in Netzwerken eine tragende Rolle spielen und damit das bevorzugte Ziel von Angriffen werden, gilt das in D wohl für die FRITZ!Boxen, wenn die kolportierten Zahlen stimmen. Da kümmert sich praktisch niemand dediziert um die Untersuchung der Firmware - für die 2926-Serie gibt's die GPL-Teile auch nicht wirklich bei Draytek, zumindest nicht ohne weiteres auf deren Server dafür:
http://gplsource.draytek.com/
Insgesamt läppert sich jedenfalls eine Installation, deren Funktionsumfang und Leistungsfähigkeit/-angebot sich mit dem einer FRITZ!Box vergleichen läßt, mit einem Gerät aus der Vigor2926-Serie (
https://www.draytek.de/vigor2926-serie.html) dann doch ganz schön ... dafür erhält man mit einem solchen Gerät wieder Funktionen, die so manchem FRITZ!Box-Besitzer das Wasser im Munde zusammenlaufen lassen (von VLANs bis VPN und Telnet-/SSH-CLI).
Aber schon das zeigt deutlich, daß es sich um vollkommen unterschiedliche Geräte mit sehr unterschiedlichen Zielgruppen handelt ... dem durchschnittlichen Verbraucher, der "nur" sein Heimnetz irgendwie mit dem Internet verbinden will, würde ich diese Geräte (nicht nur wegen des Preises, wobei sich ja schon AVM eher am oberen Ende des Preissegments bewegt) eher nicht empfehlen - die hat man eben auch schnell mal total verkonfiguriert und dann steht man am Ende nackt im Internet bzw. "spies" im LAN haben leichtes Spiel. Als reines "Zusatzgerät" für das Herstellen von (leistungsfähigen) VPN-Verbindungen ist es m.E. ebenfalls zu teuer und die Frage der Konfiguration ohne entsprechende "Vorkenntnisse" steht da genauso.
Letzteres gilt zwar für zwei RPi4 als "Client" in den FRITZ!Box-LANs ebenso ... ohne ein paar (m.E. grundlegende) Kenntnisse kommt man da nicht weiter. Aber es gibt da eben auch für fast jede Problemstellung ein Projekt, was sich mit dieser beschäftigt ... vom PiHole über OpenMediaVault bis hin zum PiVPN (
https://pivpn.dev/) und viele davon kann man auch miteinander kombinieren, solange man die "kleinen Kerle" damit nicht an den Rand der Auslastung treibt (die 4er-Modelle werden eben auch schnell heiß und dann schlägt "thermal throttling" zu, was die Performance insgesamt senkt).
Vom Preis-/Leistungsverhältnis habe ich jedenfalls (bis 40-50 MBit/s im Upstream als "Ziel" für die Auslastung) noch nichts besseres gefunden ... wie gesagt, zwei von den Devices (1 GB RAM reicht vollkommen, ebenso i.d.R. eine Speicherkarte (µSD) aus der Bastelkiste und sogar ein Netzteil mit USB-C-Stecker haben die meisten ohnehin noch irgendwo herumliegen, wobei die notwendige Leistung auch noch davon abhängt, was man an die USB-Ports anschließen will) schlagen jede beliebige FRITZ!Box ganz locker und mit Packet-Acceleration schafft das dann die Box auch, die Pakete schnell genug auf ihre "WAN-Seite" zu expedieren.
avm.de
