Hospedar ASP.NET Core en Linux con Apache

Por Shayne Boyer

Mediante esta guía, aprenda a configurar Apache como servidor proxy inverso en CentOS 7 para redirigir el tráfico HTTP a una aplicación web ASP.NET Core que se ejecuta en el servidor Kestrel. La extensión mod_proxy y los módulos relacionados crean el proxy inverso del servidor.

Precaución

En este artículo se hace referencia a CentOS, una distribución de Linux que está cerca del estado Fin de vida (EOL). Tenga en cuenta su uso y planifique en consecuencia. Para obtener más información, consulte la Guía de fin de ciclo de vida de CentOS.

Requisitos previos

• Servidor que ejecute CentOS 7, con una cuenta de usuario estándar con privilegios sudo.
• Tener .NET Core Runtime instalado en el servidor.
  1. Visite la página Descargar .NET Core.
  2. Seleccione la versión más reciente de .NET Core que no sea de versión preliminar.
  3. Descargue el runtime más reciente que no sea de versión preliminar en la tabla en Ejecutar aplicaciones: runtime.
  4. Seleccione el vínculo Instrucciones del administrador de paquetes de Linux y siga las instrucciones de CentOS.
• Disponer de una aplicación de ASP.NET Core existente.

En cualquier momento futuro tras actualizar el marco de trabajo compartido, reinicie las aplicaciones ASP.NET Core que hospeda el servidor.

Publicar y copiar en la aplicación

Configure la aplicación para una implementación dependiente de Framework.

Si la aplicación se ejecuta localmente en el entorno de desarrollo y no está configurada para realizar conexiones HTTPS seguras, adopte cualquiera de los enfoques siguientes:

• Configure la aplicación para controlar las conexiones locales seguras. Para obtener más información, vea la sección Configuración de HTTPS.

• Configure la aplicación para que se ejecute en el punto de conexión no seguro:

  • Desactive el middleware de redireccionamiento HTTPS en el entorno de desarrollo (Program.cs):

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

    Para obtener más información, consulte Usar varios entornos en ASP.NET Core.

  • Quite https://localhost:5001 (si existe) de la propiedad applicationUrl en el archivo Properties/launchSettings.json.

Para más información sobre la configuración por entorno, vea Uso de varios entornos en ASP.NET Core.

Ejecute dotnet publish desde el entorno de desarrollo para empaquetar una aplicación en un directorio (por ejemplo, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, donde el marcador de posición {TARGET FRAMEWORK MONIKER} es el moniker de la plataforma de destino (TFM)) que se pueda ejecutar en el servidor:

dotnet publish --configuration Release

La aplicación también se puede publicar como una implementación independiente si prefiere no mantener .NET Core Runtime en el servidor.

Copie la aplicación de ASP.NET Core en el servidor usando una herramienta que se integre en el flujo de trabajo de la organización (como SCP o SFTP). Es habitual encontrar las aplicaciones web en el directorio var (por ejemplo, var/www/helloapp).

Nota

En un escenario de implementación de producción, un flujo de trabajo de integración continua lleva a cabo la tarea de publicar la aplicación y copiar los recursos en el servidor.

Configurar un servidor proxy

Un proxy inverso es una configuración común para trabajar con aplicaciones web dinámicas. El proxy inverso finaliza la solicitud HTTP y la reenvía a la aplicación ASP.NET.

Un servidor proxy reenvía las solicitudes de los clientes a otro servidor en lugar de realizarlas este. Los proxies inversos las reenvían a un destino fijo, normalmente en nombre de clientes arbitrarios. En esta guía, Apache se configura como proxy inverso que se ejecuta en el mismo servidor en el que Kestrel atiende la aplicación ASP.NET Core.

Como el proxy inverso reenvía las solicitudes, use el Middleware de encabezados reenviados del paquete Microsoft.AspNetCore.HttpOverrides. El middleware actualiza Request.Scheme, mediante el encabezado X-Forwarded-Proto, para que los URI de redireccionamiento y otras directivas de seguridad funcionen correctamente.

Cualquier componente que dependa del esquema (como la autenticación, la generación de vínculos, los redireccionamientos o la geolocalización) debe colocarse después de invocar al Middleware de encabezados reenviados.

El middleware de encabezados reenviados debe ejecutarse antes de otro middleware. Hacerlo en ese orden garantiza que el middleware que se basa en la información de encabezados reenviados pueda usar los valores de encabezado para procesarlos. Para ejecutar el middleware de encabezados reenviados después del middleware de diagnóstico y control de errores, vea Orden del middleware de encabezados reenviados.

Invoque el método UseForwardedHeaders que está al principio de Startup.Configure antes de llamar a otro middleware. Configure el middleware para reenviar los encabezados X-Forwarded-For y X-Forwarded-Proto.

Agregue el espacio de nombres Microsoft.AspNetCore.HttpOverrides al principio del archivo:

using Microsoft.AspNetCore.HttpOverrides;

En la canalización de procesamiento de aplicaciones:

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

app.UseAuthentication();

Si no se especifica ningún valor ForwardedHeadersOptions para el middleware, los encabezados predeterminados para reenviar son None.

Los servidores proxy que se ejecutan en direcciones de bucle invertido (127.0.0.0/8, [::1]), incluida la dirección de localhost estándar 127.0.0.1, son de confianza de forma predeterminada. Si otras redes o servidores proxy de confianza de la organización tramitan solicitudes entre Internet y el servidor web, agréguelos a la lista de KnownProxies o KnownNetworks con ForwardedHeadersOptions. En el ejemplo siguiente se agrega un servidor proxy de confianza en la dirección IP 10.0.0.100 al middleware de encabezados reenviados KnownProxies en Startup.ConfigureServices:

Agregue el espacio de nombres System.Net al principio del archivo:

using System.Net;

Use el siguiente registro de servicio:

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

Para obtener más información, consulte Configuración de ASP.NET Core para trabajar con servidores proxy y equilibradores de carga.

Instalar Apache

Actualice los paquetes de CentOS a sus versiones estables más recientes:

sudo yum update -y

Instale el servidor web de Apache en CentOS con un único comando yum:

sudo yum -y install httpd mod_ssl

Salida de ejemplo después de ejecutar el comando:

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!

Nota

En este ejemplo, la salida refleja httpd.86_64, puesto que la versión de CentOS 7 es de 64 bits. Para comprobar dónde está instalado Apache, ejecute whereis httpd desde un símbolo del sistema.

Configurar Apache

Los archivos de configuración de Apache se encuentran en el directorio /etc/httpd/conf.d/. En Apache en Ubuntu, todos los archivos de configuración del host virtual se almacenan en /etc/apache2/sites-available. Todos los archivos que tengan la extensión .conf se procesan en orden alfabético, además de los archivos de configuración del módulo de /etc/httpd/conf.modules.d/, que contiene todos los archivos de configuración necesarios para cargar los módulos.

Cree un archivo de configuración denominado helloapp.conf para la aplicación:

<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>

Nota: las versiones de Apache anteriores a la versión 2.4.6 no requieren que RequestHeader set contenga el elemento final s:

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

Para obtener más información, consulte %{VARNAME}s en Módulo Apache mod_headers.

El bloque VirtualHost puede aparecer varias veces en uno o varios archivos en un servidor. En el archivo de configuración anterior, Apache acepta tráfico público en el puerto 80. El dominio www.example.com se atiende y el alias *.example.com se resuelve en el mismo sitio web. Para obtener más información, vea este artículo sobre la compatibilidad con host virtuales basados en nombres. Las solicitudes se redirigen mediante proxy en la raíz al puerto 5000 del servidor en 127.0.0.1. Para la comunicación bidireccional, se requieren ProxyPass y ProxyPassReverse. Para cambiar la IP o el puerto de Kestrel, consulte Kestrel: configuración de punto de conexión.

Advertencia

Si no se especifica una directiva de ServerName correcta en VirtualHost, el bloque expone la aplicación a las vulnerabilidades de seguridad. Los enlaces de carácter comodín de subdominio (por ejemplo, *.example.com) no presentan este riesgo de seguridad si se controla todo el dominio primario (a diferencia de *.com, que sí es vulnerable). Para obtener más información, consulte RFC 9110: Semántica HTTP (Sección 7.2: Host y :authority).

El registro se puede configurar por VirtualHost con las directivas ErrorLog y CustomLog. ErrorLog es la ubicación donde el servidor registra los errores, y CustomLog establece el nombre de archivo y el formato del archivo de registro. En este caso, aquí es donde se registra la información de la solicitud. Hay una línea para cada solicitud.

Guarde el archivo y pruebe la configuración. Si se pasa todo, la respuesta debe ser Syntax [OK].

sudo apachectl configtest

Reinicie Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

Para más información sobre los valores de directiva de encabezado, consulte Mod_headers de módulos de Apache.

Supervisión de la aplicación

Ahora Apache está configurado para reenviar las solicitudes efectuadas a http://localhost:80 a la aplicación ASP.NET Core que se ejecuta en Kestrel en http://127.0.0.1:5000. En cambio, Apache no está configurado para administrar el proceso de Kestrel. Use systemd y cree un archivo de servicio para iniciar y supervisar la aplicación web subyacente. systemd es un sistema de inicio que proporciona muchas características eficaces para iniciar, detener y administrar procesos.

Crear el archivo de servicio

Cree el archivo de definición de servicio:

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

Un archivo de servicio de ejemplo para la aplicación:

[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

Nota: Establezca la carpeta local/bin relativa a su distribución. Algunas versiones de Ubuntu requieren ExecStart=/usr/bin/dotnet .

En el ejemplo anterior, el usuario que administra el servicio se especifica mediante la opción User. El usuario (apache) debe existir y tener la propiedad correcta de los archivos de la aplicación.

Use TimeoutStopSec para configurar el período de tiempo que hay que esperar para que la aplicación se apague después de que reciba la señal de interrupción inicial. Si la aplicación no se apaga en este período, se emite SIGKILL para terminar la aplicación. Proporcione el valor como segundos sin unidad (por ejemplo, 150), un intervalo de tiempo (por ejemplo, 2min 30s) o infinity para deshabilitar el tiempo de expiración. El valor predeterminado de TimeoutStopSec es el valor de DefaultTimeoutStopSec del archivo de configuración del administrador (systemd-system.conf, system.conf.d, systemd-user.conf o user.conf.d). El tiempo de expiración predeterminado para la mayoría de las distribuciones es de 90 segundos.

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

Algunos valores (por ejemplo, cadenas de conexión de SQL) deben ser de escape para que los proveedores de configuración lean las variables de entorno. Use el siguiente comando para generar un valor de escape correctamente para su uso en el archivo de configuración:

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

No se admiten los separadores de dos puntos (:) en los nombres de variable de entorno. Use un subrayado doble (__) en lugar de dos puntos. El proveedor de configuración de variables de entorno convierte doble subrayado en dos puntos cuando las variables de entorno se leen en la configuración. En el ejemplo siguiente, la clave de la cadena de conexión ConnectionStrings:DefaultConnection se establece en el archivo de definición de servicio como ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Guarde el archivo y habilite el servicio.

sudo systemctl enable kestrel-helloapp.service

Inicie el servicio y compruebe que se está ejecutando:

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

Con el proxy inverso configurado y Kestrel administrado a través de systemd, la aplicación web está completamente configurada y se puede acceder a ella desde un explorador en la máquina local en http://localhost. Inspeccionar los encabezados de respuesta; el encabezado Server indica que Kestrel atiende la aplicación ASP.NET Core:

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

Ver registros

Dado que la aplicación web que usa Kestrel se administra mediante systemd, los procesos y eventos se registran en un diario centralizado. Sin embargo, este diario incluye todas las entradas de todos los servicios y procesos administrados por systemd. Para ver los elementos específicos de kestrel-helloapp.service, use el siguiente comando:

sudo journalctl -fu kestrel-helloapp.service

Para el filtrado de tiempo, especifique las opciones de tiempo con el comando. Por ejemplo, use --since today para filtrar por el día actual o --until 1 hour ago para ver las entradas de la hora anterior. Para más información, consulte la página man de journalctl.

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

Protección de datos

Hay varios softwares intermedios de ASP.NET Core que utilizan la pila de protección de datos de ASP.NET Core, incluidos los de autenticación, como el de cookies, y las protecciones de falsificación de solicitud entre sitios (CSRF). Aunque el código de usuario no llame a las API de protección de datos, esta se debe configurar para crear un almacén de claves criptográficas persistente. Si no se configura la protección de datos, las claves se conservan en memoria y se descartan cuando se reinicia la aplicación.

Si el conjunto de claves se almacena en memoria cuando se reinicia la aplicación:

• Todos los tokens de autenticación basados en cookie se invalidan.
• Los usuarios tienen que iniciar sesión de nuevo en la siguiente solicitud.
• Ya no se pueden descifrar los datos protegidos con el conjunto de claves. Esto puede incluir tokens CSRF y cookies de TempData de ASP.NET Core MVC.

Para configurar la protección de datos de modo que sea persistente y permita cifrar el anillo de claves, consulte:

• Proveedores de almacenamiento de claves en ASP.NET Core
• Cifrado de claves en reposo en Windows y Azure mediante ASP.NET Core

Protección de la nube

Configurar el firewall

Firewalld es un demonio dinámico para administrar el firewall con compatibilidad con zonas de red. Los puertos y el filtrado de paquetes se pueden seguir administrando mediante iptables. Firewalld debe instalarse de forma predeterminada. yum puede usarse para instalar el paquete o comprobar que está instalado.

sudo yum install firewalld -y

Use firewalld para abrir solo los puertos necesarios para la aplicación. En este caso se usan los puertos 80 y 443. Los siguientes comandos establecen de forma permanente que se abran los puertos 80 y 443:

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

Vuelva a cargar la configuración del firewall. Compruebe los servicios y puertos disponibles en la zona predeterminada. Hay opciones disponibles si se inspecciona 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: 

Configuración de HTTPS

Configuración de la aplicación para conexiones locales seguras (HTTPS)

El comando dotnet run usa el archivo Properties/launchSettings.json de la aplicación, que configura la aplicación para que escuche en las direcciones URL proporcionadas por la propiedad applicationUrl (por ejemplo, https://localhost:5001;http://localhost:5000).

Configure la aplicación para que use un certificado en el desarrollo para el comando dotnet run o el entorno de desarrollo (F5 o CTRL+F5 en Visual Studio Code) mediante uno de los siguientes enfoques:

• Reemplace el certificado predeterminado de configuración (recomendado)
• KestrelServerOptions.ConfigureHttpsDefaults

Configure el proxy inverso para conexiones de cliente seguras (HTTPS)

Advertencia

La configuración de seguridad de esta sección es una configuración general que se usará como punto de partida para una personalización adicional. No podemos proporcionar soporte técnico para sistemas operativos, servidores y herramientas de terceros. Utilice la configuración en esta sección bajo su propia responsabilidad. Para obtener más información, vea los siguientes recursos:

• Cifrado de SSL/TLS de Apache (documentación de Apache)
• Generador de configuración de SSL de mozilla.org

Para configurar Apache para HTTPS, se usa el módulo mod_ssl. Cuando se instaló el módulo httpd, también lo hizo el módulo mod_ssl. Si aún no se ha instalado, use yum para agregarlo a la configuración.

sudo yum install mod_ssl

Para usar HTTPS, instale el módulo mod_rewrite para habilitar la reescritura de direcciones URL:

sudo yum install mod_rewrite

Modifique el archivo helloapp.conf para habilitar una comunicación segura en el puerto 443.

En el siguiente ejemplo no se configura el servidor para redirigir las solicitudes no seguras. Se recomienda usar el middleware de redireccionamiento de HTTPS. Para más información, vea Aplicación de HTTPS en ASP.NET Core.

Nota

En entornos de desarrollo en los que la configuración del servidor controla el redireccionamiento seguro en lugar del middleware de redireccionamiento de HTTPS, se recomienda usar redireccionamientos temporales (302) en lugar de permanentes (301). El almacenamiento en caché de vínculos puede producir un comportamiento inestable en los entornos de desarrollo.

El hecho de agregar un encabezado Strict-Transport-Security (HSTS) garantiza que todas las solicitudes sucesivas realizadas por el cliente sean a través de HTTPS. Para obtener instrucciones sobre cómo configurar el encabezado Strict-Transport-Security, vea Aplicación de HTTPS en 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>

Nota

En este ejemplo se usa un certificado generado localmente. SSLCertificateFile debe ser el archivo de certificado principal para el nombre de dominio. SSLCertificateKeyFile debe ser el archivo de claves generado al crear el CSR. SSLCertificateChainFile debe ser el archivo de certificado intermedio (si existe) proporcionado por la entidad de certificación.

Se requiere la versión 2.4.43 u otra posterior del servidor HTTP de Apache para poder operar un servidor web TLS 1.3 con OpenSSL 1.1.1.

Nota

El ejemplo anterior deshabilita el grapado del Protocolo de estado de certificados en línea (OCSP). Para obtener más información e instrucciones sobre cómo habilitar el OCSP, consulte Grapado de OCSP (documentación de Apache).

Guarde el archivo y pruebe la configuración.

sudo service httpd configtest

Reinicie Apache:

sudo systemctl restart httpd

Sugerencias adicionales de Apache

Reinicio de aplicaciones con actualizaciones de marco compartidas

Después de actualizar el marco de trabajo compartido en el servidor, reinicie las aplicaciones ASP.NET Core que hospeda el servidor.

Encabezados adicionales

Para protegerse de ataques malintencionados, se deben modificar o agregar varios encabezados. Asegúrese de que el módulo mod_headers está instalado.

sudo yum install mod_headers

Protección de Apache de los ataques de secuestro de clic

El secuestro de clic, también conocido como redireccionamiento de interfaz de usuario, es un ataque malintencionado donde al visitante de un sitio web se le engaña para que haga clic en un vínculo o botón de una página distinta de la que actualmente está visitando. Use X-FRAME-OPTIONS para proteger el sitio.

Para mitigar los ataques de secuestro de clic:

1. Edite el archivo httpd.conf.

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

   Agregue la línea Header append X-FRAME-OPTIONS "SAMEORIGIN".

2. Guarde el archivo.

3. Reinicie Apache.

Examen de tipo MIME

El encabezado X-Content-Type-Options impide que Internet Explorer examine MIME (de forma que el elemento Content-Type de un archivo se determina a partir del contenido del archivo). Si el servidor establece el encabezado Content-Type en text/html con la opción nosniff establecida, Internet Explorer representa el contenido como text/html sin tener en cuenta el contenido del archivo.

Edite el archivo httpd.conf.

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

Agregue la línea Header set X-Content-Type-Options "nosniff". Guarde el archivo. Reinicie Apache.

Equilibrio de carga

En este ejemplo se muestra cómo instalar y configurar Apache en CentOS 7 y Kestrel en el mismo equipo de la instancia. Para no tener un único punto de error, el uso de mod_proxy_balancer y la modificación de VirtualHost permitirían administrar varias instancias de las aplicaciones web detrás del servidor proxy de Apache.

sudo yum install mod_proxy_balancer

En el archivo de configuración que se muestra a continuación, se configura una instancia adicional de helloapp para que se ejecute en el puerto 5001. La sección Proxy se establece con una configuración de equilibrador con dos miembros para equilibrar la carga 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>

Límites de velocidad

Use mod_ratelimit, que se incluye en el módulo httpd; el ancho de banda de los clientes puede ser limitado:

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

En el archivo de ejemplo se limita el ancho de banda a 600 KB/s en la ubicación raíz:

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

Campos del encabezado de solicitud más largos

La configuración predeterminada del servidor proxy normalmente limita los campos de encabezado de la solicitud a 8.190 bytes. Una aplicación puede requerir campos con una longitud mayor que la predeterminada (por ejemplo, las aplicaciones que usan Microsoft Entra ID). Si se requieren campos más largos, es necesario ajustar la directiva LimitRequestFieldSize del servidor proxy. El valor que se aplica depende del escenario. Para obtener más información, consulte la documentación del servidor.

Advertencia

No aumente el valor predeterminado de LimitRequestFieldSize a menos que sea necesario. El aumento de este valor incrementa el riesgo de saturación del búfer (desbordamiento) y ataques por denegación de servicio (DoS) realizados por usuarios malintencionados.

Recursos adicionales

• Requisitos previos para .NET Core en Linux
• Solución de problemas y depuración de proyectos de ASP.NET Core
• Configurar ASP.NET Core para trabajar con servidores proxy y equilibradores de carga