Vue d’ensemble du proxy TCP/TLS d’Application Gateway (préversion)
Outre les fonctionnalités existantes de couche 7 (HTTP, HTTPS, WebSockets et HTTP/2), Azure Application Gateway prend désormais en charge le proxy de couche 4 (protocole TCP) et TLS (Transport Layer Security). Cette fonctionnalité est actuellement disponible en préversion publique. Pour avoir un aperçu de cette fonctionnalité, consultez S’inscrire à la préversion.
Fonctionnalités du proxy TLS/TCP sur Application Gateway
En tant que service proxy inverse, les opérations de couche 4 d’Application Gateway fonctionnent comme ses opérations de proxy de couche 7. Un client établit une connexion TCP avec Application Gateway et Application Gateway lui-même lance une nouvelle connexion TCP à un serveur principal à partir du pool principal. La figure suivante montre l’opération classique.
Flux de processus :
- Un client lance une connexion TCP ou TLS avec la passerelle applicative à l’aide de l’adresse IP et du numéro de port de son écouteur front-end. Cela établit la connexion front-end. Une fois la connexion établie, le client envoie une requête à l’aide du protocole de couche d’application requis.
- La passerelle applicative établit une nouvelle connexion avec l’une des cibles principales du pool principal associé (formant la connexion back-end) et envoie la requête du client à ce serveur principal.
- La réponse du serveur principal est renvoyée au client par la passerelle applicative.
- La même connexion TCP frontale est utilisée pour les requêtes suivantes du client, sauf si le délai d’inactivité TCP ferme cette connexion.
Comparatif entre Azure Load Balancer et Azure Application Gateway :
| Produit | Type |
|---|---|
| Équilibrage de charge Azure | Équilibreur de charge direct où un client établit directement une connexion avec un serveur back-end sélectionné par l’algorithme de distribution de Load Balancer. |
| Application Gateway Azure | Fin de l’équilibreur de charge où un client établit directement une connexion avec Application Gateway et une connexion distincte est lancée avec un serveur back-end sélectionné par l’algorithme de distribution d’Application Gateway. |
Fonctionnalités
- Utilisez un point de terminaison unique (adresse IP front-end) pour traiter des charges de travail HTTP et non-HTTP. Le même déploiement de passerelle applicative peut prendre en charge les protocoles de couche 7 et 4 : HTTP(S), TCP ou TLS. Tous vos clients peuvent se connecter au même point de terminaison et accéder à différentes applications principales.
- Utilisez un domaine personnalisé pour faire face à n’importe quel service principal. Avec le front-end pour la référence SKU Application Gateway V2 en tant qu’adresses IP publiques et privées, vous pouvez configurer n’importe quel nom de domaine personnalisé pour pointer son adresse IP à l’aide d’un enregistrement d’adresse (A). En outre, avec la terminaison TLS et la prise en charge des certificats d’une autorité de certification privée, vous pouvez garantir une connexion sécurisée sur le domaine de votre choix.
- Utilisez un serveur principal à partir de n’importe quel emplacement (Azure ou local). Les back-ends de la passerelle applicative peuvent être les suivants :
- Ressources Azure telles que des machines virtuelles IaaS, des groupes de machines virtuelles identiques ou PaaS (App Services, Event Hubs, SQL)
- Ressources distantes telles que les serveurs locaux accessibles via un nom de domaine complet ou des adresses IP
- Pris en charge pour une passerelle privée uniquement. Avec la prise en charge du proxy TCP et TLS pour les déploiements d’Application Gateway privés, vous pouvez prendre en charge les clients HTTP et non-HTTP dans un environnement isolé pour une sécurité renforcée.
Limites
- Une passerelle de référence SKU WAF v2 permet la création de back-ends et d’écouteurs TCP ou TLS pour prendre en charge le trafic HTTP et non-HTTP via la même ressource. Toutefois, elle n’inspecte pas le trafic sur les écouteurs TLS et TCP pour les codes malveillants exploitant une faille de sécurité et les vulnérabilités.
- La valeur de délai d’expiration du drainage par défaut pour les serveurs principaux est de 30 secondes. Les valeurs de drainage définies par l’utilisateur ne sont actuellement pas prises en charge.
- La préservation de l’adresse IP du client n’est actuellement pas prise en charge.