Unité 3.4 : Équilibrage de charge - Couche 4 (Réseau)

Introduction

L'unité 3.3 a terminé TLS à un équilibreur de charge public de niveau 7 parce que le bord devait lire HTTP et router le contenu. Le niveau des données a l'exigence inverse. Il parle base de données et d'autres protocoles non HTTP, et la posture GDPR/BSI de FinCorp veut que la charge utile soit chiffrée depuis le niveau application jusqu'à la base de données, sans intermédiaire qui puisse la lire. Un équilibreur de charge conscient du contenu ne peut pas servir ce niveau, et il ne devrait pas essayer.

Cette unité couvre le Managed Network Load Balancer (NLB), l'équilibreur de charge TCP de niveau 4 de la plateforme, et se termine par la création d'un NLB privé devant le niveau des données de FinCorp à l'intérieur du centre de données virtuel que vous avez créé dans l'unité 3.1. La décision de conception est délibérément étroite : distribuer les connexions TCP sur des cibles saines sans jamais les déchiffrer ou les inspecter.

1. Layer 4 TCP Pass-Through et quand il est préférable

Le Managed Network Load Balancer fonctionne au niveau TCP/IP de la couche 4 du modèle OSI et fournit un équilibrage de charge basé sur les connexions. Il s'agit d'un élément VDC préconfiguré, entièrement géré, déployé dans un environnement à haute disponibilité et intégré au réseau défini par logiciel de la plateforme. Il sert de point d'entrée et de sortie unique pour le trafic client : l'écouteur accepte les connexions, et les règles de transfert distribuent les sessions sur plusieurs cibles de calcul pour un traitement parallèle.

La propriété définissante est ce que le NLB ne fait pas. Il distribue tout le trafic basé sur TCP, y compris les protocoles de couche supérieure tels que HTTP et HTTPS, mais ses règles de transfert et de vérification de l'état sont strictement TCP. Les décisions de routage basées sur une URL ou un en-tête HTTP ne sont pas prises en charge. Le NLB ne décrypte jamais la connexion, il ne termine donc jamais TLS. Lorsqu'un client ouvre une connexion chiffrée, la session TLS est établie avec la cible principale, et le certificat et la clé privée se trouvent sur cette cible principale, et non sur l'équilibrage de charge. C'est exactement le comportement que le niveau des données souhaite.

Deux situations rendent la couche 4 le choix obligatoire plutôt qu'une préférence :

• Chiffrement de bout en bout. Lorsque le modèle de sécurité exige que la charge utile reste chiffrée du client (ou du niveau amont) à la cible principale sans décryptage intermédiaire, un équilibrage de charge de la couche 7 est disqualifié car la termination de TLS signifie la décryption. Le NLB transmet le flux TCP chiffré sans le modifier, donc la cible principale conserve le certificat et reste le seul endroit où le texte non chiffré existe. Pour le chemin de données réglementé de FinCorp, cela retire l'équilibrage de charge de l'ensemble des composants qui gèrent les données client non chiffrées, ce qui simplifie l'évaluation de la protection des données.
• Trafic non HTTP. Les protocoles de base de données (PostgreSQL, MariaDB protocoles de fil), les courtiers de messages et d'autres services TCP ne sont pas HTTP, il n'y a donc rien pour un équilibrage de charge de la couche 7 à router. La couche 4 est le seul niveau qui convient.

Puisque le NLB ne peut pas lire le contenu de l'application, il ne peut pas non plus effectuer de tâches conscientes du contenu : pas de règles de chemin, pas de routage d'hôte, pas de vérification de l'état HTTP conscient. Si vous avez besoin de ces fonctionnalités, vous êtes au mauvais niveau et l'unité 3.3 est la réponse. La formulation honnête est que les couches 4 et 7 ne sont pas classées ; elles se trouvent à des points différents de l'architecture et résolvent des problèmes différents.

1.1 Traduction d'adresse et modèle de connexion

La compréhension de la façon dont le trafic s'écoule réellement à travers le NLB explique plusieurs de ses contraintes. Le NLB effectue une traduction d'adresse de destination (DNAT) : les connexions client se terminent sur le Load Balancer, et l'équilibrage de charge initie ensuite une connexion dédiée et distincte à la cible principale choisie. La traduction d'adresse source (SNAT) n'est pas prise en charge, ce qui signifie que les cibles ne peuvent pas initier de connexions sortantes via le Load Balancer. Le NLB est un appareil de distribution entrant, et non un chemin de sortie. Lorsque les charges de travail privées ont besoin d'un accès internet sortant, c'est le travail de la passerelle NAT (SNAT uniquement, couvert dans l'unité 3.6), et les deux produits sont complémentaires plutôt que interchangeables.

Puisque l'équilibrage de charge ouvre sa propre connexion à la cible, la cible principale voit par défaut l'adresse de l'équilibrage de charge plutôt que celle du client d'origine. Lorsque la cible principale a besoin de l'adresse IP réelle du client (pour la journalisation, la logique géographique ou la limitation de débit), activez le protocole Proxy sur la cible afin que les informations de connexion d'origine soient conservées et transmises. Le service de cible principale (par exemple Apache, NGINX ou un contrôleur d'entrée dans Cluster) doit être configuré pour attendre et analyser l'en-tête du protocole Proxy, ou les connexions échoueront.

1.2 Algorithmes de distribution et pondération de canari

Une règle de transfert comporte un algorithme de distribution. Le NLB offre quatre algorithmes :

• Round Robin : distribue les connexions sur les cibles dans un ordre circulaire et séquentiel, en respectant le poids de chaque cible.
• Moins de connexions : envoie la prochaine connexion à la cible ayant le moins de connexions actives, ce qui convient aux sessions longues ou inégales.
• Aléatoire : distribue les connexions de manière aléatoire sur les cibles.
• Adresse IP source : mappe un client de manière cohérente à la même cible en fonction de son adresse source.

Indépendamment de l'algorithme, le NLB conserve les sessions actives mappées à la même cible grâce à l'affinité de l'adresse IP source (sessions collantes) aussi longtemps que les sessions TCP sous-jacentes restent actives. L'affinité de l'adresse IP source est ce qui maintient une connexion sur un serveur principal ; la sélection de l'algorithme d'adresse IP source étend cette collante pour maintenir un client donné sur le même serveur sur les connexions, ce qui compte lorsque les serveurs principaux ne partagent pas l'état TLS et que vous souhaitez éviter une renégociation contre un Node différent.

Chaque cible comporte un poids allant de 1 à 256, par défaut 1, et le trafic est distribué en proportion du poids de la cible par rapport au poids combiné de toutes les cibles. Il s'agit du mécanisme pour un canari contrôlé. Pour envoyer environ dix pour cent de nouvelles connexions à une version candidate, enregistrez la cible canari avec un poids faible par rapport aux cibles stables à poids élevé (par exemple, poids 1 sur la cible canari contre poids 9 sur la cible titulaire) et surveillez son état et ses métriques avant d'augmenter le poids. La pondération oriente les nouvelles connexions uniquement ; les sessions déjà fixées par l'affinité de l'adresse IP source restent où elles sont jusqu'à ce qu'elles se ferment, donc un changement de poids se draine progressivement plutôt queinstantanément. Pour FinCorp, la pondération canari permet à un nouveau service d'accès aux données de prendre une petite part observable du trafic réel sans basculement d'un jour à l'autre.

2. Composition de la couche publique 7 avec la couche privée 4

La forme canonique en couches de l'Unité 1.2 place un équilibreur de charge de couche 7 public à la limite et un équilibreur de charge de couche 4 privé devant le niveau des données. Les deux ne sont pas redondants ; chacun fait ce que l'autre ne peut pas.

L'équilibreur de charge de couche 7 public (Unité 3.3) se trouve sur la limite publique, met fin à TLS, et achemine HTTP par contenu vers le niveau d'application sans état. L'équilibreur de charge NLB privé se trouve entièrement sur un réseau privé : son écouteur n'est exposé qu'au trafic interne, il gère donc les connexions est-ouest à l'intérieur du centre de données plutôt que le trafic internet nord-sud. Le niveau d'application ouvre des connexions TCP chiffrées vers l'écouteur privé du NLB, le NLB les répartit sur les cibles du niveau des données, et TLS se termine sur ces cibles. Aucun IP public ne touche le niveau des données, et aucun composant entre l'application et la base de données ne peut lire la charge utile.

Cette composition clarifie également une limite de sécurité qui piège les gens. Les pare-feu de carte réseau et Network Security Groups sont liés aux cartes réseau de serveur uniquement ; ils ne s'appliquent pas à l'Load Balancer géré (Unité 3.2). Le NLB transporte des règles de pare-feu de base qui sont appliquées automatiquement à partir de ses règles de transfert et ne peuvent pas être éditées, mais vous ne pouvez pas attacher un groupe de sécurité de réseau à celui-ci et il n'y a pas de liste d'autorisation IP sur l'équilibreur de charge lui-même. Le contrôle d'accès pour le niveau des données appartient donc aux pare-feu de carte réseau des cibles et à la topologie : les données LAN restent privées, et la seule chose qui devrait les atteindre est le niveau d'application via le NLB. Le fait de garder le NLB privé est en soi un contrôle principal, car un écouteur privé est inaccessible depuis internet par construction.

Une note pratique sur le placement : dans le Data Center Designer, l'élément NLB comporte deux interfaces. L'interface Nord est l'écouteur et se connecte vers les clients (un élément d'accès à internet pour un NLB public, ou un LAN privé pour un privé) ; l'interface Sud est le backend et se connecte au LAN privé contenant les cibles. Pour le niveau des données de FinCorp, les deux côtés, côté écouteur et côté backend, restent sur des réseaux LAN privés.

DCD Déploiement étape par étape

Vous allez créer un équilibrageur de charge privé de niveau 4 devant le niveau de données de FinCorp, en réutilisant le centre de données virtuel et la topologie à trois LAN de l'unité 3.1. L'objectif est un équilibrageur de charge privé dont l'interface écouteuse fait face à l'application LAN et dont l'interface backend fait face au niveau de données privé LAN, en distribuant des connexions TCP chiffrées sur les cibles du niveau de données sans terminer TLS. Le prérequis est que les cibles (les serveurs du niveau de données) soient déjà provisionnés sur un réseau privé LAN ; l'équilibrageur de charge a besoin de cibles existantes pour distribuer les sessions.

Objectif de construction : Créer un équilibrageur de charge privé de niveau 4 devant le niveau de données.

Étapes (dans le Data Center Designer) :

1. Ouvrez le centre de données virtuel de FinCorp de l'unité 3.1 dans le Data Center Designer.
2. Faites glisser l'élément Réseau Load Balancer dans l'espace de travail.
3. Connectez les deux interfaces de l'équilibrageur de charge. Reliez l'interface Nord (l'interface écouteuse) au réseau d'application privé LAN, de sorte que l'équilibrageur de charge fasse face aux clients internes plutôt qu'à Internet. Reliez l'interface Sud (l'interface backend) au réseau privé LAN qui contient les cibles du niveau de données. Le fait de maintenir les deux côtés sur des réseaux privés LAN est ce qui rend cet équilibrageur de charge privé, est-ouest.
4. Dans l'Inspecteur, ouvrez l'onglet Paramètres et configurez l'interface écouteuse IP. Un équilibrageur de charge privé prend une interface écouteuse privée ; attribuez-la à partir du réseau d'application LAN afin que le niveau d'application ait une adresse stable à laquelle se connecter.
5. Ouvrez l'onglet Règles de transfert et sélectionnez Ajouter une règle de transfert. Nommez la règle, choisissez l'algorithme de distribution (par exemple, le moins de connexions pour les connexions de base de données, ou l'adresse IP source où vous avez besoin d'un client fixé à une Node), et confirmez le champ Protocole, qui est prédéfini sur TCP. Définissez l'adresse IP de l'interface écouteuse et le port de l'interface écouteuse que l'équilibrageur de charge acceptera les connexions (par exemple, le port de la base de données).
6. Dans la règle, sélectionnez Ajouter une cible pour chaque serveur du niveau de données. Fournissez l'adresse IP de la cible et le port de la cible, et définissez le Poids (1 à 256, valeur par défaut 1) ; utilisez des poids inégaux pour mettre en place un déploiement canari. Activez le protocole Proxy sur la cible si le backend a besoin de l'adresse IP du client d'origine, et configurez le backend pour l'analyser.
7. Configurez les paramètres de vérification de l'état pour la règle de transfert. Les vérifications sont basées sur TCP. Les valeurs par défaut sont une durée d'attente du client de 50000 ms, une durée d'attente de connexion de 5000 ms et une durée d'attente de cible de 50000 ms ; ajustez la durée d'attente de connexion pour déterminer à quelle rapidité vous souhaitez qu'une cible non réactive soit marquée comme non saine et retirée de la rotation.
8. Mettez en œuvre les modifications. L'équilibrageur de charge devient actif selon les paramètres, en routant uniquement vers les cibles qui passent la vérification de l'état.

Erreurs courantes :

• S'attendre à ce que l'équilibrageur de charge termine TLS. Il ne le fait pas. Le certificat et la clé privée restent sur les cibles backend ; ne planifiez pas une conception de certificat sur l'équilibrageur de charge au niveau 4.
• Essayer de router sur l'URL ou le chemin HTTP. Les règles de transfert et les vérifications de l'état sont strictement basées sur TCP ; le routage de contenu est une tâche de niveau 7 (unité 3.3).
• Essayer d'attacher un groupe de sécurité réseau ou une liste d'autorisation IP à l'équilibrageur de charge. Il n'y en a pas. Les règles de pare-feu auto-générées de l'équilibrageur de charge ne peuvent pas être modifiées ; placez le filtrage sur les pare-feu NIC des cibles et gardez l'interface écouteuse privée.
• Supposer que l'équilibrageur de charge donne aux cibles une sortie Internet. Il s'agit uniquement d'une entrée DNAT ; le SNAT n'est pas pris en charge. Mettez en œuvre une passerelle NAT (unité 3.6) pour une sortie privée.
• Oublier que le backend voit l'adresse de l'équilibrageur de charge. Si l'application a besoin de l'adresse IP du client réel, activez le protocole Proxy sur la cible et configurez le backend pour l'attendre, ou les connexions sont interrompues.
• Pointer l'équilibrageur de charge vers des cibles qui n'existent pas encore. Les cibles doivent être provisionnées sur leur réseau privé LAN avant que l'équilibrageur de charge ait quelque chose à distribuer.

Résumé

Le Managed Network Load Balancer est l'équilibreur TCP de couche 4 de la plateforme : il distribue les connexions sur des cibles saines en utilisant Round Robin, Least Connections, Random ou Source IP, pondère les cibles de 1 à 256 pour le contrôle canari, et effectue une traduction d'adresses réseau (DNAT) de sorte que les connexions clientes se terminent sur l'équilibreur et qu'une nouvelle connexion s'ouvre vers la cible. Il ne décrypte jamais le trafic, il ne termine donc jamais TLS, ce qui est précisément pourquoi il convient aux protocoles non HTTP et aux chemins de données chiffrés de bout en bout où le certificat doit rester sur le backend. Placé en privé devant le niveau de données de FinCorp, derrière le bord public de la couche 7, il complète la forme en couches de l'unité 1.2 sans exposition publique et sans saut lisible entre l'application et la base de données.

Points clés :

• La couche 4 est un passage TCP : tout trafic TCP est distribué, mais les règles et les vérifications de santé sont strictement TCP, il n'y a donc pas de routage de contenu.
• Le NLB ne termine pas TLS ; le backend conserve le certificat, ce qui permet le chiffrement de bout en bout et le trafic non HTTP.
• Les algorithmes sont Round Robin, Least Connections, Random et Source IP ; les sessions adhésives sont une affinité source IP maintenue tant que les sessions TCP restent actives.
• Les poids cibles (1 à 256, valeur par défaut 1) distribuent le trafic de manière proportionnelle et constituent le mécanisme canari ; le pesage dirige les nouvelles connexions uniquement.
• DNAT entrant uniquement, pas de SNAT ; le NLB ne fournit pas de sortie (utilisez une passerelle NAT). Aucun groupe de sécurité réseau (NSG) ou liste d'autorisation IP ne se lie à l'équilibreur géré, le filtrage appartient donc aux cibles.
• Composez un bord public de la couche 7 avec un équilibreur privé de la couche 4 devant un niveau de données privé uniquement.