Héberger ASP.NET Core sur Linux avec Apache

Par Shayne Boyer

À l’aide de ce guide, découvrez comment configurer Apache comme serveur proxy inverse sur CentOS 7 pour rediriger le trafic HTTP vers une application web ASP.NET Core s’exécutant sur le serveur Kestrel. L’extension mod_proxy et les modules associés créent le proxy inverse du serveur.

Attention

Cet article fait référence à CentOS, une distribution Linux qui arrive en fin de vie (EOL). Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d’informations, consultez les conseils d’aide relatifs à la fin de vie de CentOS.

Prérequis

• Serveur exécutant CentOS 7 avec un compte d’utilisateur standard disposant du privilège sudo.
• Installez le runtime .NET Core sur le serveur.
  1. Consultez la page Télécharger .NET Core.
  2. Sélectionnez la dernière version non préliminaire de .NET Core.
  3. Téléchargez le dernier runtime hors version préliminaire dans le tableau sous Exécuter des applications - Runtime.
  4. Sélectionnez le lien Instructions du gestionnaire de package Linux et suivez les instructions relatives à CentOS.
• Une application ASP.NET Core existante.

Puis, à n’importe quel moment après la mise à niveau de l’infrastructure partagée, redémarrez les applications ASP.NET Core hébergées par le serveur.

Publier et copier sur l’application

Configurez l’application pour un déploiement dépendant du framework.

Si l’application est exécutée localement dans l’environnement de développement et n’est pas configurée par le serveur pour établir des connexions HTTPS sécurisées, adoptez l’une des approches suivantes :

• Configurez l’application pour gérer les connexions locales sécurisées. Pour plus d’informations, consultez la section Configuration HTTPS.

• Configurez l’application pour qu’elle s’exécute au niveau du point de terminaison non sécurisé :

  • Désactivez l’intergiciel de redirection HTTPS dans l’environnement de développement (Program.cs) :

    if (!app.Environment.IsDevelopment())
    {
        app.UseHttpsRedirection();
    }
    

    Pour plus d’informations, consultez Utiliser plusieurs environnements dans ASP.NET Core.

  • Supprimez https://localhost:5001 (le cas échéant) de la propriété applicationUrl dans le fichier Properties/launchSettings.json.

Pour plus d’informations sur la configuration selon l’environnement, consultez Utiliser plusieurs environnements dans ASP.NET Core.

Exécutez dotnet publish à partir de l’environnement de développement pour empaqueter une application dans un répertoire (par exemple, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, où l’espace réservé {TARGET FRAMEWORK MONIKER} est le moniker de framework cible (TFM ) exécutable sur le serveur :

dotnet publish --configuration Release

L’application peut également être publiée en tant que déploiement autonome si vous préférez ne pas gérer le runtime .NET Core sur le serveur.

Copiez l’application ASP.NET Core sur le serveur à l’aide d’un outil qui s’intègre au flux de travail de l’organisation (par exemple, SCP ou SFTP). Il est courant de placer les applications web sous le répertoire var (par exemple, var/www/helloapp).

Remarque

Dans un scénario de déploiement en production, un workflow d’intégration continue effectue le travail de publication de l’application et de copie des composants sur le serveur.

Configurer un serveur proxy

Un proxy inverse est une configuration courante pour traiter les applications web dynamiques. Le proxy inverse met fin à la requête HTTP et la transfère à l’application ASP.NET.

Un serveur proxy transfère les requêtes des clients à un autre serveur, au lieu de traiter celles-ci lui-même. Un proxy inverse transfère à une destination fixe, en général pour le compte de clients arbitraires. Dans ce guide, Apache est configuré comme proxy inverse s’exécutant sur le même serveur où Kestrel traite l’application ASP.NET Core.

Les requêtes étant transférées par le proxy inverse, utilisez le middleware (intergiciel) des en-têtes transférés à partir du package Microsoft.AspNetCore.HttpOverrides. Le middleware met à jour le Request.Scheme, à l’aide de l’en-tête X-Forwarded-Proto, afin que les URI de redirection et d’autres stratégies de sécurité fonctionnent correctement.

Tout composant qui dépend du schéma, tel que l’authentification, la génération de lien, les redirections et la géolocalisation, doit être placé après l’appel du middleware des en-têtes transférés.

Le middleware Forwarded Headers doit s’exécuter avant tout autre middleware. Cet ordre permet au middleware qui repose sur les informations des en-têtes transférés d’utiliser les valeurs d’en-tête pour le traitement. Pour exécuter le middleware Forwarded Headers après les middlewares Diagnostics et Error Handling, consultez Ordre du middleware Forwarded Headers.

Appelez la méthode UseForwardedHeaders en haut de Startup.Configure avant d’appeler d’autres intergiciels. Configurez l’intergiciel pour transférer les en-têtes X-Forwarded-For et X-Forwarded-Proto.

Ajoutez l’espace de noms Microsoft.AspNetCore.HttpOverrides en haut du fichier :

using Microsoft.AspNetCore.HttpOverrides;

Dans le pipeline de traitement des applications :

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Si aucune option ForwardedHeadersOptions n’est spécifiée au middleware, les en-têtes par défaut à transférer sont None.

Les serveurs proxy exécutés sur les adresses de bouclage (127.0.0.0/8, [::1]), notamment l’adresse localhost standard (127.0.0.1), sont approuvés par défaut. Si d’autres proxys ou réseaux approuvés au sein de l’organisation gèrent les requêtes entre Internet et le serveur web, ajoutez-les à la liste des KnownProxies ou des KnownNetworks avec ForwardedHeadersOptions. L’exemple suivant ajoute un serveur proxy approuvé avec l’adresse IP 10.0.0.100 au middleware des en-têtes transférés KnownProxies dans Startup.ConfigureServices :

Ajoutez l’espace de noms System.Net en haut du fichier :

using System.Net;

Utilisez l’inscription de service suivante :

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Pour plus d’informations, consultez l’article Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge.

Installer Apache

Mettez à jour les packages CentOS vers leur dernière version stable :

sudo yum update -y

Installez le serveur web Apache sur CentOS avec une seule commande yum :

sudo yum -y install httpd mod_ssl

Exemple de sortie après exécution de la commande :

Downloading packages:
httpd-2.4.6-40.el7.centos.4.x86_64.rpm               | 2.7 MB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 
Verifying  : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 

Installed:
httpd.x86_64 0:2.4.6-40.el7.centos.4

Complete!

Remarque

Dans cet exemple, la sortie correspond à httpd.86_64, car la version de CentOS 7 est en 64 bits. Pour vérifier où Apache est installé, exécutez whereis httpd à partir d’une invite de commandes.

Configurer Apache

Les fichiers de configuration pour Apache se trouvent dans le répertoire /etc/httpd/conf.d/. Dans Apache sur Ubuntu, tous les fichiers de configuration de l’hôte virtuel sont stockés dans /etc/apache2/sites-available. Les fichiers avec l’extension .conf sont traités par ordre alphabétique en plus des fichiers de configuration des modules dans /etc/httpd/conf.modules.d/, qui contient tous les fichiers de configuration nécessaires au chargement des modules.

Créez un fichier de configuration nommé helloapp.conf, pour l’application :

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}s
</VirtualHost>

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5000/
    ServerName www.example.com
    ServerAlias *.example.com
    ErrorLog ${APACHE_LOG_DIR}/helloapp-error.log
    CustomLog ${APACHE_LOG_DIR}/helloapp-access.log common
</VirtualHost>

Remarque : les versions Apache antérieures à 2.4.6 ne nécessitent pas que le RequestHeader set contienne la fin s :

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

Pour plus d’informations, consultez %{VARNAME}s dans Module Apache mod_headers.

Le bloc VirtualHost peut apparaître plusieurs fois, dans un ou plusieurs fichiers sur un serveur. Dans le fichier de configuration précédent, Apache accepte le trafic public sur le port 80. Le domaine www.example.com est pris en charge, et l’alias *.example.com aboutit au même site web. Pour plus d’informations, consultez Prise en charge des hôtes virtuels par nom. Les requêtes sont transmises par proxy à la racine vers le port 5000 du serveur sur 127.0.0.1. Pour la communication bidirectionnelle, ProxyPass et ProxyPassReverse sont requis. Pour changer le port/l’adresse IP de Kestrel, consultez Kestrel : configuration du point de terminaison.

Avertissement

La spécification d’une directive ServerName incorrecte dans le bloc VirtualHost expose votre application à des failles de sécurité. Une liaison générique de sous-domaine (par exemple, *.example.com) ne présente pas ce risque de sécurité si vous contrôlez le domaine parent en entier (par opposition à *.com, qui est vulnérable). Pour plus d’informations, consultez RFC 9110 : Sémantique HTTP (Section 7.2 : Hôte et autorité).

Vous pouvez configurer la journalisation par VirtualHost à l’aide des directives ErrorLog et CustomLog. ErrorLog est l’emplacement où le serveur journalise les erreurs, tandis que CustomLog définit le nom de fichier et le format du fichier journal. Dans ce cas, c’est l’endroit où les informations des requêtes sont journalisées. Il y a une ligne pour chaque requête.

Enregistrez le fichier et testez la configuration. Si tout réussit, la réponse doit être Syntax [OK].

sudo apachectl configtest

Redémarrez Apache :

sudo systemctl restart httpd
sudo systemctl enable httpd

Pour plus d’informations sur les valeurs de directive d’en-tête, consultez Module Apache mod_headers.

Surveiller l’application

Apache est désormais configuré pour transférer les requêtes faites à http://localhost:80 vers l’application ASP.NET Core s’exécutant sur Kestrel à l’adresse http://127.0.0.1:5000. Cependant, Apache n’est pas configuré pour gérer le processus Kestrel. Utilisez systemd pour créer un fichier de service afin de démarrer et surveiller l’application web sous-jacente. systemd est un système d’initialisation qui fournit de nombreuses et puissantes fonctionnalités pour le démarrage, l’arrêt et la gestion des processus.

Créer le fichier de service

Créez le fichier de définition de service :

sudo nano /etc/systemd/system/kestrel-helloapp.service

Exemple de fichier de service pour l’application :

[Unit]
Description=Example .NET Web API App running on CentOS 7

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/local/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Production 

[Install]
WantedBy=multi-user.target

Remarque : Définissez le dossier local/bin de votre distribution. Certaines versions d’Ubuntu nécessitent ExecStart=/usr/bin/dotnet

Dans l’exemple précédent, l’utilisateur qui gère le service est spécifié par l’option User. L’utilisateur (apache) doit exister et être le propriétaire légitime des fichiers de l’application.

Utilisez TimeoutStopSec pour configurer la durée d’attente de l’arrêt de l’application après la réception du signal d’interruption initial. Si l’application ne s’arrête pas pendant cette période, le signal SIGKILL est émis pour mettre fin à l’application. Indiquez la valeur en secondes sans unité (par exemple, 150), une valeur d’intervalle de temps (par exemple, 2min 30s) ou infinity pour désactiver le délai d’attente. TimeoutStopSec prend la valeur par défaut de DefaultTimeoutStopSec dans le fichier de configuration du gestionnaire (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Le délai d’expiration par défaut pour la plupart des distributions est de 90 secondes.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Certaines valeurs (par exemple, les chaînes de connexion SQL) doivent être placées dans une séquence d’échappement afin que les fournisseurs de configuration puissent lire les variables d’environnement. Utilisez la commande suivante pour générer une valeur correctement placée dans une séquence d’échappement en vue de son utilisation dans le fichier de configuration :

systemd-escape "<value-to-escape>"

Les séparateurs : (signe deux-points) ne sont pas pris en charge dans les noms de variables d’environnement. Utilisez un double trait de soulignement (__) à la place d’un signe deux-points. Le fournisseur de configuration de variables d’environnement convertit les doubles traits de soulignement en signes deux-points quand les variables d’environnement sont lues dans la configuration. Dans l’exemple suivant, la clé de chaîne de connexion ConnectionStrings:DefaultConnection est définie dans le fichier de définition de service en tant que ConnectionStrings__DefaultConnection :

Environment=ConnectionStrings__DefaultConnection={Connection String}

Enregistrez le fichier et activez le service :

sudo systemctl enable kestrel-helloapp.service

Démarrez le service et vérifiez qu’il s’exécute :

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on CentOS 7
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Le proxy inverse étant configuré et Kestrel étant géré via systemd, l’application web est maintenant entièrement configurée et accessible à partir d’un navigateur sur la machine locale à l’adresse http://localhost. Comme l’indiquent les en-têtes de réponse, l’en-tête Server montre que l’application ASP.NET Core est traitée par Kestrel :

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Afficher les journaux d’activité

Puisque l’application web utilisant Kestrel est gérée à l’aide de systemd, les processus et les événements sont enregistrés dans un journal centralisé. Cependant, ce journal comprend les entrées de tous les services et processus gérés par systemd. Pour afficher les éléments propres à kestrel-helloapp.service, utilisez la commande suivante :

sudo journalctl -fu kestrel-helloapp.service

Pour le filtrage du temps, spécifiez les options appropriées dans la commande. Par exemple, utilisez --since today pour filtrer en fonction du jour actuel ou --until 1 hour ago pour voir les entrées de l’heure précédente. Pour plus d’informations, consultez la page man pour journalctl.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Protection des données

La pile de protection des données ASP.NET Core est utilisée par plusieurs intergiciels ASP.NET Core, notamment des intergiciels d’authentification (par exemple, l’intergiciel cookie) et les protections contre la falsification de requête intersites (CSRF, Cross Site Request Forgery). Même si les API de protection des données ne sont pas appelées par le code de l’utilisateur, la protection des données doit être configurée pour créer un magasin de clés de chiffrement persistantes. Si la protection des données n’est pas configurée, les clés sont conservées en mémoire et ignorées au redémarrage de l’application.

Si le Key Ring est stocké en mémoire, au redémarrage de l’application :

• Tous les jetons d’authentification basés sur cookie sont invalidés.
• Les utilisateurs doivent se reconnecter pour envoyer leur prochaine demande.
• toutes les données protégées par le Key Ring ne peuvent plus être déchiffrées. Cela peut inclure les jetons CSRF et les cookies ASP.NET Core MVC TempData.

Pour configurer la protection des données de façon à conserver et chiffrer le porte-clés (Key Ring), consultez :

• Fournisseurs de stockage de clé dans ASP.NET Core
• Chiffrement de clé au repos dans Windows et Azure à l’aide de ASP.NET Core

Sécuriser l’application

Configurer le pare-feu

Firewalld est un démon dynamique pour gérer le pare-feu avec prise en charge des zones réseau. Les ports et le filtrage des paquets peuvent toujours être gérés par iptables. Firewalld doit être installé par défaut. Vous pouvez utiliser yum pour installer le package ou vérifier qu’il est installé.

sudo yum install firewalld -y

Utilisez firewalld pour ouvrir seulement les ports nécessaires à l’application. Dans ce cas, les ports 80 et 443 sont utilisés. Les commandes suivantes définissent l’ouverture des ports 80 et 443 de façon permanente :

sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent

Rechargez les paramètres du pare-feu. Vérifiez les services et les ports disponibles dans la zone par défaut. Vous voyez les options disponibles en examinant le résultat de firewall-cmd -h.

sudo firewall-cmd --reload
sudo firewall-cmd --list-all

public (default, active)
interfaces: eth0
sources: 
services: dhcpv6-client
ports: 443/tcp 80/tcp
masquerade: no
forward-ports: 
icmp-blocks: 
rich rules: 

Configuration HTTPS

Configurer l’application pour les connexions locales sécurisées (HTTPS)

La commande dotnet run utilise le fichier Properties/launchSettings.json de l’application, qui configure l’application pour l’écoute sur les URL fournies par la propriété applicationUrl (par exemple https://localhost:5001;http://localhost:5000).

Configurez l’application pour utiliser un certificat en développement pour la commande dotnet run ou l’environnement de développement (F5 ou Ctrl+F5 dans Visual Studio Code) en adoptant l’une de ces approches :

• Remplacer le certificat par défaut dans la configuration (recommandé)
• KestrelServerOptions.ConfigureHttpsDefaults

Configurer le proxy inverse pour les connexions clientes sécurisées (HTTPS)

Avertissement

La configuration de sécurité présentée dans cette section est une configuration générale qu’il convient d’utiliser comme point de départ pour plus de personnalisation. Nous ne pouvons pas fournir de support pour les outils, serveurs et systèmes d’exploitation tiers. L’utilisation de la configuration présentée dans cette section est à vos propres risques. Pour plus d’informations, accédez aux ressources suivantes :

• Chiffrement Apache SSL/TLS (documentation Apache)
• Générateur de configuration SSL mozilla.org

Pour configurer Apache pour HTTPS, vous utilisez le module mod_ssl. Le module mod_ssl a été installé parallèlement au module httpd. S’il n’a pas été installé, utilisez yum pour l’ajouter à la configuration.

sudo yum install mod_ssl

Pour mettre en œuvre HTTPS, installez le module mod_rewrite afin de permettre la réécriture d’URL :

sudo yum install mod_rewrite

Modifiez le fichier helloapp.conf pour sécuriser les communications sur le port 443.

L’exemple suivant ne configure pas le serveur pour rediriger les requêtes non sécurisées. Nous vous recommandons d’utiliser l’intergiciel de redirection HTTPS. Pour plus d’informations, consultez Appliquer HTTPS dans ASP.NET Core.

Remarque

Pour les environnements de développement où la configuration du serveur gère la redirection sécurisée à la place de l’intergiciel de redirection HTTPS, nous vous recommandons d’utiliser des redirections temporaires (302) plutôt que des redirections permanentes (301). La mise en cache des liens peut entraîner un comportement instable dans les environnements de développement.

L’ajout d’un en-tête Strict-Transport-Security (HSTS) garantit que toutes les demandes ultérieures du client s’effectuent par le biais du protocole HTTPS. Pour obtenir des conseils sur la définition de l’en-têteStrict-Transport-Security, consultez Appliquer HTTPS dans ASP.NET Core.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:443>
    Protocols             h2 http/1.1
    ProxyPreserveHost     On
    ProxyPass             / http://127.0.0.1:5000/
    ProxyPassReverse      / http://127.0.0.1:5000/
    ErrorLog              /var/log/httpd/helloapp-error.log
    CustomLog             /var/log/httpd/helloapp-access.log common
    SSLEngine             on
    SSLProtocol           all -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder   off
    SSLCompression        off
    SSLSessionTickets     on
    SSLUseStapling        off
    SSLCertificateFile    /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
    SSLCipherSuite        ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
</VirtualHost>

Remarque

Cet exemple utilise un certificat généré localement. SSLCertificateFile doit être le fichier de certificat principal pour le nom de domaine. SSLCertificateKeyFile doit être le fichier de clé généré quand la demande de signature de certificat est créée. SSLCertificateChainFile doit être le fichier de certificat intermédiaire (le cas échéant) qui a été fourni par l’autorité de certification.

Apache HTTP Server version 2.4.43 ou ultérieure est nécessaire pour utiliser un serveur web TLS 1.3 avec OpenSSL 1.1.1.

Remarque

L’exemple précédent désactive l’agrafage OCSP (Online Certificate Status Protocol). Pour plus d’informations et d’aide sur l’activation d’OCSP, consultez Agrafage OCSP (documentation Apache).

Enregistrez le fichier et testez la configuration :

sudo service httpd configtest

Redémarrez Apache :

sudo systemctl restart httpd

Autres suggestions pour Apache

Redémarrer des applications avec des mises à jour d’infrastructure partagée

Après la mise à niveau de l’infrastructure partagée sur le serveur, redémarrez les applications ASP.NET Core hébergées par le serveur.

En-têtes supplémentaires

Afin d’assurer une protection contre les attaques malveillantes, vous devez modifier ou ajouter quelques en-têtes. Vérifiez que le module mod_headers est installé :

sudo yum install mod_headers

Sécuriser Apache contre les attaques par détournement de clic

Le détournement de clic, également appelé UI redress attack, est une attaque malveillante qui amène le visiteur d’un site web à cliquer sur un lien ou un bouton sur une page différente de celle qu’il est en train de visiter. Utilisez X-FRAME-OPTIONS pour sécuriser le site.

Pour atténuer les attaques par détournement de clic :

1. Modifiez le fichier httpd.conf :

   sudo nano /etc/httpd/conf/httpd.conf
   

   Ajoutez la ligne Header append X-FRAME-OPTIONS "SAMEORIGIN".

2. Enregistrez le fichier.

3. Redémarrez Apache.

Détection de type MIME

L’en-tête X-Content-Type-Options empêche Internet Explorer d’effectuer une détection de données MIME (détermination du Content-Type d’un fichier à partir de son contenu). Si le serveur définit l’en-tête Content-Type sur text/html et que l’option nosniff est définie, Internet Explorer restitue le contenu en tant que text/html, quel que soit le contenu du fichier.

Modifiez le fichier httpd.conf :

sudo nano /etc/httpd/conf/httpd.conf

Ajoutez la ligne Header set X-Content-Type-Options "nosniff". Enregistrez le fichier. Redémarrez Apache.

Équilibrage de la charge.

Cet exemple montre comment installer et configurer Apache sur CentOS 7 et Kestrel sur la même machine de l’instance. Afin de multiplier les instances en cas de défaillance, l’utilisation de mod_proxy_balancer et la modification du VirtualHost permettent de gérer plusieurs instances des applications web derrière le serveur proxy Apache.

sudo yum install mod_proxy_balancer

Dans le fichier de configuration illustré ci-dessous, une instance supplémentaire de helloapp est configurée pour s’exécuter sur le port 5001. La section Proxy est définie avec une configuration d’équilibreur qui comprend deux membres pour équilibrer la charge selon la méthode byrequests.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
    ProxyPass / balancer://mycluster/ 

    ProxyPassReverse / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5001/

    <Proxy balancer://mycluster>
        BalancerMember http://127.0.0.1:5000
        BalancerMember http://127.0.0.1:5001 
        ProxySet lbmethod=byrequests
    </Proxy>

    <Location />
        SetHandler balancer
    </Location>
    ErrorLog /var/log/httpd/helloapp-error.log
    CustomLog /var/log/httpd/helloapp-access.log common
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!RC4
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>

Limites du débit

Vous pouvez utiliser mod_ratelimit, qui est inclus dans le module httpd, pour limiter la bande passante des clients :

sudo nano /etc/httpd/conf.d/ratelimit.conf

L’exemple de fichier limite la bande passante à 600 Ko/s sous l’emplacement racine :

<IfModule mod_ratelimit.c>
    <Location />
        SetOutputFilter RATE_LIMIT
        SetEnv rate-limit 600
    </Location>
</IfModule>

Longs champs d'en-tête de demande

Les paramètres par défaut du serveur proxy limitent généralement les champs d’en-tête de requête à 8 190 octets. Une application peut nécessiter des champs plus longs que la valeur par défaut (par exemple, les applications qui utilisent Microsoft Entra ID). Si des champs plus longs sont requis, il faudra modifier la directive LimitRequestFieldSize du serveur proxy. La valeur à appliquer dépend du scénario. Pour plus d'informations, voir la documentation du serveur.

Avertissement

N’augmentez pas la valeur par défaut de LimitRequestFieldSize à moins que ce ne soit nécessaire. Son augmentation augmente le risque de dépassement de mémoire tampon (dépassement de capacité) et d’attaques par déni de service (DoS) par des utilisateurs malveillants.

Ressources supplémentaires

• Prérequis pour .NET Core sur Linux
• Résoudre les problèmes et effectuer le débogage des projets ASP.NET Core
• Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge