Udostępnij za pośrednictwem

Jak zintegrować usługę Azure SignalR z zwrotnymi serwerami proxy

Zwrotny serwer proxy może być używany przed usługą Azure SignalR Service. Odwrotne serwery proxy znajdują się między klientami a usługą Azure SignalR i innymi usługami, które mogą pomóc w różnych scenariuszach. Na przykład odwrotne serwery proxy mogą równoważyć obciążenie różnych żądań klientów do różnych usług zaplecza, zazwyczaj można skonfigurować różne reguły routingu dla różnych żądań klientów i zapewnić bezproblemowe środowisko użytkownika dla użytkowników korzystających z różnych usług zaplecza. Mogą również chronić serwery zaplecza przed typowymi lukami w zabezpieczeniach za pomocą scentralizowanej kontroli ochrony. Usługi takie jak Azure Application Gateway, Azure API Management lub Akamai mogą pełnić rolę odwrotnych serwerów proxy.

Typowa architektura korzystająca z odwrotnego serwera proxy z usługą Azure SignalR jest następująca:

Diagram przedstawiający architekturę korzystającą z usługi Azure SignalR z zwrotnym serwerem proxy.

Ważne

Nieprzetworzone parametry połączenia są wyświetlane tylko w tym artykule w celach demonstracyjnych.

Parametry połączenia zawiera informacje o autoryzacji wymagane do uzyskania dostępu do usługi Azure SignalR Service przez aplikację. Klucz dostępu wewnątrz ciągu połączenia jest podobny do hasła głównego dla twojej usługi. W środowiskach produkcyjnych zawsze chroń klucze dostępu. Usługa Azure Key Vault umożliwia bezpieczne zarządzanie kluczami i obracanie ich oraz zabezpieczanie parametry połączenia przy użyciu identyfikatora Entra firmy Microsoft i autoryzowania dostępu za pomocą identyfikatora Entra firmy Microsoft.

Unikaj dystrybuowania kluczy dostępu do innych użytkowników, kodowania ich lub zapisywania ich w dowolnym miejscu w postaci zwykłego tekstu, który jest dostępny dla innych użytkowników. Obracanie kluczy, jeśli uważasz, że mogły one zostać naruszone.

Ogólne praktyki

Istnieje kilka ogólnych rozwiązań, które należy stosować w przypadku korzystania z zwrotnego serwera proxy przed usługą SignalR Service.

Nieprzetworzone parametry połączenia są wyświetlane tylko w tym artykule w celach demonstracyjnych. W środowiskach produkcyjnych zawsze chroń klucze dostępu. Usługa Azure Key Vault umożliwia bezpieczne zarządzanie kluczami i obracanie ich oraz zabezpieczanie parametry połączenia przy użyciu identyfikatora Entra firmy Microsoft i autoryzowania dostępu za pomocą identyfikatora Entra firmy Microsoft.

  • Pamiętaj o ponownym zapisie przychodzącego nagłówka hosta HTTP Usługa Azure SignalR jest usługą wielodostępną i opiera się na nagłówku HOST w celu rozpoznania poprawnego punktu końcowego. Na przykład podczas konfigurowania usługi Application Gateway dla usługi Azure SignalR wybierz Tak dla opcji Zastąp nową nazwą hosta.

  • Gdy klient korzysta z Twojego zwrotnego serwera proxy do usługi Azure SignalR, ustaw ClientEndpoint jako adres URL zwrotnego serwera proxy. Gdy klient negocjuje z serwerem centralnym, serwer centralny zwróci adres URL zdefiniowany w ClientEndpoint, aby klient mógł się połączyć. Sprawdź tutaj, aby uzyskać więcej szczegółów.

    Istnieją dwa sposoby konfigurowania ClientEndpoint:

    • Dodaj sekcję ClientEndpoint do elementu ConnectionString: Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • Skonfiguruj ClientEndpoint podczas wywoływania 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>")
        }
    };
})

  • Gdy klient przechodzi przez zwrotny serwer proxy do usługi Azure SignalR, istnieją dwa typy żądań:

    • Żądanie POST HTTP do <reverse-proxy-URL>/client/negotiate/, które nazywamy żądaniem negocjowania
    • Żądanie połączenia WebSocket/SSE/LongPolling w zależności od typu transportu do <reverse-proxy-URL>/client/, które nazywamy żądaniem połączenia.

    Upewnij się, że serwer pośredniczący obsługuje oba typy transportu dla /client/ podścieżki. Na przykład gdy typ transportu to WebSocket, upewnij się, że zwrotny serwer proxy obsługuje zarówno protokół HTTP, jak i protokół WebSocket dla /client/ ścieżki podrzędnej.

    Jeśli skonfigurowałeś wiele usług SignalR za zwrotnym serwerem proxy, upewnij się, że zarówno negotiate żądanie, jak i connect żądanie z tym samym asrs_request_id parametrem zapytania (co oznacza, że dotyczą tego samego połączenia) są kierowane do tego samego wystąpienia usługi SignalR.

  • W przypadku ServerSentEvent(SSE) upewnij się, że zwrotny serwer proxy nie buforuje ani nie buforuje odpowiedzi. Na przykład usługa API Management wyświetla listę elementów kontrolnych w tym miejscu podczas konfigurowania interfejsu API dla zdarzeń wysyłanych przez serwer.

  • W przypadku używania zwrotnego serwera proxy można dodatkowo zabezpieczyć usługę SignalR, wyłączając dostęp do sieci publicznej i używając prywatnych punktów końcowych , aby zezwolić na dostęp prywatny z zwrotnego serwera proxy do usługi SignalR za pośrednictwem sieci wirtualnej.

Następne kroki