Compartilhar via

Como integrar o Azure SignalR a proxies reversos

  • Artigo

Um servidor proxy reverso pode ser usado na frente do Serviço do Azure SignalR. Os servidores proxy reversos ficam entre os clientes e o serviço do Azure SignalR e outros serviços podem ajudar em vários cenários. Por exemplo, os servidores proxy reversos podem balancear a carga de diferentes solicitações de cliente para diferentes serviços de back-end. Geralmente é possível configurar regras de roteamento diferentes para solicitações de cliente diferentes e fornecer uma experiência de usuário contínua para os usuários que acessam diferentes serviços de back-end. Eles também podem proteger os servidores de back-end contra vulnerabilidades comuns de explorações com controle de proteção centralizado. Serviços como o Gateway de Aplicativo do Azure, o Gerenciamento de API do Azure ou o Akamai podem atuar como servidores proxy reversos.

Uma arquitetura comum usando um servidor proxy reverso com o Azure SignalR é a seguinte:

Diagrama que mostra a arquitetura usando o Azure SignalR com um servidor proxy reverso.

Importante

As cadeias de conexão brutas aparecem neste artigo apenas para fins de demonstração.

Uma cadeia de conexão inclui as informações de autorização necessárias para que o seu aplicativo acesse o serviço Azure Web PubSub. A chave de acesso dentro da cadeia de conexão é semelhante a uma senha raiz para o serviço. Em ambientes de produção, sempre proteja suas chaves de acesso. Use o Azure Key Vault para gerenciar e girar suas chaves com segurança e proteger sua cadeia de conexão usando o Microsoft Entra ID.

Evite distribuir chaves de acesso para outros usuários, fazer hard-coding com elas ou salvá-las em qualquer lugar em texto sem formatação que seja acessível a outras pessoas. Gire suas chaves se você acredita que elas podem ter sido comprometidas.

Práticas gerais

Há várias práticas gerais a serem seguidas ao usar um proxy reverso na frente de Serviço do SignalR.

As cadeias de conexão brutas aparecem neste artigo apenas para fins de demonstração. Em ambientes de produção, sempre proteja suas chaves de acesso. Use o Azure Key Vault para gerenciar e girar suas chaves com segurança e proteger sua cadeia de conexão usando o Microsoft Entra ID.

  • Regenere o cabeçalho HOST HTTP de entrada com a URL de serviço do Azure SignalR, por exemplo https://demo.service.signalr.net. O Azure SignalR é um serviço multilocatário e depende do cabeçalho HOST para resolução para o ponto de extremidade correto. Por exemplo, ao configurar o Gateway de Aplicativo no Azure SignalR, selecione Sim na opção Substituir pelo novo nome do host.

  • Quando o cliente passar pelo proxy reverso para o Azure SignalR, defina ClientEndpoint como a URL de proxy reverso. Quando o cliente negociarcom o servidor de hub, ele retornará a URL definida em ClientEndpoint para que o cliente se conecte. Veja aqui para obter mais detalhes.

    Há duas maneiras de configurar ClientEndpoint:

    • Adicione uma seção ClientEndpoint ao ConnectionString: Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • Configurar ClientEndpoint ao chamar 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>")
        }
    };
})

  • Quando um cliente passa pelo proxy reverso para o Azure SignalR, há dois tipos de solicitações:

    • Solicitação de HTTP POST para <reverse-proxy-URL>/client/negotiate/, que chamamos de solicitação de negociação
    • Solicitação de conexão WebSocket/SSE/LongPolling, dependendo do tipo de transporte para <reverse-proxy-URL>/client/, o qual chamamos como solicitação de conexão.

    Verifique se o proxy reverso dá suporte a ambos os tipos de transporte para o subcaminho /client/. Por exemplo, quando o tipo de transporte for WebSocket, verifique se o proxy reverso dá suporte a HTTP e WebSocket para o subcaminho /client/.

    Se você tiver configurado vários serviços do SignalR por trás do proxy reverso, verifique se as solicitações negotiate e connect com o mesmo parâmetro de consulta asrs_request_id (o que significa que eles são para a mesma conexão) serão roteados para a mesma instância de serviço do SignalR.

  • Quando o proxy reverso é usado, você pode proteger ainda mais o serviço SignalR desabilitando o acesso à rede pública e usando pontos de extremidade privados para permitir apenas o acesso privado do proxy reverso ao serviço do SignalR por meio da VNet.

Próximas etapas