Come usare Servizio Azure SignalR con app Azure lication Gateway

Il gateway applicazione è un servizio di bilanciamento del carico del traffico Web che consente di gestire il traffico verso le applicazioni Web. L'uso di gateway applicazione con Servizio SignalR consente di eseguire le operazioni seguenti:

• Proteggere le applicazioni da vulnerabilità Web comuni.
• Ottenere il bilanciamento del carico a livello di applicazione per le applicazioni scalabili e a disponibilità elevata.
• Configurare la sicurezza end-to-end.
• Personalizzare il nome di dominio.

Questo articolo contiene due parti,

• La prima parte illustra come configurare gateway applicazione in modo che i client possano accedere a SignalR tramite gateway applicazione.
• La seconda parte illustra come proteggere Servizio SignalR aggiungendo il controllo di accesso a Servizio SignalR e consentire solo il traffico da gateway applicazione.

Le stringa di connessione non elaborate vengono visualizzate in questo articolo solo a scopo dimostrativo. Negli ambienti di produzione proteggere sempre le chiavi di accesso. Usare Azure Key Vault per gestire e ruotare le chiavi in modo sicuro e proteggere i stringa di connessione usando Microsoft Entra ID e autorizzare l'accesso con Microsoft Entra ID.

Impostare e configurare il gateway applicazione

Creare un'istanza di Servizio SignalR

• Seguire l'articolo e creare un'istanza di Servizio SignalR ASRS1

Creare un'istanza di gateway applicazione

Creare dal portale un'istanza gateway applicazione AG1:

• Nella portale di Azure cercare gateway applicazione e Crea.

• Nella scheda Informazioni di base usare questi valori per le impostazioni del gateway applicazione seguenti:

  • Sottoscrizione e gruppo di risorse e area: uguale a quello scelto per Servizio SignalR

  • Nome del gateway applicazione: AG1

  • Rete virtuale, selezionare Crea nuovo e nella finestra Crea rete virtuale visualizzata immettere i valori seguenti per creare la rete virtuale e due subnet, una per il gateway applicazione e un'altra per i server back-end.

    • Nome: immettere VN1 come nome della rete virtuale.

    • Subnet: aggiornare la griglia Subnet con sotto 2 subnet

      Nome subnet	Intervallo di indirizzi	Nota
      myAGSubnet	(intervallo di indirizzi)	Subnet per il gateway applicazione. La subnet del gateway applicazione può contenere solo i gateway applicazione. Non sono consentite altre risorse.
      myBackendSubnet	(un altro intervallo di indirizzi)	Subnet per l'istanza di Azure SignalR.

  • Accettare i valori predefiniti per le altre impostazioni e quindi selezionare Avanti: Front-end

• Nella scheda Front-end:

  • Tipo di indirizzo IP front-end: pubblico.
  • Scegliere Aggiungi nuovo per Indirizzo IP pubblico e immettere myAGPublicIPAddress per il nome dell'indirizzo IP pubblico, quindi selezionare OK.
  • Selezionare Avanti: Back-end

• Nella scheda Back-end selezionare Aggiungi un pool back-end:

  • Nome: immettere signalr per il pool back-end di risorse Servizio SignalR.
  • Destinazione back-end: nome host dell'istanza di Servizio SignalR ASRS1, ad esempioasrs1.service.signalr.net
  • Selezionare Avanti: Configurazione

  

• Nella scheda Configurazione selezionare Aggiungi una regola di routing nella colonna Regole di routing:

  • Nome regola: myRoutingRule

  • Priorità: 1

  • Nella scheda Listener nella finestra Aggiungi una regola di routing immettere i valori seguenti per il listener:

    • Nome listener: immettere myListener come nome del listener.
    • IP front-end: selezionare Pubblico per scegliere l'indirizzo IP pubblico creato per il front-end.
    • Protocollo: HTTP
      • In questo articolo viene usato il protocollo front-end HTTP in gateway applicazione per semplificare la demo e facilitare l'avvio. In realtà, tuttavia, potrebbe essere necessario abilitare ITTP e il dominio del cliente con lo scenario di produzione.
    • Accettare i valori predefiniti per le altre impostazioni nella scheda Listener

  • Nella scheda Destinazioni back-end usare i valori seguenti:

    • Tipo di destinazione: Pool back-end

    • Destinazione back-end: selezionare signalr creato in precedenza

    • Impostazioni back-end: selezionare Aggiungi nuovo per aggiungere una nuova impostazione.

      • Nome delle impostazioni back-end: mySetting
      • Protocollo back-end: HTTPS
      • Usare un certificato CA noto: Sì
      • Eseguire l'override con il nuovo nome host: Sì
      • Override del nome host: selezionare il nome host dalla destinazione back-end
      • Altri mantengono i valori predefiniti

      

    

• Esaminare e creare il gruppo di disponibilità1

Configurare gateway applicazione probe di integrità

Quando viene creato AG1 , passare alla scheda Probe di integrità nella sezione Impostazioni del portale, modificare il percorso del probe di integrità in /api/health

Test rapido

• Provare con una richiesta https://asrs1.service.signalr.net/client client non valida e restituisce 400 con il messaggio di errore 'hub' parametro di query obbligatorio. Significa che la richiesta è arrivata al Servizio SignalR e ha eseguito la convalida della richiesta.

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

  restituisce

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

• Passare alla scheda Panoramica di AG1 e individuare l'indirizzo IP pubblico front-end

  

• Visitare l'endpoint di integrità tramite AG1 http://<frontend-public-IP-address>/client e restituisce anche 400 con il messaggio di errore 'hub' parametro di query obbligatorio. Significa che la richiesta è stata eseguita correttamente gateway applicazione a Servizio SignalR e ha eseguito la convalida della richiesta.

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

  restituisce

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

Eseguire la chat tramite gateway applicazione

Il traffico può ora raggiungere Servizio SignalR attraverso il gateway applicazione. Il cliente può usare l'indirizzo IP pubblico gateway applicazione o il nome di dominio personalizzato per accedere alla risorsa. Si userà questa applicazione di chat come esempio. Iniziamo con l'esecuzione in locale.

Le stringa di connessione non elaborate vengono visualizzate in questo articolo solo a scopo dimostrativo. Negli ambienti di produzione proteggere sempre le chiavi di accesso. Usare Azure Key Vault per gestire e ruotare le chiavi in modo sicuro e proteggere i stringa di connessione usando Microsoft Entra ID e autorizzare l'accesso con Microsoft Entra ID.

• Prima di tutto, ottenere il stringa di connessione di ASRS1

  • Nella scheda Stringhe di connessione di ASRS1
    • Endpoint client: immettere l'URL usando l'indirizzo IP pubblico front-end di AG1, ad esempio http://20.88.8.8. Si tratta di un generatore di stringa di connessione quando si usano proxy inversi e il valore non viene mantenuto quando si torna a questa scheda. Quando viene immesso un valore, il stringa di connessione aggiunge una ClientEndpoint sezione.
    • Copiare la stringa di connessione

• Clonare il repository GitHub https://github.com/aspnet/AzureSignalR-samples

• Passare alla cartella samples/Chatroom:

• Impostare il stringa di connessione copiato ed eseguire l'applicazione in locale, si noterà che è presente una ClientEndpoint sezione in ConnectionString.

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

• Aprire http://localhost:5000 dal browser e usare F12 per visualizzare le tracce di rete, si noterà che la connessione WebSocket viene stabilita tramite AG1

  

Servizio SignalR sicuro

Nella sezione precedente è stata configurata correttamente Servizio SignalR come servizio back-end di gateway applicazione, è possibile chiamare Servizio SignalR direttamente dalla rete pubblica o tramite gateway applicazione.

In questa sezione si configurerà Servizio SignalR per negare tutto il traffico dalla rete pubblica e accettare solo il traffico da gateway applicazione.

Configurare Servizio SignalR

Configurare Servizio SignalR per consentire solo l'accesso privato. Per altre informazioni, vedere Usare l'endpoint privato per Servizio SignalR.

• Passare all'istanza di Servizio SignalR ASRS1 nel portale.

• Passare alla scheda Rete :

  • Nella scheda Accesso pubblico: l'accesso alla rete pubblica passa a Disabilitato e Salva, ora non è più possibile accedere alle Servizio SignalR dalla rete pubblica

    

  • Nella scheda Accesso privato selezionare + Endpoint privato:

    • Nella scheda Informazioni di base:
      • Nome: PE1
      • Nome interfaccia di rete: PE1-nic
      • Area: assicurarsi di scegliere la stessa area del gateway applicazione
      • Selezionare Avanti: Risorse
    • Nella scheda Risorse
      • Mantenere i valori predefiniti
      • Selezionare Avanti: Rete virtuale
    • Nella scheda Rete virtuale
      • Rete virtuale: selezionare VN1 creato in precedenza
      • Subnet: selezionare VN1/myBackendSubnet creato in precedenza
      • Altri mantengono le impostazioni predefinite
      • Selezionare Avanti: DNS
    • Nella scheda DNS
      • Integrazione con la zona DNS privata: Sì
    • Esaminare e creare l'endpoint privato

Aggiornare gateway applicazione pool back-end

Poiché gateway applicazione è stato configurato prima dell'uso di un endpoint privato, è necessario aggiornare il pool back-end per esaminare la zona DNS privato e capire che deve instradare il traffico all'endpoint privato anziché all'indirizzo pubblico. Per eseguire l'aggiornamento, impostare il nome di dominio completo back-end su un altro valore e quindi modificarlo di nuovo.

Passare alla scheda Pool back-end per AG1 e selezionare Signalr:

• Passaggio 1: modificare Target asrs1.service.signalr.net in un altro valore, x.service.signalr.netad esempio , e selezionare Salva
• Passaggio 2: ripristinare Target in asrs1.service.signalr.net

Test rapido

• Ora torniamo a visitare https://asrs1.service.signalr.net/client di nuovo. Con l'accesso pubblico disabilitato, restituisce invece 403 .

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

  restituisce

  < HTTP/1.1 403 Forbidden
  

• Visitare l'endpoint tramite AG1http://<frontend-public-IP-address>/cliente restituisce 400 con il messaggio di errore 'hub' parametro di query obbligatorio. Significa che la richiesta ha eseguito correttamente il gateway applicazione per Servizio SignalR.

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

  restituisce

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

Ora, se si esegue nuovamente l'applicazione Chat in locale, verranno visualizzati i messaggi Failed to connect to .... The server returned status code '403' when status code '101' was expected.di errore , perché l'accesso pubblico è disabilitato in modo che le connessioni al server localhost siano più in grado di connettersi al servizio SignalR.

Distribuire l'applicazione Chat nella stessa rete virtuale con ASRS1 in modo che la chat possa comunicare con ASRS1.

Distribuire l'applicazione chat in Azure

• Nella portale di Azure cercare Servizi app e Creaapp Web.

• Nella scheda Informazioni di base usare questi valori per le impostazioni dell'app Web seguenti:

  • Sottoscrizione e gruppo di risorse e area: uguale a quello scelto per Servizio SignalR
  • Nome: WA1
  • Pubblica: codice
  • Stack di runtime: .NET 6 (LTS)
  • Sistema operativo: Linux
  • Area: assicurarsi che sia uguale a quello scelto per Servizio SignalR
  • Selezionare Avanti: Distribuzione, mantenere tutto come predefinito e selezionare Avanti:Rete

• Nella scheda Rete

  • Abilita inserimento di rete: selezionare Sì
  • Rete virtuale: selezionare VN1 creato in precedenza
  • Abilitare l'integrazione della rete virtuale: Attivato
  • Subnet in uscita: creare una nuova subnet
  • Selezionare Rivedi e crea

A questo punto si distribuirà l'applicazione chat in Azure. Below

L'interfaccia della riga di comando di Azure viene usata per distribuire l'applicazione chat in Azure. Vedere Avvio rapido: Distribuire un'app Web ASP.NET per altri ambienti di distribuzione che distribuiscono in Azure.

In Esempi di cartella/Chatroom eseguire i comandi seguenti:

# 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

A questo punto l'app Web viene distribuita, passare al portale per WA1 e apportare gli aggiornamenti seguenti:

• Nella scheda Configurazione:

  • Nuove impostazioni dell'applicazione:

    Nome	Valore
    WEBSITE_DNS_SERVER	168.63.129.16
    WEBSITE_VNET_ROUTE_ALL	1

  • Nuovo stringa di connessione:

    Nome	valore	Type
    ConnectionString di AzureSignalR	Il stringa di connessione copiato con il valore ClientEndpoint	Selezionare Personalizzato

  

• Nella scheda Impostazioni TLS/SSL:

  • Solo HTTPS: disattivato. Per semplificare la demo, è stato usato il protocollo front-end HTTP in gateway applicazione. È quindi necessario disattivare questa opzione per evitare di modificare automaticamente l'URL HTTP in HTTPs.

• Passare alla scheda Panoramica e ottenere l'URL di WA1.

• Ottenere l'URL e sostituire lo schema https con http, ad esempio , http://wa1.azurewebsites.netaprire l'URL nel browser, ora è possibile iniziare a chattare! Usare F12 per aprire le tracce di rete ed è possibile vedere che la connessione SignalR viene stabilita tramite AG1.

  Nota

  A volte è necessario disabilitare il reindirizzamento automatico https del browser e la cache del browser per impedire che l'URL venga reindirizzato automaticamente a HTTPS.

  

Passaggi successivi

A questo punto, è stata creata correttamente un'applicazione di chat in tempo reale con Servizio SignalR e è stata usata gateway applicazione per proteggere le applicazioni e configurare la sicurezza end-to-end. Altre informazioni sulle Servizio SignalR.