Поделиться через

Интеграция Azure SignalR с обратными прокси-клиентами

  • Статья

Обратный прокси-сервер можно использовать перед Служба Azure SignalR. Обратные прокси-серверы сидят между клиентами и службой Azure SignalR и другими службами, могут помочь в различных сценариях. Например, обратные прокси-серверы могут сбалансировать различные клиентские запросы к различным службам серверной части, обычно можно настроить разные правила маршрутизации для различных клиентских запросов и обеспечить простой пользовательский интерфейс для пользователей, обращаюющихся к различным службам серверной части. Они также могут защитить серверные серверы от распространенных уязвимостей эксплойтов с помощью централизованного управления защитой. Такие службы, как Шлюз приложений Azure, Azure Управление API или Akamai могут выступать в качестве обратных прокси-серверов.

Общая архитектура с использованием обратного прокси-сервера с Azure SignalR приведена ниже.

Схема, показывающая архитектуру с помощью Azure SignalR с обратным прокси-сервером.

Внимание

Необработанные строка подключения отображаются в этой статье только для демонстрационных целей.

Строка подключения включает сведения о авторизации, необходимые для доступа к Служба Azure SignalR приложения. Ключ доступа в строке подключения аналогичен паролю привилегированного пользователя для службы. В рабочих средах всегда защищать ключи доступа. Используйте Azure Key Vault для безопасного управления ключами и защиты строка подключения с помощью идентификатора Microsoft Entra и авторизации доступа с помощью идентификатора Microsoft Entra.

Старайтесь не распространять ключи доступа среди других пользователей, жестко программировать их или где-то сохранять в виде обычного текста в открытом доступе для других пользователей. Меняйте свои ключи постоянно, если предполагаете, что они могут быть подобраны.

Общие рекомендации

При использовании обратного прокси-сервера перед Служба SignalR существует несколько общих рекомендаций.

Необработанные строка подключения отображаются в этой статье только для демонстрационных целей. В рабочих средах всегда защищать ключи доступа. Используйте Azure Key Vault для безопасного управления ключами и защиты строка подключения с помощью идентификатора Microsoft Entra и авторизации доступа с помощью идентификатора Microsoft Entra.

  • Обязательно переопределите входящий заголовок HTTP HOST с URL-адресом службы Azure SignalR, например. https://demo.service.signalr.net Azure SignalR — это мультитенантная служба, которая использует HOST заголовок для разрешения правильной конечной точки. Например, при настройке Шлюз приложений для Azure SignalR выберите "Да" для параметра "Переопределить" с новым именем узла.

  • Когда клиент проходит обратный прокси-сервер в Azure SignalR, задайте ClientEndpoint в качестве URL-адреса обратного прокси-сервера. При согласованииклиента с сервером концентратора главный сервер вернет URL-адрес, определенный ClientEndpoint для подключения клиента. Дополнительные сведения см. здесь.

    Существует два способа настройки ClientEndpoint:

    • ClientEndpoint Добавьте раздел в ConnectionString:Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • Настройка ClientEndpoint при вызове 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>")
        }
    };
})

  • Когда клиент проходит обратный прокси-сервер в Azure SignalR, существует два типа запросов:

    • HTTP-запрос <reverse-proxy-URL>/client/negotiate/после отправки, в который мы вызываем в качестве запроса на согласование
    • Запрос подключения WebSocket/SSE/LongPolling в зависимости от типа <reverse-proxy-URL>/client/транспорта, к которому мы вызываем в качестве запроса подключения.

    Убедитесь, что обратный прокси-сервер поддерживает оба типа транспорта для /client/ подпата. Например, если тип транспорта — WebSocket, убедитесь, что обратный прокси-сервер поддерживает http и WebSocket для /client/ подпата.

    Если вы настроили несколько служб SignalR за обратным прокси-сервером, убедитесь, что negotiate запрос и connect запрос с одинаковым параметром запроса (то есть они предназначены для одного подключения) направляются в тот же asrs_request_id экземпляр службы SignalR.

  • При использовании обратного прокси-сервера можно дополнительно защитить службу SignalR, отключив доступ к общедоступной сети и используя частные конечные точки, чтобы разрешить доступ только с обратного прокси-сервера к службе SignalR через виртуальную сеть.

Следующие шаги