Udostępnij za pośrednictwem

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

  • Artykuł

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 aplikacja systemu Azure Gateway, Azure API Management lub Akamai mogą pełnić rolę zwrotnych 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 przez aplikację w celu uzyskania dostępu do usługi Azure Web PubSub. Klucz dostępu wewnątrz parametry połączenia jest podobny do hasła głównego 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.

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.

  • Pamiętaj o ponownym zapisie przychodzącego nagłówka hosta HTTP przy użyciu adresu URL usługi Azure SignalR, np. https://demo.service.signalr.net. 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 opcję Tak dla opcji Zastąpij nową nazwą hosta.

  • Gdy klient przechodzi przez zwrotny serwer proxy do usługi Azure SignalR, ustaw ClientEndpoint go jako zwrotny adres URL serwera proxy. Gdy klient negocjujeusługę z serwerem centrum, serwer koncentratora zwróci adres URL zdefiniowany przez ClientEndpoint klienta, aby nawiązać połączenie. 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>

    • Konfigurowanie ClientEndpoint podczas wywoływania elementu 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 postu HTTP do <reverse-proxy-URL>/client/negotiate/, które wywołujemy jako żądanie negocjowania
    • Żądanie połączenia WebSocket/SSE/LongPolling w zależności od typu transportu do <reverse-proxy-URL>/client/, które wywołujemy jako żądanie połączenia.

    Upewnij się, że zwrotny serwer proxy obsługuje oba typy transportu dla /client/ ścieżki podrzędnej. 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 skonfigurowano wiele usług SignalR za zwrotnym serwerem proxy, upewnij się, że negotiate żądanie i connect żądanie z tym samym asrs_request_id parametrem zapytania (co oznacza, że są one dla tego samego połączenia) są kierowane do tego samego wystąpienia usługi SignalR.

  • 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