Ankündigung von NGINX Plus R31

Prabhat Dixit

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 31 (R31) bekannt zu geben. Basierend auf NGINX Open Source ist NGINX Plus die einzige All-in-One-Software, die Webserver, Load Balancer, Reverse Proxy, Content-Cache und API-Gateway in einer Lösung vereint.

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

• Native Berichterstattung zur NGINX-Nutzung – NGINX Plus unterstützt jetzt nativ die Berichterstattung zu NGINX-Bereitstellungen in Ihrer gesamten Organisation und ermöglicht so eine konsolidierte Ansicht Ihrer NGINX-Infrastruktur in NGINX Instance Manager. Diese Funktion verbessert die Governance von NGINX-Instanzen zur Einhaltung von Compliance-Anforderungen.
• Verbesserungen an der SNI-Konfiguration – Bisher wurde für den über die Server Name Indication (SNI) übermittelten Servernamen die Direktive proxy_ssl_name verwendet, und dieser Servername galt für alle Server in der Upstream-Gruppe. Mit NGINX Plus R31 kann diese SNI nun auf einen ausgewählten Upstream-Server festgelegt werden.
• Periodische Aufgabenausführung mit NGINX JavaScript – NGINX JavaScript führt die Direktive js_periodic ein, mit der Inhalte in regelmäßigen Abständen ausgeführt werden können. Dank dieser Erweiterung muss kein Cronjob mehr eingerichtet werden. Für eine optimale Leistung kann sie so konfiguriert werden, dass sie in allen oder nur in bestimmten Worker-Prozessen ausgeführt wird.
• Ein besseres NGINX-Starterlebnis – NGINX Plus R31 verbessert das allgemeine NGINX-Starterlebnis bei Konfigurationen mit einer großen Anzahl von „locations“.
• Optimierungen und Verbesserungen für QUIC+HTTP/3 – NGINX Plus R31 bietet zahlreiche Erweiterungen und Leistungsoptimierungen für die QUIC-Implementierung, darunter die Unterstützung für die Ermittlung der maximalen Übertragungseinheit (MTU) des Pfads, Verbesserungen bei der Überlastungssteuerung und die Möglichkeit, den kryptografischen Kontext während der gesamten QUIC-Sitzung wiederzuverwenden.

Abgerundet wird das Release durch neue Funktionen und Fehlerbehebungen aus NGINX Open Source sowie Aktualisierungen des NGINX-JavaScript-Moduls.

Wichtige Verhaltensänderungen

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

Veraltung des OpenTracing-Moduls

Das mit NGINX Plus R18 eingeführte OpenTracing-Modul gilt nun als veraltet. Es ist zur Entfernung ab der zukünftigen Version NGINX Plus R34 vorgesehen. Bis dahin wird das Paket mit allen Versionen von NGINX Plus bereitgestellt. Es wird dringend empfohlen, das mit NGINX Plus R29 eingeführte OpenTelemetry-Modul zu verwenden.

Warnmeldung bei ausbleibender Meldung der NGINX-Nutzung

Benutzer von NGINX Plus sind aus Compliance-Gründen verpflichtet, ihre NGINX-Nutzung an F5 zu melden. Seit der Veröffentlichung von NGINX Plus R31 ist die Funktion zum Melden Ihrer NGINX-Nutzung an den NGINX Instance Manager nativ integriert und standardmäßig aktiviert. Eine Warnmeldung wird protokolliert, wenn die NGINX-Instanz ihre Nutzungsinformationen aus irgendeinem Grund nicht an NGINX Instance Manager übermitteln kann.

Weitere Informationen zur Konfiguration dieser Funktion in Ihrer Umgebung finden Sie im Abschnitt „Native NGINX-Nutzungsberichterstattung“.

Änderungen bei der Plattformunterstützung

Neu unterstützte Betriebssysteme:

• FreeBSD 14
• Alpine 3.19

Ältere Betriebssysteme entfernt:

• Alpine 3.15, dessen Lebenszyklus (EOL) am 1. November 2023 endete

Ältere Betriebssysteme, die als veraltet eingestuft wurden und deren Unterstützung in NGINX Plus R32 eingestellt werden soll:

• FreeBSD 12, dessen Support am 31. Dezember 2023 endet

Neue Funktionen im Detail

Native NGINX-Nutzungsberichte

NGINX Plus R31 ermöglicht die direkte Kommunikation mit NGINX Instance Manager in Ihrem Netzwerk, um die Einhaltung der Lizenzbestimmungen zu automatisieren. Wenn Sie am F5 Flex Consumption Program teilnehmen, müssen Sie Ihre NGINX Plus-Instanzen nicht mehr manuell nachverfolgen.

Standardmäßig versucht NGINX Plus beim Start, NGINX Instance Manager über eine DNS-Abfrage des Hostnamens nginx-mgmt.local zu ermitteln. Der Hostname ist zwar konfigurierbar, der Einfachheit halber empfehlen wir jedoch, 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 anschließend eine TLS-Verbindung zu NGINX Instance Manager her und übermittelt alle dreißig Minuten seine Versionsnummer, seinen Hostnamen und seine eindeutige Kennung.

Als zusätzliche Sicherheitsebene empfehlen wir außerdem, diese Verbindung mithilfe des optionalen mgmt Konfigurationsblocks mit mTLS abzusichern. NGINX Instance Manager meldet dann in regelmäßigen Abständen die Gesamtnutzung der NGINX Plus-Instanzen an einen F5-Dienst.

In Ihrem Fehlerprotokoll wird eine Warnmeldung angezeigt, wenn bei NGINX Plus Probleme bei der Auflösung des Hostnamens nginx-mgmt.local oder bei der Kommunikation mit NGINX Instance Manager auftreten.

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

2023/12/21 21:02:01 [warn] 3050#3050: Nutzungsbericht: Host beim 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 NGINX Instance Manager hat:

2023/12/21 21:02:01 [warn] 3184#3184: Nutzungsbericht: Zeitüberschreitung bei der Verbindung

Anpassen der Einstellungen des Konfigurationsblocks mgmt Configuration Block Settings

Wenn Sie die Kommunikation Ihrer NGINX Plus-Instanz mit NGINX Instance Manager genauer abstimmen möchten, können Sie den neuen Konfigurationsblock mgmt und die zugehörigen Direktiven verwenden. Damit können Sie einen benutzerdefinierten Resolver definieren, Ihr NGINX Instance Manager-System anhand einer IP-Adresse oder eines alternativen Hostnamens identifizieren, TLS-Optionen festlegen, mTLS für erhöhte Sicherheit verwenden und weitere benutzerdefinierte Parameter angeben.

Im Folgenden finden Sie ein Beispiel für eine benutzerdefinierte Konfiguration:

mgmt {
    usage_report endpoint=instance-manager.local interval=30m;
    resolver 192.168.0.2; # Sample internal 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 Direktiven finden Sie in der Produktdokumentation.

Weitere Informationen zum Herunterladen und Installieren von NGINX Instance Manager finden Sie in der Installationsanleitung.

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

Verbesserungen an der SNI-Konfiguration

Vor dieser Version ging NGINX Plus davon aus, dass alle Server in einer Upstream-Gruppe identisch sind. Das bedeutet, dass sie dieselben Anfragen beantworten, auf denselben SNI-Namen reagieren (wenn proxy_ssl_server_name verwendet wird) und SSL-Zertifikate zurückgeben können mussten, die demselben Namen entsprechen.

Es gibt jedoch Szenarien, in denen dieses Verhalten nicht ausreicht. Dies ist beispielsweise der Fall, wenn sich mehrere virtuelle Server hinter einem Upstream-Server befinden und anhand unterschiedlicher SNI- und/oder Host-Header unterschieden werden müssen, um Anfragen an bestimmte Ressourcen weiterzuleiten. Es ist auch möglich, dass nicht auf allen Servern der Upstream-Gruppe dasselbe Zertifikat verwendet werden kann oder dass Einschränkungen verhindern, die Upstream-Server in separate Upstream-Gruppen aufzuteilen.

NGINX Plus R31 unterstützt nun die Konfiguration von SNI für jeden einzelnen Upstream-Server. Die Variable $upstream_last_server_name verweist auf den Namen des ausgewählten Upstream-Servers, der dann mithilfe der Direktiven proxy_ssl_server_name und proxy_ssl_name an den Proxy-Server übergeben werden kann.

So setzen Sie proxy_ssl_server_name auf on, damit ein Servername über SNI übermittelt werden kann:
proxy_ssl_server_name on;

Und so übergeben Sie den Namen des ausgewählten Upstream-Servers mithilfe von proxy_ssl_name:
proxy_ssl_name $upstream_last_server_name;

Periodische Aufgabenausführung mit NGINX JavaScript

Mit NGINX JavaScript v0.8.1 wurde die neue Direktive js_periodic eingeführt, die sowohl im http- als auch im stream-Kontext verfügbar ist. Mit dieser Direktive kann ein JavaScript-Content-Handler festgelegt werden, der in regelmäßigen Abständen ausgeführt wird. Dies ist nützlich, wenn benutzerdefinierter Code regelmäßig ausgeführt werden und möglicherweise auf NGINX-Variablen zugreifen muss. Der Content-Handler erhält ein Sitzungsobjekt als Argument und hat außerdem Zugriff auf globale Objekte.

Standardmäßig wird der Content-Handler im Worker-Prozess 0 ausgeführt. Er kann jedoch so konfiguriert werden, dass er in bestimmten oder allen Worker-Prozessen ausgeführt wird.

Diese Direktive ist im location-Kontext verfügbar:

example.conf:

location @periodics {

    # to be run at 15 minute intervals in worker processes 1 and 3
    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);
}

Details zur Syntax und Konfiguration finden Sie in der NGINX-JavaScript-Dokumentation.

Ein besseres Starterlebnis mit NGINX

Wenn eine NGINX-Konfiguration eine große Anzahl von „Locations“ enthält, kann der Start von NGINX sehr lange dauern. In vielen Fällen ist dies möglicherweise nicht akzeptabel. Die eigentliche Ursache liegt im Sortieralgorithmus, mit dem die Liste der Locations sortiert wird.

NGINX R31 führt eine Verbesserung ein, bei der der bisherige Sortieralgorithmus Insertion Sort mit einer Zeitkomplexität von O(n2) durch Merge Sort mit einer Zeitkomplexität von O(n*log n) ersetzt wird.

Bei einer Testkonfiguration mit 20.000 Locations wurde festgestellt, dass sich die gesamte Startzeit nach diesem Update von 8 Sekunden auf 0,9 Sekunden verkürzte.

QUIC+HTTP/3-Optimierungen und -Verbesserungen

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

• Ermittlung der maximalen Übertragungseinheit (MTU) des Pfads bei Verwendung von QUIC+HTTP/3 – Die Pfad-MTU gibt in Byte die maximale Größe eines Frames oder Datenpakets an, das über ein Netzwerk übertragen werden kann. Vor dieser Änderung verwendete die QUIC-Implementierung für alle Datagramme eine Pfad-MTU von 1200 Byte. NGINX Plus unterstützt nun die Ermittlung der Pfad-MTU, die anschließend für alle ausgehenden Datagramme verwendet wird.
• Wiederverwendung des kryptografischen Kontexts während der gesamten QUIC-Sitzung – Diese Optimierung betrifft die Ver- und Entschlüsselung von QUIC-Paketen. Zuvor wurde für jeden Ver- oder Entschlüsselungsvorgang ein separater kryptografischer Kontext erstellt. Nun wird während der gesamten QUIC-Sitzung derselbe Kontext verwendet, was zu einer besseren Leistung führt.

Zu den weiteren Leistungsoptimierungen gehören die Verringerung potenzieller Verzögerungen beim Senden von Bestätigungspaketen, das Vorziehen von Bestätigungs-Frames (ACK) in der Warteschlange, um die erneute Übertragung von Frames und Verzögerungen bei der Zustellung von ACK-Frames zu reduzieren, sowie Verbesserungen am Verhalten der Überlastungssteuerung im Generic-Segmentation-Offload-Modus (GSO).

Weitere Verbesserungen und Fehlerbehebungen in NGINX Plus R31

Zusätzliches mgmt-Modul

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

Das Modul stellt mehrere Direktiven bereit, mit denen Sie die Kommunikation Ihrer NGINX-Instanz mit NGINX Instance Manager präzise abstimmen können. Eine vollständige Liste der verfügbaren Direktiven und Konfigurationsoptionen finden Sie in der NGINX-Dokumentation.

Fehlerbehebungen im MQTT-Modul

Die Unterstützung für Message Queuing Telemetry Transport (MQTT) wurde mit NGINX Plus R29 eingeführt und dieses Release enthält einige Fehlerbehebungen für Probleme, die im MQTT-Modul festgestellt wurden.

Eine wichtige Fehlerbehebung betrifft ein Problem, bei dem CONNECT-Nachrichten abgelehnt wurden, wenn kein Passwort angegeben war. Zuvor gingen wir grundsätzlich davon aus, dass auf das Feld für den Benutzernamen ein Passwort folgt. In der MQTT-Spezifikation gibt es jedoch Sonderfälle – etwa die anonyme Authentifizierung –, in denen die Angabe eines Passworts nicht zwingend erforderlich ist. Die Fehlerbehebung prüft anhand des Felds cflags im Paket, ob ein Passwort erwartet wird. Ist das Flag nicht gesetzt, bedeutet dies, dass kein Passwort erforderlich ist.

Eine weitere Fehlerbehebung verhindert das Parsen von MQTT-CONNECT-Nachrichten, wenn die Nachrichtenlänge kleiner als die Anzahl der empfangenen Bytes ist.

HTTP/3-server_tokens-Unterstützung mit Variablen

NGINX Plus R31 unterstützt nun die bislang fehlenden server_tokens-Variablen für HTTP/3-Verbindungen. Mit dem Feld string können die Signatur auf Fehlerseiten und der Wert des Antwort-Headerfelds „Server“ explizit festgelegt werden. Ist das Feld „string“ leer, wird das Feld „Server“ nicht ausgegeben.

Von NGINX Open Source übernommene Änderungen

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

Funktionen

• Pfad-MTU-Erkennung bei Verwendung von QUIC – Bisher wurde für alle Datagramme eine Standard-MTU-Größe von 1200 verwendet. Im Rahmen der Verbesserungen an QUIC+HTTP/3 haben wir Unterstützung für die Ermittlung der Pfad-MTU-Größe hinzugefügt, die anschließend für alle ausgehenden Datagramme verwendet wird.
• Leistungsoptimierungen in QUIC – Mit NGINX Mainline Version 1.25.2 wurden Optimierungen an der QUIC-Implementierung eingeführt, durch die der kryptografische Kontext während der gesamten QUIC-Sitzung wiederverwendet wird. Dies reduziert Verzögerungen beim Senden von ACK-Paketen und stellt ACK-Frames an den Anfang der Warteschlange, um die erneute Übertragung von Frames und Verzögerungen bei der Zustellung von ACK-Frames zu verringern.
• Unterstützung für die Cipher Suite TLS_AES_128_CCM_SHA256 bei Verwendung von HTTP/3 – Diese Erweiterung ergänzt QUIC um die Unterstützung für TLS_AES_128_CCM_SHA256, die derzeit einzige Cipher Suite, die von der QUIC-Implementierung von NGINX nicht unterstützt wird. Sie ist in OpenSSL standardmäßig deaktiviert und kann mit der folgenden Direktive aktiviert werden: ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• Bereitstellung des nginx-appName beim Laden von OpenSSL-Konfigurationen – Bei Verwendung der OPENSSL_init_ssl()-Schnittstelle prüft NGINX nun, ob OPENSSL_VERSION_NUMBER definiert ist, 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 Einstellungen für die Bibliotheksinitialisierung bereitstellen (insbesondere den Aufruf OPENSSL_INIT_set_config_appname()).

Änderungen

• Änderung am Sortieralgorithmus der NGINX-Warteschlange – Wie oben beschrieben, verwendet NGINX jetzt Mergesort, der eine Zeitkomplexität von O(n*log n) aufweist. Dies sorgt für einen besseren Startvorgang von NGINX, insbesondere wenn die Konfiguration sehr viele „locations“ enthält.
• Limit für die Verarbeitung von HTTP/2-Streams pro Iteration – Diese Verbesserung ermöglicht die frühzeitige Erkennung von Flood-Angriffen auf NGINX, indem die Anzahl neuer Streams begrenzt wird, die innerhalb eines Ereigniszyklus initiiert werden können. Dieses Limit entspricht dem Doppelten des Werts, der mit http2_max_concurrent_streams konfiguriert wird. Es gilt auch dann, wenn die maximal zulässige Anzahl gleichzeitiger Streams nie erreicht wird, um Fälle zu berücksichtigen, in denen Streams unmittelbar nach dem Senden der Anfragen zurückgesetzt werden.

Fehlerbehebungen

• Korrigierte Pufferverwaltung bei automatischer HTTP/2-Erkennung – Im Rahmen der automatischen HTTP/2-Erkennung bei unverschlüsselten TCP-Verbindungen werden die anfänglichen Daten zunächst in einen Puffer eingelesen, der durch die Direktive client_header_buffer_size festgelegt wird und keine Zustandsreservierung aufweist. Dies führte dazu, dass beim Speichern des Zustands über das Ende des Puffers hinaus gelesen werden konnte. Durch die aktuelle Korrektur wird nur noch die verfügbare Puffergröße anstelle der festgelegten Puffergröße gelesen. Dieser Fehler trat erstmals in der NGINX-Mainline-Version 1.25.1 (NGINX Plus R30) auf.
• Falscher Transportmodus im OpenSSL-Kompatibilitätsmodus – Vor dieser Version führte die OpenSSL-Kompatibilitätsschicht zu einer Verzögerung der Verbindung, wenn der Client einen falschen Transportparameter sendete. Durch die Fehlerbehebung wird dieses Verhalten nun ordnungsgemäß behandelt, indem zunächst der Benutzer über den falschen Parameter informiert und anschließend die Verbindung geschlossen wird.
• Korrigierte Verarbeitung von Status-Headern ohne Begründungstext – Ein Status-Header mit einem leeren „Begründungstext“ wie Status: 404 war gemäß der Common-Gateway-Interface-Spezifikation (CGI) gültig, verlor jedoch beim Parsen das nachgestellte Leerzeichen. Dies führte in der Antwort zu einer HTTP/1.1 404-Statuszeile, die aufgrund des fehlenden nachgestellten Leerzeichens gegen die HTTP-Spezifikation verstößt. Mit dieser Fehlerbehebung wird aus solchen kurzen Status-Headerzeilen nur noch der Statuscode verwendet, sodass NGINX die Statuszeile selbst mit dem Leerzeichen und, sofern verfügbar, dem entsprechenden Begründungstext erzeugt.
• Speicherleck 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.

Eine vollständige Liste der neuen Änderungen, Funktionen, Fehlerbehebungen und Problemumgehungen aus den jüngsten Versionen finden Sie in der NGINX-Datei „CHANGES“.

Änderungen am NGINX-JavaScript-Modul

NGINX Plus R31 enthält Änderungen aus Version 0.8.2 des NGINX-JavaScript-Moduls (njs). Im Folgenden finden Sie eine Liste der wichtigsten Änderungen in njs seit Version 0.8.0, die Bestandteil der Veröffentlichung von NGINX Plus R30 war.

Funktionen

• Das console-Objekt wurde eingeführt. Folgende Methoden wurden eingeführt: error(), info(), log(), time(), timeEnd(), und warn().
• Die Direktive js_periodic für http und stream wurde eingeführt. Damit lässt sich ein JS-Handler festlegen, der in regelmäßigen Abständen ausgeführt wird.
• Die Methode items() eines gemeinsam genutzten Wörterbuchs wurde implementiert. Diese Methode gibt alle nicht abgelaufenen Schlüssel-Wert-Paare zurück.

Änderungen

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

Fehlerbehebungen

• Das „xml“-Modul wurde korrigiert. Die fehlerhafte Behandlung von XML-Ausnahmen in der Methode „parse()“ wurde behoben.
• Problem mit RegExp.prototype.exec() bei globalen regulären Ausdrücken (RegExp) und Unicode-Eingaben behoben.
• Die Methoden size(), und keys() eines gemeinsam genutzten Dictionarys wurden korrigiert.
• Fehlerhafte Ausnahme in r.internalRedirect() behoben, die in Version 0.8.0 eingeführt wurde.
• Fehlerhafte Reihenfolge der Schlüssel in Object.getOwnPropertyNames() behoben.
• Die Verarbeitung von HEAD-Antworten mit einem großen Content-Length-Wert in der Fetch-API wurde korrigiert.
• Die Methode items() für ein gemeinsam genutztes Dictionary wurde korrigiert.

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

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R31 durchzuführen. Neben all den großartigen neuen Funktionen erhalten Sie damit auch mehrere zusätzliche Fehlerbehebungen und Verbesserungen. Zudem kann NGINX Sie bei einer Supportanfrage besser unterstützen, wenn Ihre Version auf dem neuesten Stand ist.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es sich einmal anzusehen. Sie können es für Sicherheits-, Lastverteilungs- und API-Gateway-Anwendungsfälle oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs einsetzen. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion.

Über den Autor

Prabhat Dixit

Weitere Blogbeiträge von Prabhat Dixit