Compartir a través de

Integración de Azure SignalR con servidores proxy inversos

  • Artículo

Se puede usar un servidor proxy inverso delante de Azure SignalR Service. Los servidores proxy inversos se encuentran entre los clientes, y el servicio Azure SignalR y otros servicios pueden ayudar en varios escenarios. Por ejemplo, los servidores proxy inversos pueden equilibrar la carga de solicitudes de cliente diferentes a diferentes servicios back-end, normalmente puede configurar reglas de enrutamiento diferentes para diferentes solicitudes de cliente y proporcionar una experiencia de usuario fluida para los usuarios que acceden a diferentes servicios back-end. También pueden proteger los servidores back-end frente a vulnerabilidades de seguridad comunes con control de protección centralizado. Los servicios como Azure Application Gateway, Azure API Management o Akamai pueden actuar como servidores proxy inversos.

Una arquitectura común mediante un servidor proxy inverso con Azure SignalR es la siguiente:

Diagrama que muestra la arquitectura que usa Azure SignalR con un servidor proxy inverso.

Importante

Las cadenas de conexión sin procesar solo aparecen en este artículo con fines de demostración.

Una cadena de conexión incluye la información de autorización necesaria para que la aplicación acceda al servicio Azure Web PubSub. La clave de acceso dentro de la cadena de conexión es similar a una contraseña raíz para el servicio. En entornos de producción, proteja siempre las claves de acceso. Use Azure Key Vault para administrar y rotar las claves de forma segura y proteger la cadena de conexión mediante el Microsoft Entra ID y autorizar el acceso con el identificador de Microsoft Entra.

Evite distribuirlas a otros usuarios, codificarlas de forma rígida o guardarlas en un archivo de texto sin formato al que puedan acceder otros usuarios. Rote sus claves si cree que se han puesto en peligro.

Procedimientos generales

Hay varias prácticas generales que se deben seguir al usar un proxy inverso delante de SignalR Service.

Las cadenas de conexión sin procesar solo aparecen en este artículo con fines de demostración. En entornos de producción, proteja siempre las claves de acceso. Use Azure Key Vault para administrar y rotar las claves de forma segura y proteger la cadena de conexión mediante el Microsoft Entra ID y autorizar el acceso con el identificador de Microsoft Entra.

  • Asegúrese de reescribir el encabezado HOST HTTP entrante con la dirección URL del servicio Azure SignalR, por ejemplo, https://demo.service.signalr.net. Azure SignalR es un servicio multiinquilino y se basa en el encabezado HOST para resolver el punto de conexión correcto. Por ejemplo, al configurar Application Gateway para Azure SignalR, seleccione Sí para la opción Invalidar con el nuevo nombre de host.

  • Cuando el cliente pase por el proxy inverso a Azure SignalR, establezca ClientEndpoint como dirección URL del proxy inverso. Cuando el cliente negocia con el servidor concentrador, el servidor concentrador devolverá la dirección URL definida en ClientEndpoint para que el cliente se conecte. Obtenga más información en este artículo.

    Hay dos formas de configurar ClientEndpoint:

    • Agregue una sección ClientEndpoint a ConnectionString: Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • Configure ClientEndpoint al llamar a AddAzureSignalR:

      services.AddSignalR().AddAzureSignalR(o =>
{
    o.Endpoints = new Microsoft.Azure.SignalR.ServiceEndpoint[1]
    {
        new Microsoft.Azure.SignalR.ServiceEndpoint("<azure-signalr-connection-string>")
        {
            ClientEndpoint = new Uri("<reverse-proxy-URL>")
        }
    };
})

  • Cuando un cliente pasa por el proxy inverso hacia Azure SignalR, hay dos tipos de solicitudes:

    • Solicitud post HTTP a <reverse-proxy-URL>/client/negotiate/, a la que llamamos solicitud de negociación
    • Solicitud de conexión WebSocket/SSE/LongPolling en función del tipo de transporte a <reverse-proxy-URL>/client/, al que llamamos como solicitud de conexión.

    Asegúrese de que el proxy inverso admite ambos tipos de transporte para la subruta /client/. Por ejemplo, cuando el tipo de transporte es WebSocket, asegúrese de que el proxy inverso admite HTTP y WebSocket para la subruta /client/.

    Si ha configurado varios servicios de SignalR detrás del proxy inverso, asegúrese de que la solicitud negotiate y la solicitud connect con el mismo parámetro de consulta asrs_request_id (lo que significa que están para la misma conexión) se enrutan a la misma instancia del servicio SignalR.

  • Cuando se usa el proxy inverso, puede proteger aún más el servicio SignalR mediante la deshabilitación del acceso a la red pública y el uso de puntos de conexión privados para permitir solo el acceso privado desde el proxy inverso al servicio SignalR a través de la red virtual.

Pasos siguientes