Build an Internet firewall using GWLB - Server Load Balancer

Vue d'ensemble de la solution d'intégration entre GWLB et la passerelle IPv4

Dans les déploiements traditionnels de services publics, les ressources au sein d'un VPC communiquent directement avec Internet en associant des adresses IP publiques. Cette approche engendre plusieurs problèmes de sécurité :

Surface d'attaque étendue : chaque adresse IP publique associée constitue un point d'exposition direct sur Internet. À mesure que le nombre de ces adresses augmente sur différentes ressources, le périmètre de sécurité réseau de l'entreprise se fragmente, ce qui rend difficile la surveillance unifiée du trafic et l'application des politiques.
Gestion complexe des politiques : les politiques de sécurité (telles que les groupes de sécurité) doivent être configurées et maintenues séparément pour chaque ressource disposant d'une adresse IP publique. Cela accroît la charge opérationnelle et les coûts, tout en augmentant le risque d'erreurs de configuration susceptibles de compromettre la sécurité.
Absence d'inspection approfondie : les groupes de sécurité et les listes de contrôle d'accès réseau (ACL) appliquent principalement le contrôle d'accès au niveau de la couche 4 (en fonction des adresses IP et des ports). Ils ne peuvent pas effectuer d'inspection approfondie des paquets (DPI), de prévention des intrusions ni d'autres protections de sécurité de niveau 7.

En déployant la passerelle IPv4 conjointement avec GWLB, vous pouvez construire un pare-feu de périmètre Internet centralisé, transparent et évolutif. La passerelle IPv4 gère de manière centralisée tout le trafic public entrant et sortant du VPC. Ce trafic est ensuite acheminé via des points de terminaison Gateway Load Balancer (GWLBe) vers des appliances réseau virtuelles backend (telles que des pare-feux) pour une inspection approfondie. Après l'inspection, le trafic est renvoyé via le GWLBe correspondant, puis finalement transmis aux serveurs d'application.

Principales fonctionnalités

Passerelle IPv4
- Contrôle centralisé du trafic public : en combinant la passerelle IPv4 avec des tables de routage et d'autres composants, vous garantissez que tout le trafic public transite par la passerelle IPv4. Cela simplifie l'application unifiée des politiques de sécurité et l'audit, tout en réduisant efficacement les risques de sécurité liés à un accès décentralisé.
GWLB
- Inspection transparente du trafic : GWLB fonctionne comme une passerelle réseau de couche 3. Le trafic conserve ses adresses IP source et de destination d'origine lors de l'inspection par les appliances réseau virtuelles, sans nécessiter de modification côté clients ou services backend.
- Appliances réseau virtuelles évolutives : vous pouvez ajouter ou supprimer des appliances réseau virtuelles derrière GWLB à tout moment, en fonction des variations du trafic de service.
- Déploiement haute disponibilité multi-zones : GWLB et ses appliances réseau virtuelles backend peuvent être déployés sur plusieurs zones. En cas de défaillance d'une appliance réseau virtuelle ou d'un GWLBe dans une zone, le trafic bascule automatiquement vers des nœuds sains situés dans d'autres zones, assurant ainsi la haute disponibilité des services de sécurité.

Scénarios

Audit centralisé de la conformité en matière de sécurité : fournit un cluster unifié d'appliances de sécurité pour les secteurs soumis à des exigences strictes de conformité (comme la finance et le gouvernement), permettant un audit, une surveillance et un traçage cohérents des journaux de trafic public et des politiques de sécurité.
Protection de sécurité approfondie pour les services publics : offre une inspection approfondie du contenu pour les sites web, API ou applications exposés à Internet, défendant efficacement contre les attaques web, les scans malveillants, les intrusions virales et autres menaces avancées.
Accès sortant sécurisé pour les ressources VPC : propose un canal de sortie sécurisé pour les ressources VPC accédant activement à Internet (pour des tâches telles que les mises à jour de correctifs ou les appels d'API externes), empêchant l'accès à des sites malveillants et la fuite de données.

Limites

Au moins une appliance réseau virtuelle doit s'exécuter en backend de GWLB.
La politique d'accès (par exemple, les règles de groupe de sécurité) pour les serveurs backend de GWLB doit autoriser le trafic UDP sur le port 6081 (port du protocole Geneve).
Lors de la création d'un service de point de terminaison, vous devez sélectionner une région et une zone prenant en charge à la fois PrivateLink et les instances GWLB. Pour obtenir la liste des régions et zones prenant en charge PrivateLink et les instances GWLB, consultez Régions et zones prenant en charge PrivateLink et Régions et zones prenant en charge GWLB.
Les zones où le GWLBe est déployé doivent constituer un sous-ensemble des zones où les ressources du service de point de terminaison (GWLB) sont déployées pour établir une connexion.

Exemple de scénario

Le système métier principal d'une entreprise s'exécute dans un VPC situé dans la région Chine (Ulanqab) d'Alibaba Cloud. Pour garantir une haute disponibilité, les instances ECS des serveurs d'application sont réparties sur deux zones (Zone B d'Ulanqab et Zone C d'Ulanqab) et desservent le trafic externe en associant directement des adresses IP élastiques (EIP). À mesure que l'activité se développe, ce modèle de déploiement — en raison de ses points d'entrée publics fragmentés — rend difficile l'application de politiques de sécurité et d'audit unifiées, ne répondant plus aux besoins croissants de l'entreprise en matière de contrôle de sécurité centralisé. De plus, ce modèle manque de capacités d'inspection approfondie du trafic, le rendant inefficace face à des cyberattaques de plus en plus sophistiquées.

Pour résoudre ces problèmes, l'entreprise peut déployer GWLB conjointement avec une passerelle IPv4 afin de construire un pare-feu de périmètre Internet hautement disponible. Cette configuration permet une inspection et une gestion centralisées du trafic, réduisant considérablement les risques de sécurité et appliquant des politiques de protection de sécurité cohérentes.

Prérequis

Vous avez créé un VPC métier et un VPC de sécurité, configuré des sous-réseaux métier et des sous-réseaux GWLB dans les zones B et C du VPC métier, et mis en place des sous-réseaux de sécurité dans les zones B et C du VPC de sécurité. Pour plus d'informations, consultez Virtual Private Cloud et vSwitch.
Vous avez créé des instances ECS de serveur d'application dans le VPC métier et y avez déployé des services d'application. Si une instance ECS nécessite une communication sur le réseau public, attribuez-lui une adresse IP publique.
Vous avez créé et activé une passerelle IPv4 pour le VPC métier.
Vous avez créé les tables de routage requises, notamment la table de routage de la passerelle IPv4, les tables de routage des sous-réseaux métier et les tables de routage des sous-réseaux GWLBe.
Vous avez créé au moins deux instances ECS dans le VPC de sécurité pour simuler des appliances réseau virtuelles.

Important
Assurez-vous que les types d'instance ECS dans le VPC de sécurité prennent en charge les trames Jumbo (jumbo frames), car l'encapsulation Geneve ajoute 68 octets au paquet d'origine, ce qui peut dépasser 1 500 octets. Pour plus d'informations, consultez Unité maximale de transmission du réseau et Familles d'instances prenant en charge les trames Jumbo.

Vous avez créé des groupes de sécurité pour toutes les instances ECS dans le VPC métier et le VPC de sécurité. Assurez-vous que le groupe de sécurité des instances ECS dans le VPC de sécurité autorise le trafic UDP sur le port 6081 et permet les ports et protocoles requis pour les vérifications d'état (health checks).

Exemple de référence : planification des blocs CIDR

VPC	Zone	Blocs CIDR et ressources
VPC métier Bloc CIDR principal : 192.168.0.0/16	Zone B	Sous-réseau GWLBe_01 B : 192.168.101.0/24 Sous-réseau métier B : 192.168.1.0/24 Serveur d'application ECS_B_01 (associé à une EIP) : 192.168.1.153 Exemple de référence : déployer un service de test sur ECS_B_01 (utilisant Alibaba Cloud Linux 3) `yum install -y nginx systemctl start nginx.service cd /usr/share/nginx/html/ echo "Hello World ! This is ECS_B_01." > index.html`
VPC métier Bloc CIDR principal : 192.168.0.0/16	Zone C	Sous-réseau GWLBe_02 C : 192.168.102.0/24 Sous-réseau métier C : 192.168.2.0/24 Serveur d'application ECS_C_01 (associé à une EIP) : 192.168.2.151 Exemple de référence : déployer un service de test sur ECS_C_01 (utilisant Alibaba Cloud Linux 3) `yum install -y nginx systemctl start nginx.service cd /usr/share/nginx/html/ echo "Hello World ! This is ECS_C_01." > index.html`
VPC de sécurité Bloc CIDR : 10.0.0.0/16	Zone B	Sous-réseau de sécurité B : 10.0.1.0/24 Appliance réseau virtuelle ECS_01 : 10.0.1.40
VPC de sécurité Bloc CIDR : 10.0.0.0/16	Zone C	Sous-réseau de sécurité C : 10.0.2.0/24 Appliance réseau virtuelle ECS_02 : 10.0.2.170

Procédure

Étape 1 : Configurer Gateway Load Balancer

Créer une instance GWLB

Une instance est une entité de service d'équilibrage de charge. Commencez par créer une instance GWLB.

Dans la barre de menu supérieure de la console Gateway Load Balancer (GWLB), sélectionnez la région où vous souhaitez déployer l'instance GWLB.
Sur la page Instances, cliquez sur Create GWLB.
Sur la page d'achat Gateway Load Balancer, configurez les paramètres de l'instance GWLB, puis cliquez sur Buy Now et suivez les instructions de la console pour finaliser l'activation de l'instance.

Dans ce scénario, définissez Region and zone sur China (Ulanqab), VPC sur le VPC de sécurité que vous avez créé, et Zone sur Ulanqab Zone B et Ulanqab Zone C. Sélectionnez les ID de vSwitch des sous-réseaux de sécurité correspondants dans chaque zone. Utilisez les valeurs par défaut ou ajustez selon vos besoins pour les autres paramètres d'instance GWLB non répertoriés ici.
Revenez à la page Instances et sélectionnez la région appropriée pour afficher votre nouvelle instance.

Créer un groupe de serveurs backend

Créez un groupe de serveurs et ajoutez-y des serveurs backend pour recevoir les requêtes client transférées par GWLB.

Dans le volet de navigation de gauche, choisissez GWLB > Server Group.
Sur la page Server Group, cliquez sur Create Server Group.
Dans la boîte de dialogue Create Server Group, configurez les paramètres du groupe de serveurs, puis cliquez sur Create.

Dans ce scénario, définissez Server Group Type sur Server et VPC sur le VPC de sécurité que vous avez créé (le même VPC que l'instance GWLB). Utilisez les valeurs par défaut ou ajustez selon vos besoins pour les autres paramètres de groupe de serveurs non répertoriés ici.
Dans la boîte de dialogue The server group is created, cliquez sur Add Backend Server.
Dans le panneau Add Backend Server, sélectionnez les instances ECS_01 et ECS_02 que vous avez créées, puis cliquez sur OK.

Configurer les écouteurs

Configurez un écouteur pour l'instance et associez-le au groupe de serveurs backend afin de transférer le trafic sur tous les ports vers les serveurs backend en utilisant le protocole Geneve.

Dans le volet de navigation de gauche, choisissez GWLB et cliquez sur l'ID de l'instance.
Cliquez sur l'onglet Listener, puis cliquez sur Create IP Listener.
Sur la page de configuration Create IP Listener, sélectionnez Server Group Type, choisissez le groupe de serveurs que vous avez créé, puis cliquez sur OK.

Utilisez les valeurs par défaut ou ajustez selon vos besoins pour les autres paramètres d'écouteur IP non répertoriés ici.

Étape 2 : Configurer les appliances réseau virtuelles

Étant donné que GWLB fonctionne en mode transparent au niveau de la couche 3 du modèle OSI, vous devez adapter les appliances réseau virtuelles déployées en backend pour qu'elles puissent recevoir, traiter et renvoyer correctement le trafic encapsulé par Geneve.

Alibaba Cloud GWLB prend en charge l'intégration d'appliances réseau virtuelles tierces (telles que Fortinet et Hillstone) dans le groupe de serveurs backend. Cette rubrique utilise iptables pour simuler une appliance réseau virtuelle backend. Suivez les instructions du fournisseur de votre appareil pour les configurations réelles.

Exemple de référence : configurer iptables sur ECS_01 (utilisant Alibaba Cloud Linux 3)

# Step1: Save the configuration script to a file
cat > setup_gwlb_multi_iptables.sh <<'EOF'
#!/bin/bash
# setup_gwlb_multi_iptables.sh
# For multi-zone GWLB deployments, automatically configures IP forwarding, iptables, and hairpin NAT rules
# ---- 1. Configuration parameters (modify as needed) ----
instance_ip="10.0.1.40" # Private IP of this ECS instance, e.g., ECS_01 in Ulanqab Zone B 
gwlb_ip1="10.0.1.41"   # Private IP of GWLB in Ulanqab Zone B
gwlb_ip2="10.0.2.171"  # Private IP of GWLB in Ulanqab Zone C
# ---- 2. Enable IPv4 forwarding ----
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/00-defaults.conf
sysctl -p /etc/sysctl.d/00-defaults.conf
# ---- 3. Install iptables service ----
yum install iptables-services -y
# ---- 4. Enable and start iptables service ----
systemctl enable iptables
systemctl start iptables
# ---- 5. Set basic iptables policies to accept all traffic (for testing/POC only; restrict as needed in production) ----
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
# ---- 6. Clear all iptables tables and rules ----
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X
# ---- 7. Configure hairpin NAT rules for multi-zone GWLB ----
iptables -t nat -A PREROUTING -p udp -s $gwlb_ip1 -d $instance_ip -i eth0 -j DNAT --to-destination $gwlb_ip1:6081
iptables -t nat -A POSTROUTING -p udp --dport 6081 -s $gwlb_ip1 -d $gwlb_ip1 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p udp -s $gwlb_ip2 -d $instance_ip -i eth0 -j DNAT --to-destination $gwlb_ip2:6081
iptables -t nat -A POSTROUTING -p udp --dport 6081 -s $gwlb_ip2 -d $gwlb_ip2 -o eth0 -j MASQUERADE
# ---- 8. Save iptables rules ----
service iptables save
echo "【Done】ECS $instance_ip has applied NAT and forwarding rules for multi-zone GWLB!"
EOF
# Step2: Make the script executable
chmod +x setup_gwlb_multi_iptables.sh
# Step3: Run immediately
sudo ./setup_gwlb_multi_iptables.sh

Étape 3 : Configurer PrivateLink

Configurer un service de point de terminaison

Exposez l'instance GWLB en tant que ressource de service dans un service de point de terminaison pour permettre l'accès depuis le VPC métier.

Sur la page Endpoint Services, cliquez sur Create Endpoint Service.
Sur la page Create Endpoint Service, configurez les paramètres du service de point de terminaison, puis cliquez sur OK.

Dans ce scénario, définissez Region sur China (Ulanqab), Service Resource Type sur GWLB, Select Service Resource sur Ulanqab Zone B et Ulanqab Zone C, choisissez l'instance GWLB que vous avez créée comme ressource de service, et définissez Automatically Accept Endpoint Connections sur Yes. Utilisez les valeurs par défaut ou ajustez selon vos besoins pour les autres paramètres de service de point de terminaison non répertoriés ici.

Configurer les points de terminaison Gateway Load Balancer

En tant que consommateur de service, créez des instances GWLBe pour vous connecter au service de point de terminaison.

Sur la page Endpoints, cliquez sur l'onglet GWLB Endpoint, puis cliquez sur Create Endpoint.

Sur la page Create Endpoint, configurez les paramètres de GWLBe_01, puis cliquez sur OK.

La configuration pour ce scénario est la suivante. Utilisez les valeurs par défaut ou ajustez selon vos besoins pour les autres paramètres de point de terminaison non répertoriés ici.

Parameter

Description

Region

Cette rubrique sélectionne China (Ulanqab).

Endpoint Name

Saisissez un nom personnalisé pour le point de terminaison.

Endpoint Type

Sélectionnez le type de nœud pour le point de terminaison. Cette rubrique sélectionne GWLB Endpoint.

Type

Cette rubrique sélectionne Select Service et choisit le service de point de terminaison que vous avez créé.

VPC

Sélectionnez le VPC pour le point de terminaison. Cette rubrique sélectionne l'ID du VPC métier.

Zones and vSwitches

Sélectionnez la zone correspondant au service de point de terminaison, puis choisissez un vSwitch dans cette zone. Le système crée automatiquement une interface réseau élastique (ENI) de point de terminaison sous ce vSwitch.

Cette rubrique sélectionne Ulanqab Zone B et l'ID du vSwitch du sous-réseau GWLBe dans la zone B.

Répétez les étapes de création pour créer GWLBe_02. Sélectionnez Ulanqab Zone C et l'ID du vSwitch du sous-réseau GWLBe dans la zone C.

Remarque
Assurez-vous que l'état de la connexion du point de terminaison indique Connected.

Étape 4 : Configurer le routage

Configurez les routes pour diriger le trafic vers GWLBe.

Dans la barre de menu supérieure de la page Route Table, sélectionnez la région de la table de routage.

Dans ce scénario, sélectionnez China (Ulanqab).

Suivez les instructions ci-dessous pour cliquer sur l'ID de chaque table de routage cible et configurer les routes sur la page de détails de la table de routage.

Remarque

Sur la page de détails de la table de routage, sous l'onglet Route Entry List > System Route, vous pouvez afficher les entrées de route système.

Le système ajoute automatiquement les routes système suivantes aux tables de routage personnalisées : les routes dont les blocs CIDR de destination correspondent aux blocs CIDR des vSwitch dans le VPC, permettant la communication entre les ressources cloud au sein de ces vSwitch.

Table de routage de la passerelle IPv4 : la table de routage de la passerelle IPv4 doit contenir des entrées qui acheminent le trafic destiné aux serveurs d'application vers GWLBe.

Sur la page de détails de la table de routage, sous l'onglet Route Entry List > System Route, recherchez les entrées de route système cibles. Dans la colonne Operations, cliquez sur Modify. Dans la boîte de dialogue Modify Route Entry, configurez comme suit, puis cliquez sur OK.

Après configuration, ces entrées de route apparaissent sous l'onglet Custom Route.

Configuration	Entrée de route système avec bloc CIDR de destination 192.168.1.0/24	Entrée de route système avec bloc CIDR de destination 192.168.2.0/24
Next Hop Type	Sélectionnez GWLB Endpoint.
GWLB Endpoint	Sélectionnez le GWLBe_01 existant dans la zone B.	Sélectionnez le GWLBe_02 existant dans la zone C.

Tables de routage des sous-réseaux métier : les tables de routage des sous-réseaux métier doivent contenir des entrées qui acheminent tout le trafic des serveurs d'application vers GWLBe.

Sur les pages de détails des tables de routage des sous-réseaux métier dans les zones B et C d'Ulanqab, accédez à l'onglet Route Entry List > Custom Route et cliquez sur Add Route Entry. Dans la boîte de dialogue Add Route Entry, configurez comme suit, puis cliquez sur OK.

Setting	Table de routage du sous-réseau métier B	Table de routage du sous-réseau métier C
Destination CIDR Block	0.0.0.0/0
Next Hop Type	Sélectionnez GWLB Endpoint.
GWLB Endpoint	Sélectionnez GWLBe_01 dans la zone B.	Sélectionnez le GWLBe_02 que vous avez créé dans la zone C d'Ulanqab.

Tables de routage des sous-réseaux GWLBe : les tables de routage des sous-réseaux GWLBe doivent acheminer le trafic de retour inspecté vers sa destination finale. Pour le trafic provenant d'Internet, les routes locales assurent la livraison aux serveurs d'application. Pour le trafic provenant des serveurs d'application, ajoutez une route qui envoie tout le trafic vers la passerelle IPv4.

Sur les pages de détails des tables de routage des sous-réseaux GWLBe dans les zones B et C d'Ulanqab, accédez à l'onglet Route Entry List > Custom Route et cliquez sur Add Route Entry. Dans la boîte de dialogue Add Route Entry, configurez comme suit, puis cliquez sur OK.

Setting

Table de routage du sous-réseau GWLBe

Destination CIDR Block

0.0.0.0/0

Next Hop Type

Sélectionnez IPv4 Gateway.

IPv4 Gateway

Sélectionnez la passerelle IPv4 que vous avez créée.

Référence de configuration de routage : entrées de route pour la table de routage de la passerelle IPv4, les tables de routage des sous-réseaux métier et les tables de routage des sous-réseaux GWLBe (affichage uniquement des entrées de route personnalisées)

Configuration de la table de routage de la passerelle IPv4

Destination CIDR Block

Next hop

Route entry type

192.168.1.0/24

Point de terminaison Gateway Load Balancer (GWLBe_01)

Entrée de route personnalisée

192.168.2.0/24

Point de terminaison Gateway Load Balancer (GWLBe_02)

Entrée de route personnalisée

Configuration des tables de routage des sous-réseaux métier

Subnet type

Destination CIDR Block

Next hop

Route entry type

Sous-réseau métier B

0.0.0.0/0

Point de terminaison Gateway Load Balancer (GWLBe_01)

Entrée de route personnalisée

Sous-réseau métier C

0.0.0.0/0

Point de terminaison Gateway Load Balancer (GWLBe_02)

Entrée de route personnalisée

Configuration des tables de routage des sous-réseaux GWLBe

Subnet type

Destination CIDR Block

Next hop

Route entry type

Sous-réseau GWLBe B

0.0.0.0/0

Passerelle IPv4

Entrée de route personnalisée

Sous-réseau GWLBe C

0.0.0.0/0

Passerelle IPv4

Entrée de route personnalisée

Étape 5 : Tests de vérification

Connectez-vous à un serveur d'appliance de sécurité et capturez tous les paquets sur le port 6081 en exécutant la commande suivante :

tcpdump -i any port 6081

La sortie affiche les paquets de requête et de réponse des instances ECS du serveur d'application, confirmant que GWLB achemine correctement le trafic vers les appliances réseau virtuelles pour l'inspection de sécurité.

Tester la connectivité du trafic entrant

Depuis n'importe quel client disposant d'un accès Internet, exécutez curl http://<EIP bound to application server ECS_B_01> et curl http://<EIP bound to application server ECS_C_01> pour vérifier l'accès normal à l'application.
```
C:\Users\Administrator>curl http://8.xxx.56/
Hello World ! This is ECS_C_01.
C:\Users\Administrator>curl http://8.xxx.130/
Hello World ! This is ECS_B_01.
```

Sur n'importe quelle instance ECS backend de GWLB, ouvrez une fenêtre de ligne de commande et exécutez tcpdump -i any port 6081 pour capturer tous les paquets sur le port 6081.

Si la sortie affiche un trafic encapsulé en Geneve avec des paquets internes tels que IP <client public IP>.xxxxx > <application ECS private IP>.http ..., cela signifie que GWLB distribue correctement le trafic externe aux appliances de sécurité pour traitement.

10:24:36.525075 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [SEW], seq 2485172945, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:24:36.525098 IP iZ0jlgsxxx .56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [SEW], seq 2485172945, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:24:36.526547 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [S,E], seq 3488689686, ack 2485172946, win 59220, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:24:36.526549 IP iZ0jlgxxx .56736 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [S,E], seq 3488689686, ack 2485172946, win 59220, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:24:36.572545 IP 10.0.1.41.56736 > iZ0jlgxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [.], ack 1, win 255, length 0
10:24:36.572551 IP iZ0jlgs4u5xxx .56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [.], ack 1, win 255, length 0
10:24:36.572552 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [P.], seq 1:77, ack 1, win 255, length 76: HTTP: GET / HTTP/1.1
10:24:36.572554 IP iZ0xxx .56736 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [P.], seq 1:77, ack 1, win 255, length 76: HTTP: GET / HTTP/1.1
10:24:36.622282 IP 10.0.1.41.56736 > iZ0jlgsxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [F.], seq 77, ack 269, win 254, length 0
10:24:36.622288 IP iZ0jlgs4uxxx .56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [F.], seq 77, ack 269, win 254, length 0
10:24:36.623401 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [F.], seq 269, ack 78, win 463, length 0
10:24:36.623481 IP iZ0jlgs4uxxx .56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [F.], seq 269, ack 78, win 463, length 0

Tester la connectivité du trafic sortant

Connectez-vous à n'importe quel serveur d'application et exécutez ping www.aliyun.com pour vérifier l'accès normal à Internet.

[root@iZ0jl xxx xxx ~]# ping www.aliyun.com
PING www.aliyun.com.w.cdngslb.com (124.238.xxx.xxx) 56(84) bytes of data.
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=1 ttl=51 time=17.3 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=2 ttl=51 time=15.1 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=3 ttl=51 time=15.1 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=4 ttl=51 time=14.5 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=5 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=6 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=7 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=8 ttl=51 time=14.4 ms

Sur n'importe quelle instance ECS backend de GWLB, ouvrez une fenêtre de ligne de commande et exécutez tcpdump -i any port 6081 pour capturer tous les paquets sur le port 6081.

La sortie affiche les paquets de requête et de réponse des instances ECS du serveur d'application, confirmant que le trafic sortant des serveurs d'application transite par les appliances réseau virtuelles backend de GWLB pour inspection et transit.

10:15:18.247012 IP 10.0.1.41.32236 > iZ0jlgs xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 8, length 64
10:15:18.247028 IP iZ0jlgs xxx > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 8, length 64
10:15:18.261183 IP 10.0.1.41.32236 > iZ0jlgs xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 8, length 64
10:15:18.261192 IP iZ0jlgs xxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 8, length 64
10:15:19.248397 IP 10.0.1.41.32236 > iZ0jlgs xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 9, length 64
10:15:19.248419 IP iZ0jlg xxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo reply, id 9, seq 9, length 64
10:15:19.262605 IP 10.0.1.41.32236 > iZ0jlg xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo request, id 9, seq 9, length 64
10:15:19.262613 IP iZ0jlg xxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 9, length 64

Références

Aperçu de la facturation GWLB : GWLB utilise une tarification au paiement à l'utilisation. Les coûts incluent les frais d'instance GWLB et les frais LCU.
Facturation PrivateLink : GWLB nécessite GWLBe pour fournir des services. GWLBe est tarifé et facturé indépendamment par le service PrivateLink.
Lors du déploiement de GWLB, activez les fonctionnalités suivantes :
- Vérification d'état GWLB : détecte la disponibilité des appliances réseau virtuelles backend. Si un appareil tombe en panne, les nouvelles requêtes sont automatiquement acheminées vers les appareils backend sains.
- Drainage de connexion : gère en douceur les connexions existantes lors de la suppression d'une appliance réseau virtuelle backend.
- Rééquilibrer le trafic existant : lorsqu'une appliance réseau virtuelle backend tombe en panne ou est supprimée, GWLB réachemine le trafic existant vers les appareils backend sains pour éviter toute interruption de service.
Pour plus d'informations sur PrivateLink et la passerelle IPv4 :
- Qu'est-ce que PrivateLink
- Passerelle IPv4