Partage via


Quand utiliser Kestrel avec un proxy inverse

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 8 de cet article.

Avertissement

Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la Stratégie de prise en charge de .NET et .NET Core. Pour la version actuelle, consultez la version .NET 8 de cet article.

Important

Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Pour la version actuelle, consultez la version .NET 8 de cet article.

Kestrel peut être utilisé par lui-même ou avec un serveur proxy inverse. Un serveur proxy inverse reçoit les requêtes HTTP en provenance du réseau et les transfère à Kestrel. Voici quelques exemples de serveur proxy inverse :

Kestrel utilisé comme serveur web edge (accessible sur Internet) :

Kestrel communique directement avec Internet sans serveur proxy inverse

Kestrel utilisé dans une configuration de proxy inverse :

Kestrel communique indirectement avec Internet via un serveur proxy inverse, par exemple IIS, Nginx ou Apache

Les deux configurations, avec ou sans serveur proxy inverse, sont des configurations d’hébergement prises en charge.

Quand Kestrel est utilisé comme serveur edge sans serveur proxy inverse, le partage de la même adresse IP et du même port entre plusieurs processus n’est pas pris en charge. Quand Kestrel est configuré pour écouter sur un port, Kestrel gère tout le trafic pour ce port, quel que soit les en-têtes Host des requêtes. Un proxy inverse qui peut partager des ports peut transférer les requêtes à Kestrelsur une adresse IP et un port uniques.

Même si un serveur proxy inverse n’est pas nécessaire, en utiliser un peut être un bon choix.

Un proxy inverse :

  • Peut limiter la surface publique exposée des applications qu’il héberge.
  • Fournit une couche supplémentaire de configuration et de cybersécurité (défense en profondeur).
  • Peut mieux s’intégrer à l’infrastructure existante.
  • Simplifie la configuration de l’équilibrage de charge et d’une communication sécurisée (HTTPS). Seul le serveur proxy inverse nécessite le certificat X.509 pour le ou les domaines publics. Ce serveur peut communiquer avec les serveurs de l’application sur le réseau interne à l’aide du protocole HTTP ou HTTPS brut avec des certificats gérés localement. Le protocole HTTPS interne augmente la sécurité, mais ajoute une surcharge significative.

Avertissement

L’hébergement dans une configuration de proxy inverse nécessite le filtrage d’hôte.

Ressources supplémentaires

Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge