Managed Redis sicher über TLS mit stunnel und redis-cli verbinden

Voraussetzungen für eine sichere Redis-TLS-Verbindung

Für diese Anleitung benötigen Sie:

• Zugriff auf einen Ubuntu-24.04-Server mit einem Benutzerkonto ohne Root-Rechte, das über sudo-Berechtigungen verfügt. Zusätzlich sollte eine Firewall mit ufw eingerichtet sein. Falls das System noch nicht vorbereitet wurde, führen Sie zunächst eine grundlegende Ubuntu-Serverkonfiguration durch.
• Eine verwaltete Redis-Datenbankinstanz, die TLS voraussetzt. Die hier beschriebenen Verbindungsverfahren eignen sich für Cloud- und Hosting-Anbieter, die einen TLS-fähigen Redis-Endpunkt bereitstellen.

Bevor Sie Befehle ausführen, sollten Sie den Redis-Hostnamen, den TLS-Port und das Datenbankpasswort über die Verwaltungsoberfläche oder API Ihres Datenbankanbieters bereithalten. Wenn diese Werte bereits vorliegen, müssen die Zugangsdaten während der Einrichtung nicht erst gesucht werden.

Sichere Verbindungsmethode für Redis auswählen

Verwaltete Redis-Dienste stellen häufig einen eigenen TLS-Endpunkt zur Verfügung und können unverschlüsselte Verbindungen vollständig ablehnen. Von einem Ubuntu-System aus stehen mehrere Möglichkeiten zur Verfügung, um einen solchen Endpunkt sicher zu erreichen.

Die native TLS-Unterstützung ist normalerweise die bevorzugte Variante. Sie benötigt weniger Komponenten, erfordert keinen zusätzlichen Dienst und ermöglicht redis-cli, das Serverzertifikat direkt zu prüfen. Dieses Vorgehen entspricht den Empfehlungen der Redis-TLS-Dokumentation und der redis-cli-Dokumentation.

stunnel bleibt dann sinnvoll, wenn die installierte redis-cli-Version ohne TLS-Unterstützung kompiliert wurde. Das lässt sich daran erkennen, dass redis-cli --help keine Option --tls anzeigt. Außerdem eignet sich stunnel für lokale Anwendungen, die lediglich einen gewöhnlichen unverschlüsselten TCP-Socket erwarten. Die folgenden Abschnitte beschreiben sowohl native TLS-Verbindungen als auch den Einsatz von stunnel.

Eine SSH-Portweiterleitung stellt selbst keine Redis-spezifische TLS-Verbindung her. Stattdessen wird die Kommunikation zwischen dem lokalen Rechner und dem SSH-Server verschlüsselt. Diese Variante kann sinnvoll sein, wenn das Redis-Netzwerk ausschließlich über einen Jump Host erreichbar ist. Eine detaillierte Konfiguration von SSH-Tunneln gehört jedoch nicht zu den nachfolgenden Einrichtungsschritten.

CA-Zertifikatsprüfung bei Redis über TLS verstehen

TLS verschlüsselt nicht nur den Datenverkehr. Das Protokoll ermöglicht dem Client außerdem zu überprüfen, ob tatsächlich der vorgesehene Server erreicht wurde und nicht ein unbefugtes System die Verbindung abfängt.

Wenn redis-cli mit --tls eine Verbindung aufbaut, führt OpenSSL oder die TLS-Bibliothek des Betriebssystems einen Handshake durch. Dabei präsentiert der Server ein X.509-Zertifikat, das der Client anhand mehrerer Kriterien überprüft:

1. Das Zertifikat muss auf eine vertrauenswürdige Stammzertifizierungsstelle, also eine Certificate Authority (CA), zurückgeführt werden können.
2. Das Zertifikat darf nicht abgelaufen sein. Bei entsprechender Konfiguration kann zusätzlich überprüft werden, ob es widerrufen wurde.
3. Die im Zertifikat hinterlegte Identität muss zum Hostnamen passen, über den die Verbindung hergestellt wird.

Welche Zertifizierungsstellen als vertrauenswürdig gelten, lässt sich unter anderem mit folgenden Optionen festlegen:

• --cacert: Gibt eine PEM-Datei an, die ein oder mehrere vertrauenswürdige CA-Zertifikate beziehungsweise ein vom Anbieter bereitgestelltes CA-Bundle enthält.
• --cacertdir: Verweist auf ein Verzeichnis mit gehashten CA-Zertifikaten, ähnlich dem Aufbau des systemweiten Zertifikatsspeichers.

Verwendet der verwaltete Redis-Dienst ein Zertifikat einer öffentlichen CA, der das Betriebssystem bereits vertraut, beispielsweise Let’s Encrypt, ist eine eigene --cacert-Datei möglicherweise nicht notwendig. Auf einem aktuellen Ubuntu-System kann deshalb allein die Option --tls ausreichen, sofern der Anbieter auf eine öffentlich vertrauenswürdige Zertifizierungsstelle setzt.

Schlägt die Zertifikatsprüfung fehl, meldet redis-cli einen entsprechenden Zertifikatsfehler und baut keine Verbindung auf. Redis stellt für Diagnosezwecke außerdem die Option --insecure bereit. Diese deaktiviert die Zertifikatsvalidierung. In produktiven Umgebungen sollte sie nicht verwendet werden, da dadurch Man-in-the-Middle-Angriffe möglich werden. Sie ist ausschließlich für kontrollierte Tests und Fehlersuche vorgesehen, wie auch in der Diskussion zur Implementierung der Redis-Kommandozeilenwerkzeuge beschrieben.

Einige verwaltete Redis-Umgebungen verlangen gegenseitige TLS-Authentifizierung, also Mutual TLS oder mTLS. In diesem Fall muss auch der Client ein Zertifikat vorlegen. Dafür werden --cert und --key gemeinsam mit --cacert verwendet, entsprechend den manuellen TLS-Beispielen in der Redis-Dokumentation.

Wird statt nativer TLS-Unterstützung stunnel eingesetzt, übernimmt stunnel die Validierung des Zertifikats des entfernten Servers. In der Datei stunnel.conf lässt sich die Prüfung der Zertifikatskette mit verifyChain = yes und CApath = /etc/ssl/certs aktivieren. Dieses Vorgehen entspricht den offiziellen Unix-Konfigurationsbeispielen von stunnel.

Schritt 1: stunnel und redis-cli unter Ubuntu 24.04 installieren

Eine vollständige Redis-Serverinstallation enthält normalerweise auch redis-cli. Unter Ubuntu 24.04 können jedoch ausschließlich die Redis-Client-Werkzeuge zusammen mit stunnel aus den Standard-Paketquellen installiert werden. Dadurch muss kein lokaler Redis-Server eingerichtet werden, wenn das System lediglich zur Administration einer entfernten Datenbank dient.

Aktualisieren Sie zunächst den lokalen APT-Paketindex, damit das System auf aktuelle Paketinformationen zugreifen kann:

sudo apt update

Installieren Sie anschließend redis-tools, das redis-cli enthält, zusammen mit stunnel4:

sudo apt install redis-tools stunnel4

Bestätigen Sie die Installation mit ENTER, sobald APT danach fragt.

Prüfen Sie nach der Installation, welche Versionen installiert wurden:

redis-cli –version

stunnel4 -version

Ubuntu 24.04 stellt über redis-tools eine Redis-Version aus der 7.x-Reihe bereit, die native TLS-Unterstützung enthält. Entsprechend sollte für redis-cli eine 7.x-Version und für stunnel eine 5.x-Version angezeigt werden.

Bevor Sie sich für eine Verbindungsmethode entscheiden, prüfen Sie, ob das installierte redis-cli mit TLS-Unterstützung erstellt wurde:

redis-cli –help 2>&1 | grep -E ‚–tls|–cacert‘

Werden --tls und --cacert ausgegeben, können Sie das native TLS-Verfahren aus Schritt 2 nutzen. Fehlen diese Optionen, verwenden Sie stattdessen den stunnel-Ablauf aus den Schritten 3 und 4.

Überprüfen Sie abschließend, ob der systemd-Dienst von stunnel vorhanden ist:

sudo systemctl status stunnel4

Direkt nach der Installation kann der Dienst den Status active (exited) zusammen mit einer Meldung wie TLS tunnels disabled, see /etc/default/stunnel4 anzeigen. Das ist normal: Die Software ist installiert, aber es wurde noch kein Tunnel aktiviert oder eingerichtet.

Schritt 2: Managed Redis direkt mit redis-cli über TLS verbinden

Mit dieser Variante verbindet sich redis-cli direkt mit dem TLS-Endpunkt des verwalteten Redis-Dienstes. Ersetzen Sie die Platzhalter in den folgenden Befehlen durch Hostnamen, Port und Passwort Ihres Redis-Anbieters.

Verbindung über den Zertifikatsspeicher des Systems herstellen

Diese Methode eignet sich, wenn der Redis-Server ein Zertifikat verwendet, das von einer öffentlichen CA ausgestellt wurde, der Ubuntu bereits vertraut.

Starten Sie redis-cli mit --tls sowie dem Hostnamen und TLS-Port Ihrer Redis-Instanz:

redis-cli -h managed_redis_hostname -p managed_redis_tls_port –tls

Ist eine Authentifizierung erforderlich, speichern Sie das Passwort zunächst in der Umgebungsvariable REDISCLI_AUTH. Dadurch erscheint das Kennwort nicht direkt in der Shell-Historie und ist insbesondere auf Mehrbenutzersystemen besser geschützt:

export REDISCLI_AUTH=your_redis_password

redis-cli -h managed_redis_hostname -p managed_redis_tls_port –tls

Alternativ lässt sich das Passwort mit -a direkt übergeben. Diese Variante ist weniger empfehlenswert, wenn andere Benutzer Kommandozeilenargumente oder laufende Prozesse einsehen können:

redis-cli -h managed_redis_hostname -p managed_redis_tls_port –tls -a your_redis_password

Hinweis: Verwenden Sie die Verbindungsdaten, die Ihr verwalteter Redis-Dienst bereitstellt. Diese enthalten üblicherweise den korrekten Hostnamen, TLS-Port, die TLS-Einstellungen und die benötigten Authentifizierungsinformationen.

Um die Verbindung zu testen, ohne eine interaktive Redis-Sitzung zu öffnen, senden Sie einen einzelnen PING-Befehl:

redis-cli -h managed_redis_hostname -p managed_redis_tls_port –tls ping

Bei erfolgreicher Verbindung erscheint:

PONG

Wird PONG zurückgegeben, war der TLS-Handshake erfolgreich und der Redis-Server hat die Verbindung akzeptiert. Sie können nun interaktive Befehle verwenden. Die später beschriebene stunnel-Konfiguration wird nur benötigt, wenn zusätzlich ein lokaler unverschlüsselter Endpunkt erforderlich ist.

Verbindung mit einer CA-Zertifikatsdatei des Anbieters herstellen

Einige verwaltete Dienste setzen Zertifikate ein, die von einer privaten CA signiert wurden. Vertraut Ubuntu dieser CA nicht bereits, laden Sie das vom Anbieter bereitgestellte CA-Bundle, beispielsweise eine Datei namens ca.pem, herunter und geben Sie sie ausdrücklich an:

redis-cli -h managed_redis_hostname -p managed_redis_tls_port

–tls –cacert /path/to/ca.pem

Beschränken Sie die Dateiberechtigungen so, dass nur Ihr Benutzerkonto auf die PEM-Datei zugreifen kann:

chmod 600 /path/to/ca.pem

Redis mit Mutual TLS verbinden

Verlangt der entfernte Server ein Client-Zertifikat, übergeben Sie zusätzlich zum CA-Zertifikat auch das öffentliche Zertifikat und den privaten Schlüssel des Clients:

redis-cli -h managed_redis_hostname -p managed_redis_tls_port

–tls

–cacert /path/to/ca.pem

–cert /path/to/client.crt

–key /path/to/client.key

Verbindung über eine Redis-TLS-URI aufbauen

redis-cli unterstützt auch Verbindungs-URIs. Für TLS-Verbindungen wird das in der Redis-CLI-Dokumentation beschriebene Schema rediss:// verwendet:

redis-cli -u rediss://default:your_redis_password@managed_redis_hostname:managed_redis_tls_port

Funktioniert native TLS-Unterstützung in Ihrer Umgebung, kann redis-cli für die tägliche Administration ohne stunnel eingesetzt werden. Die folgenden Schritte richten stunnel nur für Szenarien ein, in denen zusätzlich ein lokaler unverschlüsselter TCP-Port benötigt wird.

Schritt 3: stunnel für Managed Redis über TLS konfigurieren

Automatischen Start von stunnel aktivieren

Öffnen Sie zunächst die Standardkonfigurationsdatei mit einem Editor:

sudo nano /etc/default/stunnel4

Setzen Sie ENABLED auf 1, damit stunnel beim Systemstart und bei einem manuellen Neustart des Dienstes aktiviert wird.

/etc/default/stunnel4

# Change to one to enable stunnel automatic startup
ENABLED=1

Speichern Sie die Datei und schließen Sie den Editor.

stunnel-Tunnel für Redis konfigurieren

Erstellen oder öffnen Sie nun die Hauptkonfiguration von stunnel:

sudo nano /etc/stunnel/stunnel.conf

Fügen Sie die folgende Konfiguration ein und ersetzen Sie die Platzhalter durch die Werte Ihrer Redis-Umgebung:

/etc/stunnel/stunnel.conf

fips = no

setuid = nobody

setgid = nogroup

pid = /tmp/stunnel-redis.pid

debug = 5

delay = yes
[redis-cli]

client = yes

accept = 127.0.0.1:8000

connect = managed_redis_hostname_or_ip:managed_redis_tls_port

verifyChain = yes

CApath = /etc/ssl/certs

Die globalen Einstellungen gelten für alle Dienste innerhalb dieser Datei:

• fips: Ist dieser Wert auf yes gesetzt, erzwingt stunnel den FIPS-140-3-Modus. Mit no bleibt die normale Cipher-Konfiguration ohne zusätzliche FIPS-Vorgaben aktiv.
• setuid / setgid: Nach dem Start gibt stunnel erhöhte Berechtigungen ab und läuft als nobody beziehungsweise nogroup. Dieses Vorgehen entspricht dem empfohlenen Sicherheitsmodell von stunnel.
• pid: Speichert die Prozess-ID unter /tmp/stunnel-redis.pid. Dieser Speicherort bleibt auch nach dem Wechsel auf ein weniger privilegiertes Benutzerkonto beschreibbar und vermeidet Probleme, die beispielsweise bei /var/run/stunnel4/ auftreten können, wenn der Prozess als nobody ausgeführt wird.
• debug: Legt die Protokollierungsstufe zwischen 0 für sehr geringe Ausgaben und 7 für besonders ausführliche Meldungen fest. Stufe 5 reicht in den meisten Fällen aus und kann zur Analyse von TLS-Handshake-Problemen vorübergehend erhöht werden.
• delay: Verschiebt die DNS-Auflösung des mit connect definierten Ziels und verhindert, dass eine einmal aufgelöste IP-Adresse dauerhaft zwischengespeichert wird. Das hilft insbesondere dann, wenn sich die Adresse eines verwalteten Endpunkts während Wartungsarbeiten oder eines Failovers ändert.

Die Einstellungen unter [redis-cli] definieren den eigentlichen Redis-Tunnel:

• client = yes: Konfiguriert stunnel als TLS-Client für die Verbindung zum entfernten Server.
• accept: Legt die lokale Adresse und den Port fest, auf dem stunnel Verbindungen entgegennimmt. Mit 127.0.0.1:8000 können nur Prozesse auf demselben Server den Tunnel verwenden, was sich für administrative Verbindungen eignet.
• connect: Definiert den Hostnamen und den TLS-Port des entfernten verwalteten Redis-Servers.
• verifyChain / CApath: Validiert das entfernte Serverzertifikat anhand der vertrauenswürdigen CA-Zertifikate unter /etc/ssl/certs. Dieses Muster entspricht den offiziellen Client-Beispielen von stunnel.

Hinweis: Für connect muss der TLS-fähige Redis-Port verwendet werden, den der verwaltete Dienst bereitstellt. Wird stunnel stattdessen auf einen unverschlüsselten Port geleitet, kann die Verbindung sofort abbrechen oder eine Meldung wie Error: Server closed the connection erscheinen.

Speichern Sie die Konfiguration und starten Sie stunnel neu, damit die Änderungen geladen werden:

sudo systemctl restart stunnel4

Prüfen Sie anschließend, ob der Tunnel auf dem lokalen Port 8000 lauscht:

sudo ss -tlnp | grep 8000

Die Ausgabe sollte ungefähr so aussehen:

LISTEN 0 128 127.0.0.1:8000 0.0.0.0:* users:((„stunnel4“,pid=12345,fd=7))

Zusätzlich können Sie prüfen, ob stunnel nach dem Start seine erhöhten Rechte erfolgreich abgegeben hat:

ps aux | grep ‚[s]tunnel‘

Der Prozess stunnel4 sollte dem Benutzer nobody gehören.

Falls der Dienst nicht startet, überprüfen Sie die aktuellen Protokolle auf Syntaxfehler oder Probleme während des TLS-Handshakes:

sudo journalctl -u stunnel4 -n 50 –no-pager

Schritt 4: Redis über den stunnel-Tunnel verbinden

Sobald stunnel auf 127.0.0.1:8000 lauscht, verbindet sich redis-cli unverschlüsselt per TCP mit diesem lokalen Weiterleitungsport. stunnel verschlüsselt den Datenverkehr anschließend und sendet ihn an den entfernten Redis-TLS-Endpunkt. Dadurch entsteht eine zweistufige Verbindung: Auf dem lokalen Loopback-Interface bleibt der Datenverkehr unverschlüsselt, während die Kommunikation über das Netzwerk durch TLS geschützt wird.

Stellen Sie die Verbindung zum lokalen Listener her:

redis-cli -h 127.0.0.1 -p 8000

Alternativ können Sie auch den Hostnamen localhost verwenden:

redis-cli -h localhost -p 8000

Übergeben Sie bei dieser lokalen Verbindung nicht die Option --tls. Die TLS-Verarbeitung erfolgt bereits innerhalb von stunnel. Würde --tls zusätzlich verwendet, würde redis-cli versuchen, mit dem lokalen unverschlüsselten Listener erneut einen TLS-Handshake durchzuführen.

Falls Redis eine Authentifizierung verlangt, exportieren Sie das Passwort vor dem Verbindungsaufbau:

export REDISCLI_AUTH=your_redis_password

redis-cli -h 127.0.0.1 -p 8000

Die Eingabeaufforderung sollte den lokalen Verbindungsendpunkt widerspiegeln:

1.

Nachdem die Verbindung hergestellt wurde, testen Sie den Tunnel mit PING:

127.0.0.1:8000> ping

Output:

PONG

Die Antwort PONG bestätigt, dass stunnel den Redis-Befehl erfolgreich weitergeleitet und eine Antwort vom entfernten Server erhalten hat. Kann stunnel den Zielserver nicht erreichen oder schlägt die TLS-Aushandlung fehl, kann redis-cli beispielsweise folgende Meldung ausgeben:

Could not connect to Redis at 127.0.0.1:8000: Connection refused

Nach einem kurzzeitig erfolgreichen Verbindungsaufbau kann auch folgende Meldung erscheinen:

Error: Server closed the connection

Im Abschnitt zur Fehlerbehebung werden diese Probleme systematisch untersucht.

Beenden Sie den interaktiven Modus nach Abschluss der Arbeiten mit:

127.0.0.1:8000> exit

Wurde die stunnel-Konfiguration später verändert, laden Sie den Dienst neu, damit die aktualisierten Einstellungen übernommen werden:

sudo systemctl reload stunnel4

Der Tunnel kann außerdem bei Bedarf manuell gestoppt und wieder gestartet werden:

sudo systemctl stop stunnel4

sudo systemctl start stunnel4

Häufige Redis-TLS- und stunnel-Fehler beheben

Auch nach einer vollständigen Einrichtung können Verbindungs- oder Authentifizierungsfehler auftreten. Häufige Ursachen sind nicht übereinstimmende Einstellungen, fehlende Dateiberechtigungen, falsche Hostinformationen oder ungültige Verbindungsparameter. Die folgenden Abschnitte behandeln typische Fehlermeldungen, mögliche Ursachen und geeignete Lösungsschritte.

Fehler: Error: Server closed the connection

Diese Meldung kann auftreten, wenn sich redis-cli zwar erfolgreich mit dem lokalen stunnel-Port verbindet, stunnel selbst jedoch keine stabile TLS-Verbindung zum entfernten Redis-Server aufbauen kann. Die Ausgabe sieht typischerweise so aus:

Error: Server closed the connection

Eine häufige Ursache ist ein falscher Hostname oder Port in /etc/stunnel/stunnel.conf. Öffnen Sie die Datei und prüfen Sie, ob der Wert von connect exakt dem Redis-Hostnamen und TLS-Port entspricht, die Ihr Hosting- oder Datenbankanbieter vorgibt:

connect = your_redis_host:your_redis_port

Kontrollieren Sie außerdem, ob der unter accept konfigurierte Port mit dem Port übereinstimmt, den Sie an redis-cli übergeben. Lauscht der lokale Tunnel beispielsweise auf Port 8000, verwenden Sie:

redis-cli -h 127.0.0.1 -p 8000

Wurde der verwaltete Redis-Dienst vor Kurzem neu gestartet, skaliert, migriert oder anderweitig verändert, können bestehende Verbindungen ebenfalls zurückgesetzt werden. In vielen Fällen reicht es aus, die Verbindung erneut aufzubauen und sich wieder zu authentifizieren.

Connection refused beim Start von redis-cli

Wenn redis-cli eine Meldung wie die folgende ausgibt:

Could not connect to Redis at 127.0.0.1:8000: Connection refused

läuft der stunnel-Dienst meist nicht oder lauscht nicht auf der erwarteten Adresse beziehungsweise dem vorgesehenen Port.

Überprüfen Sie zunächst den Status von stunnel4:

sudo systemctl status stunnel4

Falls der Dienst beendet wurde oder fehlgeschlagen ist, starten Sie ihn neu:

sudo systemctl restart stunnel4

Kontrollieren Sie anschließend, ob stunnel tatsächlich einen TCP-Port geöffnet hat:

sudo ss -tlnp | grep stunnel

Wird kein lauschender Socket angezeigt, ist der Dienst wahrscheinlich beim Start fehlgeschlagen. Prüfen Sie die Konfiguration und analysieren Sie die aktuellen Protokolle:

sudo journalctl -u stunnel4 -n 50 –no-pager

Achten Sie dort insbesondere auf Konfigurationsfehler, DNS-Probleme oder fehlende Berechtigungen.

Authentication required oder NOAUTH Authentication required

Viele verwaltete Redis-Datenbanken verlangen eine Authentifizierung, bevor Befehle ausgeführt werden dürfen. Erfolgt keine Anmeldung, kann Redis beispielsweise folgende Antwort liefern:

(error) NOAUTH Authentication required.

Das Passwort kann während des Verbindungsaufbaus mit -a übergeben werden:

redis-cli -h 127.0.0.1 -p 8000 -a your_password

Alternativ können Sie sich nach dem Start der Redis-CLI manuell authentifizieren:

127.0.0.1:8000> auth your_password

Vergleichen Sie das Passwort genau mit dem Wert, den der verwaltete Datenbankdienst bereitstellt. Bereits kleine Abweichungen in der Schreibweise oder versehentliche Leerzeichen am Ende können dazu führen, dass die Anmeldung scheitert.

stunnel4 startet und beendet sich sofort wieder

Nach der Installation oder nach Konfigurationsänderungen kann systemctl status stunnel4 den Zustand active (exited) anzeigen. Beendet sich der Dienst auch nach dem Anlegen einer Tunnelkonfiguration unmittelbar wieder, wurde stunnel möglicherweise nicht korrekt aktiviert.

Öffnen Sie /etc/default/stunnel4 und überprüfen Sie folgenden Wert:

ENABLED=1

Steht ENABLED auf 0, bleibt stunnel nicht aktiv. Ändern Sie den Wert und starten Sie den Dienst anschließend neu:

sudo systemctl restart stunnel4

Prüfen Sie danach mit sudo systemctl status stunnel4, ob der Dienst läuft, oder kontrollieren Sie mit sudo ss -tlnp | grep stunnel, ob ein Listening-Socket vorhanden ist.

Berechtigungsfehler bei der stunnel-PID-Datei

Nachdem stunnel zum Benutzer nobody gewechselt ist, muss der Prozess seine PID-Datei weiterhin schreiben können. Liegt diese unter /var/run und besitzt nobody dort keine Schreibrechte, kann stunnel beim Start scheitern.

Die in dieser Anleitung verwendete Konfiguration speichert die PID-Datei stattdessen unter /tmp:

pid = /tmp/stunnel-redis.pid

Falls Sie den pid-Pfad verändert haben, stellen Sie sicher, dass das Zielverzeichnis existiert und vom Benutzer nobody beschrieben werden kann:

sudo touch /tmp/stunnel-redis.pid

sudo chown nobody:nogroup /tmp/stunnel-redis.pid

Passen Sie stunnel.conf bei Bedarf an und starten Sie den Dienst anschließend erneut:

sudo systemctl restart stunnel4

Ist der Verzeichnispfad falsch oder verfügt das Dienstkonto nicht über die notwendigen Berechtigungen, korrigieren Sie die Dateisystemeinstellungen, bevor Sie stunnel erneut starten.

Fehler bei der DNS-Auflösung

Kann stunnel den Hostnamen des verwalteten Redis-Servers nicht auflösen, lassen sich keine ausgehenden Verbindungen herstellen. Das kann nach DNS-Änderungen beim Anbieter oder aufgrund einer lokalen Netzwerk- beziehungsweise DNS-Fehlkonfiguration auftreten. In den Protokollen finden sich dann häufig Hinweise auf fehlgeschlagene Namensauflösungen oder Zeitüberschreitungen.

Testen Sie die DNS-Auflösung auf dem Server mit:

nslookup your_redis_host

oder:

ping your_redis_host

Lässt sich der Hostname nicht auflösen, überprüfen Sie, ob Host und Port noch aktuell sind, und stellen Sie sicher, dass ausgehende Netzwerkverbindungen sowie die DNS-Auflösung auf dem Server funktionieren.

Um Probleme mit veralteten DNS-Einträgen zu verringern, insbesondere wenn sich die IP-Adressen eines verwalteten Endpunkts ändern können, ergänzen Sie folgende Option in stunnel.conf:

delay = yes

Mit delay führt stunnel bei jeder neuen Verbindung erneut eine DNS-Auflösung durch. Dadurch sinkt das Risiko, nach Änderungen an der Infrastruktur weiterhin eine veraltete Adresse zu verwenden.

FAQ zu Managed Redis, TLS und stunnel

Wie verbinde ich Redis über TLS mit stunnel?

Installieren Sie stunnel und redis-tools und richten Sie anschließend in /etc/stunnel/stunnel.conf einen Client-Tunnel ein. Setzen Sie client = yes, tragen Sie bei connect den Hostnamen und TLS-Port Ihrer verwalteten Redis-Instanz ein und definieren Sie mit accept einen lokalen Listener, beispielsweise 127.0.0.1:8000. Für die Zertifikatsprüfung verwenden Sie verifyChain = yes gemeinsam mit CApath = /etc/ssl/certs. Wenn der Zertifikatsspeicher des Betriebssystems nicht genutzt werden soll, kann stattdessen mit CAfile ein passendes CA-Bundle angegeben werden.

Nachdem stunnel über /etc/default/stunnel4 aktiviert und neu gestartet wurde, verbinden Sie sich ohne --tls über den lokalen Port:

export REDISCLI_AUTH=your_redis_password

redis-cli -h 127.0.0.1 -p 8000

In dieser Konfiguration verwendet redis-cli unverschlüsseltes TCP ausschließlich auf der lokalen Loopback-Verbindung zu stunnel. stunnel verschlüsselt die Daten anschließend und leitet sie an den entfernten TLS-Endpunkt weiter. Der vollständige Verbindungsablauf wird in Schritt 4 beschrieben.

Wie verbinde ich Redis direkt mit redis-cli?

Viele verwaltete Redis-Dienste setzen verschlüsselte Verbindungen voraus. Redis 6 und neuere Versionen von redis-cli unterstützen native TLS-Verbindungen mit --tls:

redis-cli -h managed_redis_hostname -p managed_redis_tls_port –tls

Verwendet der Dienst eine private Certificate Authority, geben Sie das dazugehörige CA-Bundle ausdrücklich an:

redis-cli -h managed_redis_hostname -p managed_redis_tls_port

–tls –cacert /path/to/ca.pem

Das Passwort kann vor dem Verbindungsaufbau auch in einer Umgebungsvariable gespeichert werden:

export REDISCLI_AUTH=your_redis_password

redis-cli -h managed_redis_hostname -p managed_redis_tls_port –tls

Bevor Sie TLS-Optionen verwenden, kontrollieren Sie, ob die installierte Version von redis-cli mit TLS-Unterstützung kompiliert wurde:

redis-cli –help 2>&1 | grep -E ‚–tls|–cacert‘

Erscheint --tls nicht in der Ausgabe, besitzt der Client keine TLS-Unterstützung. Verwenden Sie in diesem Fall stattdessen die zuvor beschriebene stunnel-Methode.

Einige selbst verwaltete Redis-Systeme stellen möglicherweise weiterhin einen unverschlüsselten Endpunkt bereit. Dort kann eine direkte Verbindung ohne TLS folgendermaßen aufgebaut werden:

redis-cli -h managed_redis_hostname -p managed_redis_port -a your_redis_password

Unverschlüsselte Verbindungen sollten nur genutzt werden, wenn der jeweilige Anbieter oder die eingesetzte Infrastruktur diese ausdrücklich unterstützt.

Warum zeigt redis-cli „Could not connect to Redis at 127.0.0.1:6379: Connection refused“?

Diese Meldung bedeutet, dass auf dem von redis-cli angesprochenen Host und Port kein Prozess lauscht. Da Redis standardmäßig Port 6379 verwendet, tritt der Fehler häufig auf, wenn -p nicht angegeben wurde, obwohl stunnel auf einem anderen lokalen Port wie 8000 läuft.

Beim Einsatz von stunnel weist eine abgelehnte Verbindung normalerweise darauf hin, dass stunnel gestoppt wurde, nicht korrekt gestartet ist oder auf einer anderen Adresse beziehungsweise einem anderen Port lauscht als in redis-cli angegeben. Prüfen Sie zunächst den Dienst:

sudo systemctl status stunnel4

Überprüfen Sie anschließend, ob ein stunnel-Prozess aktiv ist und welchen Port er verwendet:

ps aux | grep ‚[s]tunnel‘

sudo ss -tlnp | grep stunnel

Der Wert von accept in /etc/stunnel/stunnel.conf muss mit dem Port übereinstimmen, den Sie im redis-cli-Befehl verwenden. Ist der Dienst nicht verfügbar oder falsch konfiguriert, prüfen Sie die letzten Protokolleinträge:

sudo journalctl -u stunnel4 -n 50 –no-pager

Die vorherigen Abschnitte zur Fehlerbehebung enthalten weitere Schritte für Tunnel, die Verbindungen ablehnen oder direkt nach dem Aufbau wieder schließen.

Welche Aufgabe hat CAfile in stunnel.conf?

Mit der Option CAfile wird stunnel mitgeteilt, wo sich eine PEM-Datei mit einem oder mehreren vertrauenswürdigen CA-Zertifikaten befindet. Dieses Zertifikatspaket wird verwendet, um das TLS-Zertifikat des verwalteten Redis-Servers zu validieren.

Die Beispielkonfiguration dieser Anleitung nutzt stattdessen CApath = /etc/ssl/certs. Dadurch lädt stunnel die gehashten Zertifikate aus dem Zertifikatsspeicher des Betriebssystems, entsprechend dem Vorgehen in den offiziellen Unix-Beispielen von stunnel. CAfile ist besonders dann sinnvoll, wenn der Redis-Dienst ein eigenes privates CA-Bundle bereitstellt, das nicht unter /etc/ssl/certs vorhanden ist.

Unabhängig von der gewählten CA-Variante sollte zusätzlich die Prüfung der Zertifikatskette aktiviert werden:

verifyChain = yes

Ist die Überprüfung aktiv, kontrolliert stunnel, ob das Serverzertifikat auf eine vertrauenswürdige Root-CA zurückgeführt werden kann. Dadurch wird die ausgehende TLS-Verbindung besser gegen Man-in-the-Middle-Angriffe geschützt.

Kann ich stunnel auch unter Windows für Managed Redis verwenden?

Ja. stunnel stellt einen Windows-Installer bereit und unterstützt dort dieselben grundlegenden Konfigurationsoptionen wie unter Linux. Dazu gehören client, accept, connect, verifyChain, CAfile und pid.

Installieren Sie stunnel aus der offiziellen Quelle, erstellen Sie eine stunnel.conf mit dem Hostnamen und TLS-Port der verwalteten Redis-Instanz und verwenden Sie Windows-kompatible Pfade für CAfile und pid. Nach dem Start des stunnel-Dienstes verbinden Sie redis-cli mit dem lokal unter accept definierten Port. Das entspricht demselben zweistufigen Verbindungsmodell aus Schritt 4. Die Option --tls wird beim lokalen Redis-Client dabei nicht verwendet.

Was ist der Unterschied zwischen stunnel Client Mode und Server Mode?

Im Client-Modus mit client = yes nimmt stunnel lokal unverschlüsselte Verbindungen entgegen und baut anschließend eine TLS-Verbindung zu einem entfernten Server auf. Dieser Modus ist geeignet, wenn redis-cli oder eine andere lokale Anwendung einen normalen TCP-Socket erwartet, während der entfernte Redis-Endpunkt ausschließlich TLS akzeptiert.

Der Server-Modus arbeitet in die entgegengesetzte Richtung. stunnel nimmt verschlüsselte TLS-Verbindungen von entfernten Clients an, entschlüsselt sie und leitet die Daten unverschlüsselt an einen lokalen Dienst weiter. Da verwaltete Redis-Angebote normalerweise bereits einen eigenen TLS-Endpunkt bereitstellen, verbindet sich das lokale System als TLS-Client, entweder direkt mit redis-cli --tls oder über stunnel im Client-Modus. stunnel wird in diesem Szenario nicht als TLS-Server vor Redis geschaltet.

Ist stunnel mit Redis 6 oder neuer noch notwendig?

Für die meisten modernen Installationen ist stunnel nicht mehr zwingend erforderlich. Redis 6 führte native TLS-Unterstützung ein, und aktuelle redis-cli-Pakete unter Ubuntu 24.04 können sich in der Regel direkt über --tls verbinden. Dadurch werden weniger zusätzliche Komponenten benötigt, weshalb diese Variante in dieser Anleitung bevorzugt wird.

stunnel bleibt dennoch relevant, wenn redis-cli ohne TLS-Unterstützung kompiliert wurde, ältere Anwendungen nur unverschlüsseltes TCP unterstützen oder sich die Verbindungseinstellungen einer Anwendung nicht anpassen lassen. Für die tägliche Administration mit einem modernen Client ist native TLS-Unterstützung vorzuziehen, während stunnel für solche Kompatibilitätsfälle eingesetzt werden kann.

Wie starte ich stunnel automatisch beim Systemstart?

Unter Ubuntu und Debian setzen Sie zunächst ENABLED=1 in /etc/default/stunnel4 und legen die Tunnelkonfiguration unter /etc/stunnel/stunnel.conf ab. Aktivieren Sie anschließend den systemd-Dienst:

sudo systemctl enable stunnel4

Prüfen Sie danach, ob systemd den Dienst als aktiviert erkennt:

systemctl is-enabled stunnel4

Nach einem Neustart des Systems können Sie kontrollieren, ob der Tunnel weiterhin aktiv ist und auf dem konfigurierten Port lauscht:

sudo systemctl status stunnel4

sudo ss -tlnp | grep 8000

Unter CentOS, RHEL und verwandten Linux-Distributionen kann der Dienst statt stunnel4 lediglich stunnel heißen. Verwenden Sie dort entsprechend sudo systemctl enable stunnel. Die Konfiguration befindet sich üblicherweise weiterhin unter /etc/stunnel/.

Fazit