Intégrer un pare-feu Azure avec Azure Standard Load Balancer

Vous pouvez intégrer un pare-feu Azure à un réseau virtuel avec Azure Standard Load Balancer (public ou interne).

La conception préconisée est d’intégrer un équilibreur de charge interne à votre pare-feu Azure, car il s’agit d’une conception plus simple. Vous pouvez utiliser un équilibreur de charge public si vous en avez déjà un de déployé et que vous souhaitez le conserver. Toutefois, vous devez être conscient d’un problème de routage asymétrique qui peut interrompre la fonctionnalité avec le scénario d’équilibreur de charge public.

Pour plus d’informations sur Azure Load Balancer, consultez Qu’est-ce qu’Azure Load Balancer ?.

Équilibreur de charge public

Avec un équilibreur de charge public, l’équilibreur de charge est déployé avec une adresse IP publique front-end.

Routage asymétrique

Le routage asymétrique signifie qu’un paquet suit un chemin jusqu’à la destination et en suit un autre lors du retour à la source. Ce problème se produit quand un sous-réseau dispose d’une route par défaut jusqu’à l’adresse IP privée du pare-feu et que vous utilisez un équilibreur de charge public. Dans ce cas, le trafic d’équilibreur de charge entrant est reçu par le biais de son adresse IP publique, mais le chemin de retour passe par l’adresse IP privée du pare-feu. Le pare-feu étant avec état, il supprime le paquet de retour, car le pare-feu n’a pas connaissance de l’établissement d’une session de ce type.

Résoudre le problème de routage

Quand vous déployez un pare-feu Azure sur un sous-réseau, l’une des étapes consiste à créer une route par défaut pour le sous-réseau, dirigeant les paquets via l’adresse IP privée du pare-feu située sur le sous-réseau du pare-feu Azure. Pour plus d’informations, consultez Didacticiel : Déployer et configurer un pare-feu Azure à l’aide du portail Azure

Quand vous introduisez le pare-feu dans votre scénario d’équilibreur de charge, vous souhaitez que votre trafic Internet entre par le biais de l’adresse IP de votre pare-feu. À partir de là, le pare-feu applique ses règles et dirige les paquets (grâce à la traduction d’adresses réseau) vers l’adresse IP publique de votre équilibreur de charge. C’est là que le problème se produit. Les paquets arrivent sur l’adresse IP publique du pare-feu, mais retournent vers le pare-feu par le biais de l’adresse IP privée (à l’aide de la route par défaut). Pour éviter ce problème, créez une route d’hôte supplémentaire pour l’adresse IP publique du pare-feu. Les paquets accédant à l’adresse IP publique du pare-feu sont routés via Internet. Cela évite de suivre la route par défaut jusqu’à l’adresse IP privée du pare-feu.

Exemple de table de route

Par exemple, les routes suivantes sont destinées à un pare-feu à l’adresse IP publique 203.0.113.136 et à l’adresse IP privée 10.0.1.4.

Exemple de règle NAT

Dans l’exemple suivant, une règle NAT traduit le trafic RDP vers le pare-feu à l’adresse 203.0.113.136 vers l’équilibreur de charge à l’adresse 203.0.113.220 :

Sondes d’intégrité

N’oubliez pas que vous devez disposer d’un service web en cours d’exécution sur les hôtes du pool de l’équilibreur de charge si vous utilisez des sondes d’intégrité TCP pour le port 80 ou des sondes HTTP/HTTPS.

Équilibreur de charge interne

Avec un équilibreur de charge interne, l’équilibreur de charge est déployé avec une adresse IP privée front-end.

Il n’y a aucun problème de routage asymétrique avec ce scénario. Les paquets entrants arrivent à l’adresse IP publique du pare-feu, subissent une traduction vers l’adresse IP privée de l’équilibreur de charge, puis retournent à l’adresse IP privée du pare-feu en suivant le même chemin de retour.

Ainsi, vous pouvez déployer ce scénario de la même manière que le scénario d’équilibreur de charge public, mais sans avoir besoin de la route hôte de l’adresse IP publique du pare-feu.

Les machines virtuelles du pool de back-ends peuvent disposer d’une connectivité Internet sortante via le pare-feu Azure. Configurez une route définie par l’utilisateur sur le sous-réseau de la machine virtuelle avec le pare-feu comme tronçon suivant.

Sécurité supplémentaire

Pour améliorer la sécurité de votre scénario d’équilibreur de charge, vous pouvez utiliser des groupes de sécurité réseau (NSG).

Vous pouvez par exemple créer un groupe de sécurité réseau sur le sous-réseau back-end où se trouvent les machines virtuelles à charge équilibrée. Autorisez le trafic entrant en provenance de l’adresse IP/du port du pare-feu.

Pour plus d’informations sur les groupes de sécurité réseau, consultez Groupes de sécurité.

Étapes suivantes

• Découvrez comment déployer et configurer un Pare-feu Azure.