Udostępnij za pośrednictwem

Jak używać usługi Azure SignalR Service z usługą aplikacja systemu Azure Gateway

  • Artykuł

Application Gateway to moduł równoważenia obciążenia ruchu internetowego, który umożliwia zarządzanie ruchem do aplikacji internetowych. Korzystanie z usługi Application Gateway z usługą SignalR Service umożliwia wykonanie następujących czynności:

  • Chroń aplikacje przed typowymi lukami w zabezpieczeniach internetowych.
  • Uzyskaj równoważenie obciążenia na poziomie aplikacji dla skalowalnych i wysoce dostępnych aplikacji.
  • Skonfiguruj kompleksowe zabezpieczenia.
  • Dostosuj nazwę domeny.

Ten artykuł zawiera dwie części:

  • W pierwszej części pokazano, jak skonfigurować usługę Application Gateway, aby klienci mogli uzyskiwać dostęp do usługi SignalR za pośrednictwem usługi Application Gateway.
  • W drugiej części pokazano, jak zabezpieczyć usługę SignalR Service przez dodanie kontroli dostępu do usługi SignalR Service i zezwalanie tylko na ruch z usługi Application Gateway.

Diagram przedstawiający architekturę korzystania z usługi SignalR Service z usługą Application Gateway.

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.

Instalowanie i konfigurowanie usługi Application Gateway

Tworzenie wystąpienia usługi SignalR Service

  • Postępuj zgodnie z artykułem i utwórz wystąpienie usługi SignalR Service ASRS1

Tworzenie wystąpienia usługi Application Gateway

Utwórz z poziomu portalu wystąpienie usługi Application Gateway AG1:

  • W witrynie Azure Portal wyszukaj ciąg Application Gateway i Utwórz.

  • Na karcie Podstawowe użyj tych wartości dla następujących ustawień bramy aplikacji:

    • Subskrypcja i grupa zasobów i region: tak samo jak w przypadku usługi SignalR Service

    • Nazwa bramy aplikacji: AG1

    • Sieć wirtualna, wybierz pozycję Utwórz nową, a następnie w wyświetlonym oknie Tworzenie sieci wirtualnej wprowadź następujące wartości, aby utworzyć sieć wirtualną i dwie podsieci, jedną dla bramy aplikacji, a drugą dla serwerów zaplecza.

      • Nazwa: wprowadź VN1 jako nazwę sieci wirtualnej.

      • Podsieci: zaktualizuj siatkę Podsieci przy użyciu poniższych 2 podsieci

        Nazwa podsieci Zakres adresów Uwaga
        myAGSubnet (zakres adresów) Podsieć bramy aplikacji. Podsieć bramy aplikacji może zawierać tylko bramy aplikacji. Inne zasoby nie są dozwolone.
        myBackendSubnet (inny zakres adresów) Podsieć dla wystąpienia usługi Azure SignalR.

    • Zaakceptuj wartości domyślne innych ustawień, a następnie wybierz pozycję Dalej: Frontony

  • Na karcie Frontony:

    • Typ adresu IP frontonu: Publiczny.
    • Wybierz pozycję Dodaj nowy dla publicznego adresu IP i wprowadź ciąg myAGPublicIPAddress jako nazwę publicznego adresu IP, a następnie wybierz przycisk OK.
    • Wybierz pozycję Dalej: zapleczaZrzut ekranu przedstawiający tworzenie wystąpienia usługi Application Gateway z kartą Frontends (Frontends).

  • Na karcie Zaplecza wybierz pozycję Dodaj pulę zaplecza:

    • Nazwa: wprowadź signalr dla puli zasobów usługi SignalR Service.
    • Docelowy obiekt docelowy zaplecza: nazwa hosta wystąpienia usługi SignalR Service ASRS1, na przykład asrs1.service.signalr.net
    • Wybierz pozycję Dalej: Konfiguracja

    Zrzut ekranu przedstawiający konfigurowanie puli zaplecza bramy aplikacji dla usługi SignalR Service.

  • Na karcie Konfiguracja wybierz pozycję Dodaj regułę routingu w kolumnie Reguły routingu:

    • Nazwa reguły: myRoutingRule

    • Priorytet: 1

    • Na karcie Odbiornik w oknie Dodawanie reguły routingu wprowadź następujące wartości dla odbiornika:

      • Nazwa odbiornika: wprowadź wartość myListener jako nazwę odbiornika.
      • Adres IP frontonu: wybierz pozycję Publiczny, aby wybrać publiczny adres IP utworzony dla frontonu.
      • Protokół: HTTP
        • W tym artykule używamy protokołu frontonu HTTP w usłudze Application Gateway, aby uprościć pokaz i ułatwić rozpoczęcie pracy. Jednak w rzeczywistości może być konieczne włączenie protokołu HTTPs i domeny klienta w tym scenariuszu produkcyjnym.
      • Zaakceptuj wartości domyślne innych ustawień na karcie OdbiornikZrzut ekranu przedstawiający konfigurowanie karty odbiornika reguły routingu bramy aplikacji dla usługi SignalR Service.

    • Na karcie Elementy docelowe zaplecza użyj następujących wartości:

      • Typ docelowy: pula zaplecza

      • Obiekt docelowy zaplecza: wybierz wcześniej utworzony signalr

      • Ustawienia zaplecza: wybierz pozycję Dodaj nowe , aby dodać nowe ustawienie.

        • Nazwa ustawień zaplecza: mySetting
        • Protokół zaplecza: HTTPS
        • Użyj dobrze znanego certyfikatu urzędu certyfikacji: Tak
        • Zastąpij nową nazwą hosta: Tak
        • Zastąpienie nazwy hosta: wybierz nazwę hosta z obiektu docelowego zaplecza
        • Inne przechowują wartości domyślne

        Zrzut ekranu przedstawiający konfigurowanie ustawienia zaplecza bramy aplikacji dla usługi SignalR Service.

      Zrzut ekranu przedstawiający tworzenie obiektów docelowych zaplecza dla bramy aplikacji.

  • Przeglądanie i tworzenie grupy dostępności 1Zrzut ekranu przedstawiający przeglądanie i tworzenie wystąpienia bramy aplikacji.

Konfigurowanie sondy kondycji usługi Application Gateway

Po utworzeniu grupy dostępności AG1 przejdź do karty Sondy kondycji w sekcji Ustawienia w portalu, zmień ścieżkę sondy kondycji na/api/health

Zrzut ekranu przedstawiający konfigurowanie sondy kondycji zaplecza bramy aplikacji dla usługi SignalR Service.

Szybki test

  • Spróbuj użyć nieprawidłowego żądania https://asrs1.service.signalr.net/client klienta i zwraca błąd 400 z komunikatem o błędzie "hub" parametr zapytania jest wymagany. Oznacza to, że żądanie dotarło do usługi SignalR Service i wykonało walidację żądania.

    curl -v https://asrs1.service.signalr.net/client

    zwraca

    < HTTP/1.1 400 Bad Request
< ...
<
'hub' query parameter is required.

  • Przejdź do karty Przegląd grupy dostępności AG1 i znajdź publiczny adres IP frontonu

    Zrzut ekranu przedstawiający szybki test punktu końcowego usługi SignalR Kondycja usługi za pośrednictwem usługi Application Gateway.

  • Odwiedź punkt końcowy kondycji za pośrednictwem grupy DOSTĘPNOŚCI1http://<frontend-public-IP-address>/client, a także zwraca wartość 400 z komunikatem o błędzie "hub" parametr zapytania jest wymagany. Oznacza to, że żądanie pomyślnie przeszedł przez usługę Application Gateway do usługi SignalR Service i wykonał walidację żądania.

    curl -I http://<frontend-public-IP-address>/client

    zwraca

    < HTTP/1.1 400 Bad Request
< ...
<
'hub' query parameter is required.

Uruchamianie czatu za pośrednictwem usługi Application Gateway

Teraz ruch może dotrzeć do usługi SignalR Service za pośrednictwem usługi Application Gateway. Aby uzyskać dostęp do zasobu, klient może użyć publicznego adresu IP usługi Application Gateway lub niestandardowej nazwy domeny. Użyjmy tej aplikacji do czatu jako przykładu. Zacznijmy od uruchamiania go lokalnie.

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.

  • Najpierw uzyskajmy parametry połączenia usługi ASRS1

    • Na karcie Parametry połączenia usługi ASRS1
      • Punkt końcowy klienta: wprowadź adres URL przy użyciu publicznego adresu IP frontonu grupy DOSTĘPNOŚCI 1, na przykład http://20.88.8.8. Jest to generator parametry połączenia podczas korzystania z odwrotnych serwerów proxy, a wartość nie jest zachowywana po następnym powrocie do tej karty. Po wprowadzeniu wartości parametry połączenia dołącza sekcjęClientEndpoint.
      • Kopiowanie parametrów połączenia Zrzut ekranu przedstawiający pobieranie parametry połączenia dla usługi SignalR Service z punktem końcowym klienta.

  • Klonowanie repozytorium GitHub https://github.com/aspnet/AzureSignalR-samples

  • Przejdź do folderu samples/Chatroom:

  • Ustaw skopiowaną parametry połączenia i uruchom aplikację lokalnie, aby zobaczyć, że w ClientEndpoint sekcji ConnectionString znajduje się sekcja.

    cd samples/Chatroom
dotnet restore
dotnet user-secrets set Azure:SignalR:ConnectionString "<copied-connection-string-with-client-endpoint>"
dotnet run

  • Otwórz http://localhost:5000 plik z przeglądarki i użyj F12, aby wyświetlić ślady sieci. Zobaczysz, że połączenie protokołu WebSocket zostało nawiązane za pośrednictwem grupy dostępności AG1

    Zrzut ekranu przedstawiający uruchamianie aplikacji czatu lokalnie z usługą App Gateway i usługą SignalR Service.

Bezpieczna usługa SignalR Service

W poprzedniej sekcji pomyślnie skonfigurowaliśmy usługę SignalR Service jako usługę zaplecza usługi Application Gateway, możemy wywołać usługę SignalR Service bezpośrednio z sieci publicznej lub za pośrednictwem usługi Application Gateway.

W tej sekcji skonfigurujemy usługę SignalR Service tak, aby blokowała cały ruch z sieci publicznej i akceptowała tylko ruch z usługi Application Gateway.

Konfigurowanie usługi SignalR Service

Skonfigurujmy usługę SignalR Service tak, aby zezwalała tylko na dostęp prywatny. Więcej szczegółów można znaleźć w artykule Use private endpoint for SignalR Service (Używanie prywatnego punktu końcowego dla usługi SignalR Service).

  • Przejdź do wystąpienia usługi SignalR Service ASRS1 w portalu.

  • Przejdź do karty Sieć :

    • Na karcie Dostęp publiczny: Zmiana dostępu do sieci publicznej na Wyłączone i Zapisz, teraz nie możesz już uzyskać dostępu do usługi SignalR Service z sieci publicznej

      Zrzut ekranu przedstawiający wyłączanie dostępu publicznego dla usługi SignalR Service.

    • Na karcie Dostęp prywatny wybierz pozycję + Prywatny punkt końcowy:

      • Na karcie Podstawy :
        • Nazwa: PE1
        • Nazwa interfejsu sieciowego: PE1-nic
        • Region: upewnij się, że wybrano ten sam region co usługa Application Gateway
        • Wybierz pozycję Dalej: zasoby
      • Na karcie Zasoby
        • Zachowaj wartości domyślne
        • Wybierz pozycję Dalej: Sieć wirtualna
      • Na karcie Sieć wirtualna
        • Sieć wirtualna: wybierz wcześniej utworzoną sieć VN1
        • Podsieć: wybierz wcześniej utworzoną sieć VN1/myBackendSubnet
        • Inne zachowują ustawienia domyślne
        • Wybierz pozycję Dalej: DNS
      • Na karcie DNS
        • Integracja z prywatną strefą DNS: Tak
      • Przeglądanie i tworzenie prywatnego punktu końcowego

Odświeżanie puli zaplecza usługi Application Gateway

Ponieważ usługa Application Gateway została skonfigurowana przed użyciem prywatnego punktu końcowego, musimy odświeżyć pulę zaplecza, aby przyjrzeć się strefie Prywatna strefa DNS i ustalić, że powinien kierować ruch do prywatnego punktu końcowego zamiast adresu publicznego. Odświeżamy, ustawiając nazwę FQDN zaplecza na inną wartość, a następnie zmieniając ją z powrotem.

Przejdź do karty Pule zaplecza dla grupy DOSTĘPNOŚCI 1 i wybierz pozycję signalr:

  • Krok 1. Zmień wartość docelową asrs1.service.signalr.net na inną wartość, x.service.signalr.netna przykład , i wybierz pozycję Zapisz
  • Krok2. Zmień element docelowy z powrotem na asrs1.service.signalr.net

Szybki test

  • Teraz odwiedźmy https://asrs1.service.signalr.net/client ponownie. Gdy dostęp publiczny jest wyłączony, zwraca wartość 403 .

    curl -v https://asrs1.service.signalr.net/client

    zwraca

    < HTTP/1.1 403 Forbidden

  • Odwiedź punkt końcowy za pośrednictwem grupy DOSTĘPNOŚCI1 http://<frontend-public-IP-address>/clienti zwraca 400 z komunikatem o błędzie "hub" parametr zapytania jest wymagany. Oznacza to, że żądanie pomyślnie przeszedł przez usługę Application Gateway do usługi SignalR Service.

    curl -I http://<frontend-public-IP-address>/client

    zwraca

    < HTTP/1.1 400 Bad Request
< ...
<
'hub' query parameter is required.

Teraz, jeśli ponownie uruchomisz aplikację czatu, zobaczysz komunikaty Failed to connect to .... The server returned status code '403' when status code '101' was expected.o błędach , ponieważ dostęp publiczny jest wyłączony, aby połączenia serwera localhost mogły dłużej łączyć się z usługą SignalR.

Wdróżmy aplikację Czat w tej samej sieci wirtualnej z usługą ASRS1, aby czat mógł komunikować się z usługą ASRS1.

Wdrażanie aplikacji czatu na platformie Azure

  • W witrynie Azure Portal wyszukaj pozycję App Services i Utwórz aplikację internetową.

  • Na karcie Podstawowe użyj tych wartości dla następujących ustawień aplikacji internetowej:

    • Subskrypcja i grupa zasobów i region: tak samo jak w przypadku usługi SignalR Service
    • Nazwa: WA1
    • Publikowanie: kod
    • Stos środowiska uruchomieniowego: .NET 6 (LTS)
    • System operacyjny: Linux
    • Region: upewnij się, że jest on taki sam jak wybrany dla usługi SignalR Service
    • Wybierz pozycję Dalej: Wdrożenie, zachowaj wszystko jako domyślne, a następnie wybierz pozycję Dalej:Sieć

  • Na karcie Sieć

    • Włącz iniekcję sieci: wybierz pozycję Włączone
    • Sieć wirtualna: wybierz pozycję VN1 , która została wcześniej utworzona
    • Włączanie integracji z siecią wirtualną: włączone
    • Podsieć ruchu wychodzącego: utwórz nową podsieć
    • Wybierz pozycję Przejrzyj i utwórz

Teraz wdrożymy naszą aplikację czatu na platformie Azure. Poniżej

Używamy interfejsu wiersza polecenia platformy Azure do wdrażania naszej aplikacji czatu na platformie Azure. Zapoznaj się z przewodnikiem Szybki start: wdrażanie aplikacji internetowej ASP.NET dla innych środowisk wdrażania wdrożonych na platformie Azure.

W obszarze przykłady folderów/Chatroom uruchom poniższe polecenia:

# Build and publish the assemblies to publish folder
dotnet publish --os linux -o publish
# zip the publish folder as app.zip
cd publish
zip -r app.zip .
# use az CLI to deploy app.zip to our webapp
az login
az account set -s <your-subscription-name-used-to-create-WA1>
az webapp deploy -g <resource-group-of-WA1> -n WA1 --src-path app.zip

Teraz aplikacja internetowa jest wdrażana, przejdźmy do portalu dla usługi WA1 i wprowadźmy następujące aktualizacje:

  • Na karcie Konfiguracja:

    • Nowe ustawienia aplikacji:

      Nazwa/nazwisko Wartość
      WEBSITE_DNS_SERVER 168.63.129.16
      WEBSITE_VNET_ROUTE_ALL 1

    • Nowe parametry połączenia:

      Nazwa/nazwisko Wartość Typ
      Azure SignalRConnectionString Skopiowana parametry połączenia z wartością ClientEndpoint wybieranie pozycji Niestandardowe

    Zrzut ekranu przedstawiający konfigurowanie parametry połączenia aplikacji internetowej.

  • Na karcie Ustawienia protokołu TLS/SSL:

    • Tylko https: wyłączone. Aby uprościć pokaz, użyliśmy protokołu frontonu HTTP w usłudze Application Gateway. W związku z tym należy wyłączyć tę opcję, aby uniknąć automatycznego zmieniania adresu URL HTTP na adresy HTTPs.

  • Przejdź do karty Przegląd i uzyskaj adres URL aplikacji WA1.

  • Pobierz adres URL i zastąp schemat https ciągiem http, http://wa1.azurewebsites.netna przykład , otwórz adres URL w przeglądarce, a teraz możesz rozpocząć czatowanie! Użyj F12, aby otworzyć ślady sieci i zobaczyć, że połączenie usługi SignalR jest ustanawiane za pośrednictwem grupy dostępności AG1.

    Uwaga

    Czasami należy wyłączyć automatyczne przekierowywanie https przeglądarki i pamięć podręczną przeglądarki, aby zapobiec automatycznemu przekierowywaniu adresu URL do protokołu HTTPS.

    Zrzut ekranu przedstawiający uruchamianie aplikacji czatu na platformie Azure z usługą App Gateway i usługą SignalR Service.

Następne kroki

Teraz udało Ci się utworzyć aplikację czatu w czasie rzeczywistym z usługą SignalR Service i używać usługi Application Gateway do ochrony aplikacji i konfigurowania kompleksowego zabezpieczeń. Dowiedz się więcej o usłudze SignalR Service.