Dans l'exploitation quotidienne, les problèmes les plus frustrants ne sont pas les erreurs évidentes, mais ces pannes "quantiques" qui apparaissent et disparaissent, rendant le diagnostic aussi difficile que d'attraper un fantôme. Imaginez : le nœud maître d'un cluster LVS haute disponibilité, point d'entrée du trafic, est incapable d'accéder de manière fiable à son propre adresse IP virtuelle (VIP). Les courbes de surveillance oscillent comme un rythme cardiaque irrégulier, et la commande curl alterne entre succès et timeout.

Ce n'est pas de la science-fiction, mais un problème réel survenu dans une architecture réseau complexe. Aujourd'hui, nous allons démystifier cette énigme et voir comment un "paquet martien" intercepté discrètement par le mécanisme de sécurité du noyau Linux peut rendre une connexion interne, qui devrait être transparente, complètement chaotique.

Sur le terrain : une connexion "quantique" déconcertante

Dans une architecture système haute disponibilité, il est courant d'utiliser LVS (Linux Virtual Server) en mode DR (Direct Routing) pour fournir une adresse IP virtuelle (VIP) aux services backend. Normalement, tous les clients accèdent aux services via ce VIP, et LVS se charge de distribuer le trafic vers les serveurs réels.

Cependant, lors d'un déploiement, un phénomène étrange a été observé : le nœud maître (IP : 192.168.1.5), qui sert de point d'entrée, renconrtait des problèmes d'instabilité lorsqu'il tentait d'accéder lui-même au VIP (192.168.1.7) qu'il exposait.

• Parfois, tout fonctionne : depuis le nœud maître, un curl vers le VIP montre un handshake TCP en trois étapes et une réponse HTTP complets et sains.
• Parfois, la requête échoue : la même opération reste bloquée pendant une longue période, se terminant par une erreur "Connection timed out" (délai de connexion dépassé).

Pourquoi la même opération sur le même nœud produit-elle deux résultats différents ?

En remontant à la source : deux chemins de trafic distincts

La clé du problème réside dans l'identité du destinataire sélectionné par LVS pour cette requête. Pour mieux comprendre, décrivons les deux scénarios de trafic :

Scénario A : Routage vers la machine locale (Le chemin du succès)

Requête envoyée -> Dispatcher LVS -> Décision : cible locale -> Redirection interne vers l'interface lo

Détails du chemin :

1. Le nœud maître (192.168.1.5) agit en tant que client et initie une requête vers le VIP (192.168.1.7).
2. La requête atteint le dispatcher LVS, qui détermine que la meilleure destination est le nœud maître lui-même.
3. LVS effectue une "redirection interne" qui oriente directement le paquet vers l'interface lo (boucle locale) du nœud.
4. Le processus applicatif sur le nœud local traite la requête et génère une réponse.
5. Le paquet de réponse est renvoyé depuis l'interface lo : comme toute la communication se déroule à l'intérieur du système d'exploitation, la traduction des adresses IP source (192.168.1.7) et destination (192.168.1.5) est gérée efficacement par le noyau, sans passer par aucune carte réseau physique.
6. Résultat : Connexion réussie, communication normale.

Scénario B : Routage vers le nœud esclave (Le mystère de l'échec) - Le "paquet martien" refoulé

Requête envoyée -> Dispatcher LVS -> Décision : cible nœud esclave -> Modification de l'adresse MAC du paquet pour l'esclave (192.168.1.6) -> Paquet envoyé via l'interface physique

Détails du chemin :

1. Le nœud maître (192.168.1.5) initie toujours une requête vers le VIP (192.168.1.7).
2. La requête atteint le dispatcher LVS, qui cette fois détermine que la requête doit être envoyée au nœud esclave (192.168.1.6).
3. LVS modifie l'adresse MAC du paquet pour cibler le nœud esclave, puis l'envoie via la carte réseau physique du nœud maître (par exemple, eth0).
4. Le nœud esclave reçoit la requête, la traite et est prêt à envoyer le paquet de réponse. L'adresse IP source de ce paquet de réponse est le VIP (192.168.1.7), et l'adresse IP de destination est l'IP du nœud maître (192.168.1.5).
5. Le nœud esclave envoie ce paquet de réponse directement à la carte réseau physique du nœud maître.
6. Le problème crucial survient ici : la carte réseau physique du nœud maître reçoit le paquet, mais la pile réseau du noyau Linux l'examine et l'écarte résolument.

Le coupable principal : la détection de "paquet martien" par le noyau

Le noyau Linux dispose d'un mécanisme de sécurité important appelé détection de "paquet martien" : "Comment mon propre IP peut-il arriver via une interface réseau externe (carte physique) ? Ce doit être un paquet 'martien' forgé pour tromper !". Pour des raisons de sécurité, le comportement par défaut du noyau est de jeter silencieusement de tels paquets, empêchant ainsi la réponse du nœud esclave d'être reçue par le nœud maître. Le client curl en amont attend le timeout et affiche une erreur.

Solution : activer le laissez-passer pour "les siens"

La cause étant identifiée, la solution devient claire : il faut indiquer au noyau que, dans certains scénarios spécifiques (comme le mode LVS DR), recevoir un paquet dont l'adresse source est une IP locale via une interface externe est "légitime" et non une attaque. Cela peut être fait en modifiant un paramètre du noyau : sysctl -w net.ipv4.conf.all.accept_local=1.

Conclusion

Ce problème étrange de "s'auto-accéder et échouer" est ainsi résolu. Ce n'était pas juste un ajustement de paramètre, mais une réévaluation de l'interaction entre les mécanismes de bas niveau du système et la conception de l'architecture de haut niveau.

• Le dilemme sécurité vs fonctionnalité : La détection de "paquets martiens" par le noyau fait partie de la sécurité réseau, visant à contrer les attaques par usurpation d'IP. Cependant, dans des architectures spécifiques comme LVS en mode DR, ce chemin de retour légitime déclenche une fausse alerte de sécurité. Cela nous enseigne que dans la conception et l'exploitation de systèmes complexes, il ne faut pas considérer un composant ou une règle de manière isolée, mais toujours dans le contexte du flux de trafic métier complet.
• Optimisation ciblée plutôt que désactivation brute : La solution n'est pas de désactiver tous les filtres de sécurité, mais d'utiliser le paramètre accept_local pour accorder un "feu vert" à ce trafic métier spécifique et légitime. Cela illustre l'approche de réglage chirurgical dans l'exploitation informatique : résoudre un problème spécifique avec un impact minimal.

La prochaine fois que vous rencontrez des "événements paranormaux" intermittents dans le monde réseau, posez-vous la question : un "gardien" zélé n'aurait-il pas, quelque part, empêché un "membre de la famille" d'entrer ? Comprendre les règles et les appliquer judicieusement est l'art de l'exploitation avancée.