Ankündigung von NGINX Plus R31

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 31 (R31) bekannt zu geben. NGINXPlus basiert auf NGINX Open Source und ist die einzige All-in-One-Software mit Webserver, Load Balancer, Reverse-Proxy, Inhaltscache und API-Gateway.

Zu den neuen und erweiterten Funktionen in NGINX Plus R31 gehören:

• Native NGINX-Nutzungsberichte – NGINX Plus bietet jetzt native Unterstützung für Berichte zu NGINX-Bereitstellungen in Ihrem gesamten Unternehmen und ermöglicht so eine konsolidierte Ansicht Ihrer NGINX-Infrastruktur im NGINX Instance Manager. Diese Funktion ermöglicht eine verbesserte Governance von NGINX-Instanzen zu Compliance-Zwecken.
• Verbesserungen der SNI-Konfiguration – Bisher verwendete der Servername, der durch Server Name Identification (SNI) weitergeleitet wurde, die Direktive proxy_ssl_name und wurde von allen Servern in der Upstream-Gruppe verwendet. NGINX Plus R31 ermöglicht die Einstellung dieses SNI auf einen ausgewählten Upstream-Server.
• Periodische Aufgabenausführung mit NGINX JavaScript – NGINX JavaScript führt die Direktive js_periodic ein, um die Ausführung von Inhalten in periodischen Abständen zu ermöglichen. Diese Verbesserung macht das Einrichten eines Cron-Jobs überflüssig und kann so konfiguriert werden, dass sie für eine optimale Leistung auf allen oder bestimmten Arbeitsprozessen ausgeführt wird.
• Ein besseres NGINX-Starterlebnis – NGINX Plus R31 bringt Verbesserungen beim allgemeinen NGINX-Starterlebnis in Fällen, in denen die Konfiguration eine große Anzahl von „Standorten“ enthält.
• QUIC+HTTP/3-Optimierungen und -Verbesserungen – NGINX Plus R31 fügt der QUIC-Implementierung viele Erweiterungen und Leistungsoptimierungen hinzu, darunter Unterstützung für die Erkennung der maximalen Pfadübertragungseinheit (MTU), Verbesserungen der Überlastungskontrolle und die Möglichkeit, den kryptografischen Kontext während Ihrer gesamten QUIC-Sitzung wiederzuverwenden.

Abgerundet wird die Version durch neue Funktionen und Fehlerbehebungen, die von NGINX Open Source übernommen wurden, sowie Updates für das NGINX JavaScript-Modul.

Wichtige Verhaltensänderungen

Notiz: Wenn Sie von einer anderen Version als NGINX Plus R30 aktualisieren, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in früheren Ankündigungsblogs für alle Versionen zwischen Ihrer aktuellen und dieser Version.

Abschaffung des OpenTracing-Moduls

Das in NGINX Plus R18 eingeführte OpenTracing-Modul wird jetzt nicht mehr unterstützt. Es ist gekennzeichnet, dass es ab der nächsten Version von NGINX Plus R34 entfernt wird. Das Paket wird bis dahin mit allen NGINX Plus-Versionen verfügbar gemacht. Es wird dringend empfohlen, das in NGINX Plus R29 eingeführte OpenTelemetry-Modul zu verwenden.

Warnmeldung bei Nichtmeldung der NGINX-Nutzung

NGINX Plus-Benutzer müssen ihre NGINX-Nutzung aus Compliance-Gründen an F5 melden. Mit der Veröffentlichung von NGINX Plus R31 ist die Möglichkeit, Ihre NGINX-Nutzung an den NGINX Instance Manager zu melden, nativ vorhanden und standardmäßig aktiviert. Wenn die NGINX-Instanz aus irgendeinem Grund ihre Nutzungsinformationen nicht an den NGINX Instance Manager übermitteln kann, wird eine Warnmeldung protokolliert.

Ausführliche Informationen zum Konfigurieren dieser Funktion in Ihrer Umgebung finden Sie im Abschnitt „Native NGINX Usage Reporting“ .

Änderungen an der Plattformunterstützung

Neue unterstützte Betriebssysteme:

• FreeBSD 14
• Alpine 3.19

Ältere Betriebssysteme entfernt:

• Alpine 3.15, das am 1. November 2023 das Ende seiner Lebensdauer (EOL) erreichte

Ältere Betriebssysteme, die veraltet sind und deren Entfernung in NGINX Plus R32 geplant ist:

• FreeBSD 12 erreicht am 31. Dezember 2023 das Ende der Lebensdauer

Neue Features im Detail

Native NGINX-Nutzungsberichte

NGINX Plus R31 führt eine native Kommunikation mit NGINX Instance Manager in Ihrem Netzwerk ein, um die Lizenzkonformität zu automatisieren. Wenn Sie am F5 Flex Consumption Program teilnehmen, müssen Sie Ihre NGINX Plus-Instanzen nicht mehr manuell verfolgen.

Standardmäßig versucht NGINX Plus, den NGINX Instance Manager beim Start über eine DNS-Suche des Hostnamens nginx-mgmt.local zu erkennen. Obwohl der Hostname konfigurierbar ist, empfehlen wir (der Einfachheit halber), Ihrem lokalen DNS einen A-Eintrag hinzuzufügen, der den Standard-Hostnamen mit der IP-Adresse des Systems verknüpft, auf dem NGINX Instance Manager ausgeführt wird. NGINX Plus stellt dann eine TLS-Verbindung zum NGINX Instance Manager her und meldet alle dreißig Minuten dessen Versionsnummer, Hostnamen und eindeutige Kennung.

Für eine zusätzliche Sicherheitsebene empfehlen wir außerdem , diese Verbindung mithilfe des optionalen Verwaltungskonfigurationsblocks mit mTLS bereitzustellen. In regelmäßigen Abständen meldet der NGINX Instance Manager dann die Gesamtnutzung der NGINX Plus-Instanzen an einen F5-Dienst.

Wenn bei NGINX Plus Probleme beim Auflösen des Hostnamens nginx-mgmt.local oder bei der Kommunikation mit NGINX Instance Manager auftreten, wird in Ihrem Fehlerprotokoll eine Warnmeldung angezeigt.

Dies ist ein Beispiel für eine Fehlermeldung, die angibt, dass die NGINX Plus-Instanz nginx-mgmt.local nicht auflösen kann:

21.12.2023 21:02:01 [Warnung] 3050#3050: Nutzungsbericht: Host zum Auflösen des Endpunkts „nginx-mgmt.local“ nicht gefunden

Und hier ist ein Beispiel für eine Fehlermeldung, die darauf hinweist, dass die NGINX Plus-Instanz Schwierigkeiten bei der Kommunikation mit dem NGINX Instance Manager hat:

21.12.2023 21:02:01 [warn] 3184#3184: Nutzungsbericht: Zeitüberschreitung bei Verbindung

Anpassen der Einstellungen des Verwaltungskonfigurationsblocks

Wenn Sie die Kommunikation Ihrer NGINX Plus-Instanz mit dem NGINX Instance Manager lieber feinabstimmen möchten, können Sie den neuen Verwaltungskonfigurationsblock und die zugehörigen Anweisungen verwenden. Auf diese Weise können Sie einen benutzerdefinierten Resolver definieren, eine IP-Adresse oder einen alternativen Hostnamen zur Identifizierung Ihres NGINX Instance Manager-Systems verwenden, TLS-Optionen angeben, mTLS zur erhöhten Sicherheit verwenden und andere benutzerdefinierte Parameter angeben.

Nachfolgend sehen Sie ein Beispiel für eine benutzerdefinierte Konfiguration:

mgmt {
usage_report endpoint=instance-manager.local interval=30m;
resolver 192.168.0.2; # Beispiel für interne DNS-IP

uuid_file /var/lib/nginx/nginx.id;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers DEFAULT;

ssl_certificate client.pem;
ssl_certificate_key client.key;

ssl_trusted_certificate trusted_ca_cert.crt;
ssl_verify on;
ssl_verify_depth 2;
}

Weitere Einzelheiten zu diesen Anweisungen finden Sie in der Produktdokumentation .

Weitere Informationen zum Herunterladen und Installieren von NGINX Instance Manager finden Sie im Installationshandbuch .

Notiz: Wenn Sie eine frühere Version von NGINX Plus verwenden, können Sie Ihre Instanzen trotzdem melden, indem Sie diese Anweisungen befolgen.

Verbesserungen der SNI-Konfiguration

Vor dieser Version ging NGINX Plus davon aus, dass alle Server in einer Upstream-Gruppe identisch waren. Dies bedeutet, dass sie in der Lage sein müssen, dieselben Anfragen zu beantworten, auf denselben SNI-Namen zu reagieren (wenn proxy_ssl_server_name verwendet wird) und SSL-Zertifikate mit demselben Namen zurückzugeben.

Es gibt jedoch Szenarien, in denen dieses Verhalten nicht ausreicht. Zum Beispiel, wenn mehrere virtuelle Server hinter einem Upstream-Server gemeinsam genutzt werden und durch einen anderen SNI und/oder Host-Header unterschieden werden müssen, um Anforderungen an bestimmte Ressourcen weiterzuleiten. Es ist auch möglich, dass nicht auf allen Servern in der Upstream-Gruppe dasselbe Zertifikat verwendet werden kann oder dass Einschränkungen hinsichtlich der Platzierung von Upstream-Servern in separaten Upstream-Gruppen bestehen.

NGINX Plus R31 führt die Unterstützung für SNI ein, das pro Upstream-Server konfiguriert werden kann. Die Variable $upstream_last_server_name bezieht sich auf den Namen des ausgewählten Upstream-Servers, der dann mit den Anweisungen proxy_ssl_server_name und proxy_ssl_name an den Proxy-Server übergeben werden kann.

So legen Sie proxy_ssl_server_name auf on fest, um die Weitergabe eines Servernamens durch SNI zu ermöglichen:
Proxy_SSL_Server_Name ein;

Und so übergeben Sie den ausgewählten Upstream-Servernamen mit proxy_ssl_name :
Proxy_SSL_Name $Upstream_letzter_Server_Name;

Periodische Aufgabenausführung mit NGINX JavaScript

NGINX JavaScript v0.8.1 hat eine neue Direktive js_periodic eingeführt, die sowohl im HTTP- als auch im Stream -Kontext verfügbar ist. Mit dieser Anweisung können Sie einen JavaScript-Inhaltshandler angeben, der in regelmäßigen Abständen ausgeführt wird. Dies ist in Fällen nützlich, in denen benutzerdefinierter Code in regelmäßigen Abständen ausgeführt werden muss und möglicherweise Zugriff auf NGINX-Variablen erfordert. Der Content-Handler erhält ein Session-Objekt als Argument und hat zudem Zugriff auf globale Objekte.

Standardmäßig wird der Inhaltshandler auf dem Arbeitsprozess 0 ausgeführt, er kann jedoch so konfiguriert werden, dass er auf bestimmten oder allen Arbeitsprozessen ausgeführt wird.

Diese Anweisung ist im Standortkontext verfügbar:

example.conf:

location @periodics {

# soll in 15-Minuten-Intervallen in den Worker-Prozessen 1 und 3 ausgeführt werden
js_periodic main.handler interval=900s worker_affinity=0101;

resolver 10.0.0.1;
js_fetch_trusted_certificate /path/to/certificate.pem;
}

example.js:

async function handler(s) {
let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
let body = await reply.text();

ngx.log(ngx.INFO, body);
}

Einzelheiten zu Syntax und Konfiguration finden Sie in den NGINX-JavaScript-Dokumenten .

Ein besseres NGINX-Startup-Erlebnis

In Szenarien, in denen eine NGINX-Konfiguration eine große Anzahl von „Standorten“ enthält, kann die Startzeit Ihres NGINX beträchtliche Zeit in Anspruch nehmen. In vielen Fällen ist dies möglicherweise nicht akzeptabel. Das Grundproblem liegt im Sortieralgorithmus, der zum Sortieren der Standortliste verwendet wird.

NGINX R31 führt eine Erweiterung ein, die den vorhandenen Sortieralgorithmus von Insertionsort , der eine Zeitkomplexität von O(n2) aufweist, durch Mergesort mit einer Zeitkomplexität von O(n*log n) ersetzt.

In einer Testkonfiguration mit 20.000 Standorten konnte beobachtet werden, dass sich die Gesamtstartzeit nach diesem Update von 8 Sekunden auf 0,9 Sekunden reduzierte.

QUIC+HTTP/3-Optimierungen und -Verbesserungen

NGINX Plus R31 führt mehrere Verbesserungen und Leistungsoptimierungen für die QUIC+HTTP/3-Implementierung ein, wie zum Beispiel:

• Erkennung der maximalen Pfadübertragungseinheit (MTU) bei Verwendung von QUIC+HTTP/3 – Die Pfad-MTU ist eine Maßeinheit in Bytes für den größten Frame oder das größte Datenpaket, das über ein Netzwerk übertragen werden kann. Vor dieser Änderung verwendete die QUIC-Implementierung eine Pfad-MTU von 1200 Bytes für alle Datagramme. NGINX Plus unterstützt jetzt die Ermittlung der MTU-Größe des Pfads, die dann für alle ausgehenden Datagramme verwendet wird.
• Kryptografischen Kontext während der gesamten QUIC-Sitzung wiederverwenden – Diese Optimierung bezieht sich auf das Verschlüsselungs- und Entschlüsselungsverhalten von QUIC-Paketen. Bisher wurde für jeden Verschlüsselungs- oder Entschlüsselungsvorgang ein separater kryptografischer Kontext erstellt. Jetzt wird während der gesamten QUIC-Sitzung derselbe Kontext verwendet, was zu einer besseren Leistung führt.

Zu den weiteren Leistungsoptimierungen gehören die Reduzierung potenzieller Verzögerungen beim Senden von Bestätigungspaketen, das Platzieren von Bestätigungsframes (ACK) an den Anfang der Warteschlange, um Frame-Neuübertragungen und Verzögerungen bei der Zustellung von ACK-Frames zu reduzieren, sowie Verbesserungen des Überlastungskontrollverhaltens im GSO-Modus (Generic Segmentation Offload).

Weitere Verbesserungen und Fehlerbehebungen in NGINX Plus R31

Zusätzliches Verwaltungsmodul

In NGINX Plus R31 können Sie mit ngx_mgmt_module Informationen zur NGINX-Nutzung an den NGINX Instance Manager melden. Diese Informationen umfassen den NGINX-Hostnamen, die NGINX-Version und eine eindeutige Instanzkennung.

Das Modul bietet mehrere Anweisungen zur Feinabstimmung der Kommunikation Ihrer NGINX-Instanz mit dem NGINX Instance Manager. Eine vollständige Liste der verfügbaren Anweisungen und Konfigurationsoptionen finden Sie in den NGINX-Dokumenten .

Fehlerbehebungen im MQTT-Modul

Die Unterstützung für Message Queuing Telemetry Transport (MQTT) wurde in NGINX Plus R29 eingeführt und diese Version enthält einige Fehlerbehebungen für im MQTT-Modul beobachtete Probleme.

Ein wichtiger Fix behebt das Problem, dass CONNECT-Nachrichten abgelehnt wurden, wenn kein Kennwort angegeben wurde. Bisher haben wir unbedingt erwartet, dass auf das Feld „Benutzername“ ein Passwort folgt. Es gibt jedoch Sonderfälle in der MQTT-Spezifikation – wie beispielsweise die anonyme Authentifizierung – bei denen die Angabe eines Passworts nicht zwingend erforderlich ist. Der Fix überprüft bedingt, ob das Kennwort erwartet wird oder nicht, indem er das Cflags- Feld des Pakets betrachtet. Wenn das Flag nicht gesetzt ist, bedeutet dies, dass das Passwort nicht obligatorisch ist.

Ein weiterer Bugfix stoppt das Parsen von MQTT CONNECT-Nachrichten, wenn die Nachrichtenlänge kleiner ist als die Anzahl der empfangenen Bytes.

HTTP/3 Server-Tokens- Unterstützung mit Variablen

NGINX Plus R31 fügt Unterstützung für fehlende Server-Token -Variablen für HTTP/3-Verbindungen hinzu. Das Zeichenfolgenfeld kann verwendet werden, um die Signatur auf Fehlerseiten und den Wert des Antwortheaderfelds „Server“ explizit festzulegen. Wenn das Zeichenfolgenfeld leer ist, wird die Ausgabe des Felds „Server“ deaktiviert.

Von NGINX Open Source übernommene Änderungen

NGINX Plus R31 basiert auf NGINX Open Source 1.25.3 und übernimmt funktionale Änderungen, Funktionen und Fehlerbehebungen seit der Veröffentlichung von NGINX Plus R30 (in NGINX 1.25.2 und 1.25.3).

Merkmale

• Pfad-MTU-Erkennung bei Verwendung von QUIC – Bisher wurde für alle Datagramme eine Standardgröße von 1200 MTU verwendet. Als Teil der QUIC+HTTP/3-Verbesserungen haben wir Unterstützung zum Ermitteln der Pfad-MTU-Größe hinzugefügt, die dann für alle ausgehenden Datagramme verwendet wird.
• Leistungsoptimierungen in QUIC – Die NGINX-Hauptversion 1.25.2 führte Optimierungen in der QUIC-Implementierung ein, um den kryptografischen Kontext für die gesamte QUIC-Sitzung wiederzuverwenden. Dadurch werden Verzögerungen beim Senden von ACK-Paketen reduziert und ACK-Frames an den Anfang der Warteschlange gestellt, um Frame-Neuübertragungen und Verzögerungen bei der Zustellung von ACK-Frames zu verringern.
• Unterstützung für die TLS_AES_128_CCM_SHA256 -Chiffre-Suite bei Verwendung von HTTP/3 – Diese Erweiterung fügt TLS_AES_128_CCM_SHA256 -Unterstützung zu QUIC hinzu. Dies ist derzeit die einzige Chiffre-Suite, die von der NGINX QUIC-Implementierung nicht unterstützt wird. Es ist in OpenSSL standardmäßig deaktiviert und kann mit dieser Anweisung aktiviert werden: ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• Geben Sie beim Laden von OpenSSL-Konfigurationen den nginx- App-Namen an . Wenn Sie die Schnittstelle OPENSSL_init_ssl() verwenden, prüft NGINX jetzt nicht mehr, ob OPENSSL_VERSION_NUMBER überprüft wird, sondern ob OPENSSL_INIT_LOAD_CONFIG definiert und wahr ist. Dadurch wird sichergestellt, dass die Schnittstelle nicht mit BoringSSL und LibreSSL verwendet wird, da diese keine zusätzlichen Initialisierungseinstellungen für die Bibliothek bereitstellen (insbesondere den Aufruf OPENSSL_INIT_set_config_appname() ).

Änderungen

• Änderung am Warteschlangensortieralgorithmus von NGINX – Wie oben beschrieben, verwendet NGINX jetzt Mergesort , das eine Zeitkomplexität von O(n*log n) aufweist. Dies sorgt für ein besseres NGINX-Starterlebnis , insbesondere wenn die Konfiguration eine sehr große Anzahl von „Standorten“ enthält.
• HTTP/2-Iterations-Stream-Handling-Limit – Diese Verbesserung gewährleistet eine frühzeitige Erkennung von Flood-Angriffen auf NGINX, indem eine Begrenzung der Anzahl neuer Streams festgelegt wird, die in einer Ereignisschleife eingeführt werden können. Dieses Limit ist doppelt so hoch und wird mit http2_max_concurrent_streams konfiguriert. Es wird auch dann angewendet, wenn der maximale Schwellenwert zulässiger gleichzeitiger Streams nie erreicht wird, um Fälle zu berücksichtigen, in denen Streams unmittelbar nach dem Senden der Anforderungen zurückgesetzt werden.

Fehlerbehebungen

• Behobene Pufferverwaltung mit automatischer HTTP/2-Erkennung – Als Teil der automatischen HTTP/2-Erkennung bei einfachen TCP-Verbindungen werden die Anfangsdaten zuerst in einen durch die Direktive „client_header_buffer_size“ angegebenen Puffer gelesen, der keine Statusreservierung hat. Dies führte zu einem Problem, bei dem der Puffer beim Speichern des Status überlesen werden konnte. Der aktuelle Fix ermöglicht das Lesen nur der verfügbaren Puffergröße anstelle der festen Puffergröße. Dieser Fehler trat erstmals in der NGINX-Hauptversion 1.25.1 (NGINX Plus R30) auf.
• Falscher Transportmodus im OpenSSL-Kompatibilitätsmodus – Vor dieser Version verursachte die OpenSSL-Kompatibilitätsschicht eine Verzögerung der Verbindung, wenn vom Client ein falscher Transportparameter gesendet wurde. Der Fix behebt dieses Verhalten mühelos, indem er den Benutzer zunächst über den falschen Parameter benachrichtigt und anschließend die Verbindung schließt.
• Behobener Umgang mit Statusheadern ohne Begründungsphrase – Ein Statusheader mit einer leeren „Begründungsphrase“ wie Status: 404 war gemäß der CGI-Spezifikation (Common Gateway Interface) gültig, aber beim Parsen ging das nachstehende Leerzeichen verloren. Dies führte zu einer HTTP/1.1 404- Statuszeile in der Antwort, die aufgrund eines fehlenden Leerzeichens am Ende gegen die HTTP-Spezifikation verstößt. Mit dieser Fehlerbehebung wird nur der Statuscode aus solchen kurzen Statusheaderzeilen verwendet, sodass NGINX die Statuszeile selbst mit dem Leerzeichen und der entsprechenden Begründungsphrase (falls verfügbar) generiert.
• Speicherverlust beim Neuladen der Konfiguration mit PCRE2 behoben – Dieses Problem trat auf, wenn NGINX für die Verwendung von PCRE2 in Version 1.21.5 oder höher konfiguriert war.

Die vollständige Liste der neuen Änderungen, Funktionen, Fehlerbehebungen und Problemumgehungen aus den letzten Versionen finden Sie in der Datei NGINX CHANGES .

Änderungen am NGINX JavaScript-Modul

NGINX Plus R31 enthält Änderungen aus der NGINX JavaScript (njs)-Modulversion 0.8.2. Hier ist die Liste der wesentlichen Änderungen in njs seit 0.8.0 (Teil der NGINX Plus R30-Version).

Merkmale

• Konsolenobjekt eingeführt. Folgende Methoden wurden eingeführt: error() , info() , log() , time() , timeEnd() und warn() .
• Einführung der Direktive js_periodic für http und Stream , die die Angabe eines JS-Handlers ermöglicht, der in regelmäßigen Abständen ausgeführt wird.
• Implementierte items() -Methode eines gemeinsam genutzten Wörterbuchs . Diese Methode gibt alle nicht abgelaufenen Schlüssel-Wert-Paare zurück.

Änderungen

• Das Modul „fs“ wurde erweitert. Methode existsSync() hinzugefügt.

Fehlerbehebungen

• Das „xml“-Modul wurde repariert. Beschädigte XML-Ausnahmebehandlung in der parse() -Methode behoben.
• RegExp.prototype.exec() mit globalem regulären Ausdruck (Regexp) und Unicode-Eingabe behoben.
• Feste size() - und keys()- Methoden eines gemeinsam genutzten Wörterbuchs .
• Fehlerhafte Ausnahme in r.internalRedirect() behoben, die in 0.8.0 eingeführt wurde.
• Falsche Reihenfolge der Schlüssel in Object.getOwnPropertyNames() behoben.
• Behobene HEAD-Antwortbehandlung mit großer Inhaltslänge in der Fetch-API.
• Feste Items() -Methode für ein gemeinsam genutztes Wörterbuch.

Eine umfassende Liste aller Funktionen, Änderungen und Fehlerbehebungen finden Sie im njs- Änderungsprotokoll .

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R31 zu aktualisieren. Zusätzlich zu den ganzen tollen neuen Funktionen erhalten Sie auch mehrere zusätzliche Fehlerbehebungen und Verbesserungen. Und wenn Sie auf dem neuesten Stand sind, kann NGINX Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren. Sie können es für Anwendungsfälle in den Bereichen Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs verwenden. Beginnen Sie noch heute mit einer kostenlosen 30-Tage-Testversion .