Gateway Load Balancer (GWLB) est idéal pour déployer, étendre ou gérer des appliances réseau virtuelles tierces (NVA) dans des scénarios tels que les pare-feu, la détection d'intrusion, la mise en miroir du trafic et l'inspection approfondie des paquets (DPI). GWLB fonctionne en mode transparent au niveau de la couche 3 du modèle de référence OSI (Open Systems Interconnection). Vous devez donc préparer votre environnement avant d'utiliser GWLB pour déployer des NVA. Cette rubrique explique le fonctionnement de GWLB et comment intégrer des NVA avec ce service.
Qu'est-ce que GWLB ?
GWLB est un équilibreur de charge qui fonctionne au niveau de la couche 3, également appelée couche réseau, du modèle de référence OSI. Il aide les applications d'entreprise à déployer, étendre et gérer divers types d'appliances réseau virtuelles tierces (NVA) dans des scénarios tels que les pare-feu, la détection d'intrusion, la mise en miroir du trafic et l'inspection approfondie des paquets (DPI). GWLB offre les capacités suivantes :
GWLB prend en charge le déploiement de plusieurs appliances réseau virtuelles tierces.
GWLB assure un déploiement plus fiable des appliances réseau virtuelles tierces.
GWLB prend en charge la disponibilité inter-zones des appliances réseau virtuelles tierces.
GWLB peut fonctionner avec PrivateLink pour maintenir la disponibilité des appliances réseau virtuelles tierces entre les réseaux privés virtuels (VPC) et les comptes.
GWLB est compatible avec les services SaaS (software as a service) des fournisseurs d'appliances réseau virtuelles tierces.
Fonctionnement
Flux de travail
Comme illustré dans la figure suivante, une instance GWLB est connectée à un endpoint GWLB d'un autre VPC. Un endpoint GWLB est un type spécial d'endpoint VPC. Une instance GWLB peut être connectée à plusieurs endpoints GWLB.
Le tableau suivant décrit le fonctionnement d'une instance GWLB.
|
N° |
Description |
|
① |
Le trafic réseau du client vers le serveur est acheminé vers un endpoint GWLB. |
|
② |
L'endpoint GWLB transfère le trafic réseau vers l'instance GWLB associée via PrivateLink. |
|
③ |
L'instance GWLB encapsule le paquet d'origine à l'aide de GENEVE et transfère le trafic vers une NVA saine en backend, selon l'algorithme de répartition du trafic. La NVA identifie la source du trafic sur la base d'informations telles que l'ID d'endpoint GWLB de 64 bits transporté par GENEVE. |
|
④ |
Après avoir traité le paquet, la NVA le renvoie à l'instance GWLB en utilisant GENEVE. |
|
⑤ |
L'instance GWLB transfère le trafic vers l'endpoint GWLB correspondant via PrivateLink. |
|
⑥ |
L'endpoint GWLB interroge une route en fonction de l'adresse de destination et transfère le trafic vers le serveur de destination. |
Méthodes de répartition du trafic
GWLB prend en charge la répartition du trafic basée sur l'algorithme de hachage cohérent appliqué aux paquets de type 5-tuple, 3-tuple ou 2-tuple. Un paquet 5-tuple contient l'adresse IP source, l'adresse IP de destination, le protocole, le port source et le port de destination. Un paquet 3-tuple contient l'adresse IP source, l'adresse IP de destination et le protocole. Un paquet 2-tuple contient l'adresse IP source et l'adresse IP de destination. GWLB achemine le trafic ayant le même tuple vers le même serveur backend.
Cas généraux :
Pour le trafic transmis via TCP ou UDP, sélectionnez un algorithme de hachage basé sur les paquets 5-tuple.
Pour le trafic transmis via un protocole autre que TCP et UDP, sélectionnez un algorithme de hachage basé sur les paquets 3-tuple.
Mécanisme de contrôle de santé
GWLB effectue périodiquement des contrôles de santé à intervalles réguliers. Il envoie des paquets TCP, HTTP ou HTTPS à une NVA backend et vérifie si celle-ci est saine en fonction de sa réponse.
TCP : Si GWLB parvient à établir une connexion TCP avec une NVA backend, il considère que cette NVA est saine.
HTTP ou HTTPS : Si le code d'état HTTP 2xx ou 3xx est renvoyé après l'envoi d'une requête HTTP ou HTTPS par GWLB à la NVA backend, GWLB considère que la NVA est saine. Sinon, GWLB considère que la NVA n'est pas saine. GWLB n'effectue pas de vérification du nom d'hôte sur le certificat transmis. Par conséquent, les certificats, y compris les certificats auto-signés, sont pris en compte tant qu'ils ne sont pas expirés.
Les paquets de contrôle de santé ne sont pas encapsulés par GENEVE.
Si la NVA ne répond pas avant la fin du délai d'attente du contrôle de santé, elle échoue aux tests.
Intégrer une NVA avec GWLB
Méthode d'intégration
GWLB communique avec les NVA backend via le protocole GENEVE. Il encapsule le TLV (type-length-value) GENEVE dans chaque paquet pour envoyer des informations supplémentaires, telles que l'ID d'endpoint GWLB et le Flow Cookie, à la NVA. Un paquet GENEVE reçu par une NVA peut contenir un ou plusieurs TLV GENEVE.
ID d'endpoint GWLB : ID de 64 bits attribué à l'endpoint GWLB. Une NVA peut utiliser un ID d'endpoint GWLB pour associer les paquets à ses configurations. Un ID d'endpoint GWLB sert également à déterminer la source du trafic.
Flow Cookie : nombre aléatoire de 32 bits généré pour un flux lorsque GWLB crée une entrée de flux dans une table de flux. Chaque flux possède un cookie unique. La NVA doit renvoyer le cookie d'origine. Lorsque GWLB reçoit un paquet de la NVA, il ne transfère le paquet que si le cookie contenu dans le paquet correspond au cookie attribué au flux. Si le cookie ne correspond pas au cookie attribué ou s'il n'y a pas de cookie, le paquet est supprimé.
Le processus suivant décrit comment une NVA répond à une requête :
Encapsulez le paquet d'origine dans un en-tête GENEVE.
Échangez l'adresse IP source et l'adresse IP de destination dans l'en-tête IPv4 externe. L'adresse IP source est l'adresse IP de la NVA et l'adresse IP de destination est l'adresse IP de GWLB.
Conservez le port d'origine et n'échangez pas les ports source et de destination dans l'en-tête IPv4 externe.
Mettez à jour la somme de contrôle IP dans l'en-tête IPv4 externe.
Renvoyez tous les champs d'origine dans l'en-tête GENEVE.
Renvoyez tous les TLV d'origine dans l'option GENEVE, y compris l'ID d'endpoint GWLB et le Flow Cookie.
Format du paquet GENEVE
L'exemple suivant montre le format d'un paquet GENEVE. Pour plus d'informations sur GENEVE, consultez RFC 8926.
Outer IPv4 Header:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |Protocol=17 UDP| Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = xxxx | Dest Port = 6081 Geneve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Geneve Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0|Opt Len = 8|O|C| Rsvd. | EtherType = 0x0800 or 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) = 0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Geneve Options: Alibaba Cloud Gateway Load Balancer TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class = 0x0139 (Ali)| Type = 1 |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 64-bit GWLB endpoint ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class = 0x0139 (Ali)| Type = 3 |R|R|R| Len = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Flow Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Customer payload follows...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Customer payload identified by EtherType in Geneve header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+