Introduction
Redis est largement utilisé pour la mise en cache, le stockage de sessions et le courtage de messages, mais les problèmes de connectivité réseau peuvent paralyser les applications qui en dépendent. Les symptômes peuvent inclure des délais d'attente, des connexions refusées ou des échecs intermittents. Ce guide fournit une approche pratique, étape par étape, pour diagnostiquer et résoudre les problèmes de réseau de Redis. Nous couvrons les outils et commandes essentiels, de la vérification de la résolution DNS au test de connectivité TCP et à la vérification des règles de pare-feu. À la fin, vous disposerez d'un processus de dépannage reproductible et d'une liste de contrôle pour les opérations continues. Que vous soyez développeur, consultant DevOps ou membre d'une équipe de startup, la maîtrise de ces techniques vous aidera à rétablir rapidement le service et à prévenir les problèmes futurs.
Inventaire de la version et de l'environnement
Avant de dépanner, rassemblez des informations sur votre configuration Redis. Cet inventaire aide à identifier les problèmes de compatibilité potentiels et à cerner la zone problématique. Enregistrez les détails suivants :
- Version du serveur Redis :
redis-server --versionouredis-cli info server | grep redis_version - Bibliothèque cliente Redis et version (le cas échéant)
- Système d'exploitation et version du noyau sur le serveur et le client
- Topologie du réseau : Le serveur Redis et le client sont-ils sur le même hôte, le même LAN ou à travers Internet ? Y a-t-il des équilibreurs de charge, du NAT ou des réseaux virtuels impliqués ?
- Emplacement du fichier de configuration Redis et paramètres pertinents :
bind,port,protected-mode,requirepass, optionstls-*. - Configuration DNS : Le client utilise-t-il un nom d'hôte ou une adresse IP ? Y a-t-il des entrées DNS personnalisées ?
Créez un tableau résumant ces informations pour référence :
| Composant | Détails | Version/Valeur |
|---|---|---|
| Serveur Redis | Version, OS, IP/nom d'hôte | p. ex., 7.2.4, Ubuntu 22.04, 192.168.1.10 |
| Client | Environnement d'application, bibliothèque | p. ex., Node.js 20, redis 4.6.10 |
| Réseau | Topologie, pare-feux, NAT | p. ex., même VPC, groupe de sécurité autorisant 6379 |
| Configuration | Paramètres clés | bind, protected-mode, requirepass |
Cet inventaire est crucial car de nombreux problèmes de réseau Redis proviennent d'une mauvaise configuration ou de changements d'environnement. Par exemple, Redis se lie par défaut à 127.0.0.1, ce qui n'autorise que les connexions locales. Si votre client s'exécute sur une autre machine, vous devrez mettre à jour la directive bind.
Chemin de configuration sécurisé
Lorsque vous modifiez les paramètres réseau de Redis, procédez avec prudence pour éviter de perturber le trafic de production. Suivez ces bonnes pratiques :
- Sauvegardez le fichier de configuration actuel avant de le modifier :
cp /etc/redis/redis.conf /etc/redis/redis.conf.bak - Apportez des modifications progressivement et testez chacune d'elles. Évitez de changer plusieurs paramètres à la fois.
- Utilisez un environnement de préproduction si possible pour répliquer la configuration de production et tester les changements.
- Appliquez les modifications avec un outil de gestion de configuration si disponible, ou redémarrez Redis proprement après les changements.
Options clés de configuration réseau de Redis
- bind : Spécifie les interfaces réseau sur lesquelles Redis écoute. Pour les connexions depuis des hôtes distants, définissez l'IP du serveur ou
0.0.0.0pour toutes les interfaces, mais avec prudence et en activant l'authentification/pare-feu. - port : La valeur par défaut est 6379. Modifiez-la si nécessaire, mais assurez-vous que les clients utilisent le bon port.
- protected-mode : Lorsqu'il est activé (par défaut) et qu'aucun mot de passe n'est défini, Redis n'accepte que les connexions depuis l'interface de bouclage. Pour un accès distant, définissez un mot de passe ou
protected-mode no(non recommandé sans autres mesures de sécurité). - requirepass : Définit un mot de passe pour l'authentification des clients. Toujours le définir pour un accès distant.
- tls-port, tls-cert-file, etc. : Activent TLS pour les connexions chiffrées.
Exemple : Activer les connexions distantes avec mot de passe
Supposons que vous deviez autoriser les connexions depuis un serveur d'application distant (IP 192.168.1.20) vers votre serveur Redis (192.168.1.10). Suivez ces étapes :
- Modifiez
redis.conf:
bind 192.168.1.10
protected-mode yes
requirepass yourstrongpassword
- Redémarrez Redis :
sudo systemctl restart redis-serverousudo service redis-server restart
- Vérifiez que Redis écoute :
sudo netstat -tlnp | grep redisdevrait afficher :
tcp 0 0 192.168.1.10:6379 0.0.0.0:* LISTEN 1234/redis-server
Côté client, connectez-vous avec :
redis-cli -h 192.168.1.10 -p 6379 -a yourstrongpassword ping
Sortie attendue : PONG
Important : L'utilisation de -a sur la ligne de commande expose le mot de passe dans les listes de processus. Envisagez d'utiliser la variable d'environnement REDISCLI_AUTH ou de fournir le mot de passe de manière interactive.
Vérification et diagnostics
Une fois votre configuration en place, utilisez les étapes de diagnostic suivantes pour vérifier la connectivité et identifier les problèmes.
1. Connectivité de base : ping et telnet
- Utilisez
pingpour tester la joignabilité du réseau (l'ICMP peut être bloqué, donc ce n'est pas toujours concluant) :
ping 192.168.1.10
- Utilisez
telnetouncpour tester la connexion TCP au port Redis :
telnet 192.168.1.10 6379
En cas de succès, vous verrez quelque chose comme :
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
Tapez ensuite PING et appuyez sur Entrée. Redis devrait répondre avec +PONG. Si vous voyez -NOAUTH Authentication required., l'authentification est nécessaire. Tapez AUTH yourpassword avant PING.
2. Utilisation de redis-cli
redis-cli est le client en ligne de commande standard de Redis. Utilisez-le pour tester la connexion et l'authentification :
redis-cli -h 192.168.1.10 -p 6379 -a yourstrongpassword ping
Attendu : PONG
Si vous obtenez Could not connect to Redis at 192.168.1.10:6379: Connection refused, le serveur n'est pas joignable ou n'écoute pas sur cette interface/port. Vérifiez le bind du serveur et le pare-feu.
3. Résolution DNS
Si vous utilisez un nom d'hôte au lieu d'une adresse IP, vérifiez la résolution DNS depuis la machine cliente :
nslookup myredis.example.com
ou
dig myredis.example.com
Assurez-vous que l'IP résolue est correcte et joignable. Redis n'effectue pas de recherches DNS lors de la liaison ; il utilise l'IP littérale dans bind. Donc si vous définissez bind sur un nom d'hôte, Redis le résout une fois au démarrage. Il est préférable d'utiliser une adresse IP pour éviter la dépendance au DNS au démarrage.
4. Règles de pare-feu
Les pare-feux (iptables, firewalld, groupes de sécurité cloud) peuvent bloquer le port 6379. Vérifiez les règles sur le serveur et tout dispositif intermédiaire :
- Sur Linux avec iptables :
sudo iptables -L -n | grep 6379
Cherchez une règle ACCEPT pour le port 6379. Si elle est absente, ajoutez une règle (mais comprenez la gestion de votre pare-feu) :
sudo iptables -A INPUT -p tcp --dport 6379 -j ACCEPT
Cependant, pour des modifications permanentes, utilisez l'outil de pare-feu de votre distribution (p. ex., firewalld, ufw).
- Environnements cloud : Vérifiez le groupe de sécurité ou la liste de contrôle d'accès réseau pour vous assurer que le TCP 6379 entrant est autorisé depuis la plage IP du client.
5. Problèmes de routage et de réseau
Utilisez traceroute pour voir le chemin et identifier où les paquets peuvent être perdus :
traceroute 192.168.1.10
Si la route ne se termine pas, il y a un problème d'infrastructure réseau (p. ex., route manquante, VPN en panne).
6. Journaux Redis
Les journaux Redis peuvent fournir des indices. Vérifiez le fichier journal (généralement /var/log/redis/redis-server.log) :
tail -f /var/log/redis/redis-server.log
Cherchez des messages concernant les connexions refusées, les erreurs de liaison ou les échecs d'authentification.
7. Performances et limites de connexion
Parfois, les problèmes de connectivité sont dus à l'épuisement des ressources. Vérifiez le nombre de connexions client :
redis-cli info clients
Cherchez connected_clients et maxclients. Si le maximum est atteint, augmentez maxclients dans la configuration et redémarrez.
Modes de défaillance et récupération
Comprendre les modes de défaillance courants vous aide à récupérer rapidement et à mettre en œuvre des plans de restauration.
Modes de défaillance courants
- Connexion refusée : Le serveur ne fonctionne pas ou n'écoute pas sur la bonne interface/port. Récupération : Démarrez Redis ou corrigez
bind/port. - Délai de connexion dépassé : Problème de pare-feu ou de routage réseau généralement. Récupération : Vérifiez le pare-feu, les groupes de sécurité et le routage.
- Erreur d'authentification requise : Le client n'a pas fourni de mot de passe ou le mot de passe est incorrect. Récupération : Fournissez le bon mot de passe ; réinitialisez le mot de passe si oublié (redémarrez temporairement avec
--requirepass). - Échec de résolution DNS : Le nom d'hôte ne se résout pas. Récupération : Utilisez une adresse IP ou corrigez les enregistrements DNS.
- Échec de la poignée de main TLS : Certificats incompatibles ou client non configuré pour TLS. Récupération : Vérifiez les certificats et les paramètres TLS du client.
- Dégradation des performances : Latence élevée ou perte de paquets. Récupération : Enquêtez sur la qualité du réseau, le slowlog Redis et les délais d'attente du client.
Étapes de restauration et de récupération
Lorsqu'un changement de configuration cause des problèmes, revenez à la configuration de sauvegarde :
sudo cp /etc/redis/redis.conf.bak /etc/redis/redis.conf
sudo systemctl restart redis-server
Après la restauration, vérifiez à nouveau la connectivité en utilisant les étapes de diagnostic ci-dessus. Si le problème persiste, vérifiez d'autres facteurs comme les changements de code client ou les changements réseau.
Scénario d'exemple : Après avoir activé l'accès distant, les clients ne peuvent pas se connecter
Vous avez changé bind en 0.0.0.0 et redémarré Redis. Maintenant, aucun client ne peut se connecter. Enquêtez :
- Vérifiez si Redis écoute :
ss -tlnp | grep 6379devrait afficher*:6379ou0.0.0.0:6379. - Vérifiez le pare-feu : Si vous avez un pare-feu local, il peut toujours bloquer le port. Ajoutez une règle d'autorisation.
- Vérifiez
protected-mode: Si vous avez définiprotected-mode yesmais pas de mot de passe, Redis refusera les connexions externes. Définissez un mot de passe ou désactivez le mode protégé (non recommandé). - Restauration : Restaurez la configuration d'origine et redémarrez.
Pièges courants et comment les éviter
Au-delà des modes de défaillance ci-dessus, voici des erreurs fréquentes qui conduisent à des problèmes de réseau Redis, avec des explications et des mesures préventives :
- Liaison à 127.0.0.1 par défaut : Les nouvelles installations laissent souvent l'adresse de liaison par défaut, ce qui fait échouer les clients distants avec « Connexion refusée ». Examinez toujours la directive
binddansredis.confet définissez-la sur l'IP d'interface appropriée ou0.0.0.0(avec des mesures de sécurité en place).
- Ignorer
protected-mode: Lorsqueprotected-modeest activé et qu'aucun mot de passe n'est défini, Redis rejette les connexions externes même sibind 0.0.0.0est défini. Comprenez que le mode protégé est une fonction de sécurité ; définissezrequirepassou désactivez le mode protégé uniquement dans des réseaux de confiance.
- Utiliser des noms d'hôte dans
bind: Comme indiqué, Redis ne résout le nom d'hôte qu'au démarrage. Si le DNS change ou que le service redémarre lorsque le DNS est indisponible, Redis peut ne pas démarrer ou se lier incorrectement. Utilisez des adresses IP pour éviter cette fragilité.
- Mauvaise configuration du pare-feu : De nombreux déploiements cloud ont à la fois des pare-feux au niveau du système d'exploitation et des règles de groupe de sécurité. Oublier d'ouvrir le port dans l'une ou l'autre couche entraîne des délais d'attente. Vérifiez toujours les deux et testez depuis un hôte externe.
- Ne pas définir de mot de passe : Exposer Redis sans authentification sur Internet peut conduire au vol ou à la perte de données. Même sur les réseaux internes, définir un mot de passe fort est une pratique de sécurité de base. Utilisez
requirepasset envisagezACLpour des autorisations granulaires.
- Négliger les délais d'attente côté client : Les pools de connexion d'application peuvent avoir des délais d'attente plus courts que les paramètres propres de Redis, provoquant des déconnexions apparentes. Examinez la configuration de la bibliothèque cliente (p. ex.,
connectTimeout,commandTimeout) et ajustez pour correspondre à la latence du réseau et aux temps de réponse de Redis.
Liste de contrôle des opérations
Utilisez cette liste de contrôle pour la maintenance régulière et lors du dépannage. Pour chaque élément, attribuez une personne responsable et une fréquence de révision.
| Élément de la liste de contrôle | Commande/Action | Responsable | Fréquence de révision |
|---|---|---|---|
| Vérifier que le service Redis fonctionne | systemctl status redis-server | Administrateur système (p. ex., Jane Doe) | Contrôle automatisé quotidien, manuel hebdomadaire |
| Vérifier les interfaces et le port d'écoute | ss -tlnp | grep redis | Administrateur système | Hebdomadaire |
| Tester la connectivité locale | redis-cli ping (attendre PONG) | Développeur d'application | À chaque déploiement |
| Tester la connectivité distante depuis l'hôte d'application | redis-cli -h <hôte> -p <port> -a <mot de passe> ping | Développeur d'application | À chaque déploiement |
| Examiner le journal Redis pour les erreurs | tail -n 100 /var/log/redis/redis-server.log | Administrateur système | Quotidien |
| Surveiller le nombre de connexions | redis-cli info clients | grep connected_clients | Équipe de surveillance | Continue via les métriques, alerte si >80% de maxclients |
| Vérifier les règles de pare-feu pour le port 6379 | sudo iptables -L -n | grep 6379 et groupe de sécurité cloud | Administrateur réseau | Mensuel ou après tout changement réseau |
| Valider la résolution DNS si des noms d'hôte sont utilisés | nslookup <nom d'hôte> | Administrateur réseau | Mensuel ou après des changements DNS |
| S'assurer que les certificats TLS sont valides et non expirés | openssl x509 -enddate -noout -in /chemin/vers/cert.pem | Ingénieur sécurité | Trimestriel ou avant expiration (p. ex., 30 jours à l'avance) |
| Examiner les paramètres du pool de connexion de l'application | Vérifier les connexions max, les délais d'attente dans la config de l'application | Développeur d'application | Mensuel ou lors des revues de performance |
| Documenter tout changement effectué et mettre à jour la sauvegarde de configuration | Mettre à jour le runbook et la sauvegarde de config dans le contrôle de version | Administrateur système | Après chaque changement |
Conclusion
Le dépannage réseau de Redis nécessite une approche systématique. En maintenant un inventaire précis de votre environnement, en effectuant des changements de configuration sûrs et en utilisant les commandes de diagnostic décrites ici, vous pouvez identifier et résoudre rapidement les problèmes de connectivité. La liste de contrôle des opérations fournie aide à prévenir les problèmes et garantit que votre déploiement Redis reste sain. Commencez par un pilote restreint et mesurable lors du diagnostic des problèmes, car une isolation précoce simplifie le processus. N'oubliez pas de mettre en œuvre des mesures de sécurité comme l'authentification et TLS lorsque vous exposez Redis au-delà de localhost. Avec ces pratiques, vous pouvez garder vos applications basées sur Redis fonctionnant sans heurts.