Delen via

Azure SignalR integreren met omgekeerde proxy's

  • Artikel

Een omgekeerde proxyserver kan worden gebruikt vóór Azure SignalR Service. Omgekeerde proxyservers bevinden zich tussen de clients en de Azure SignalR-service en andere services kunnen in verschillende scenario's helpen. Omgekeerde proxyservers kunnen bijvoorbeeld taken verdelen over verschillende clientaanvragen naar verschillende back-endservices, u kunt meestal verschillende routeringsregels configureren voor verschillende clientaanvragen en naadloze gebruikerservaring bieden voor gebruikers die toegang hebben tot verschillende back-endservices. Ze kunnen uw back-endservers ook beschermen tegen veelvoorkomende beveiligingsproblemen met gecentraliseerd beveiligingsbeheer. Services zoals Azure-toepassing Gateway, Azure API Management of Akamai kunnen fungeren als omgekeerde proxyservers.

Een algemene architectuur die gebruikmaakt van een reverse proxy-server met Azure SignalR, is zoals hieronder:

Diagram met de architectuur met behulp van Azure SignalR met een omgekeerde proxyserver.

Belangrijk

Onbewerkte verbindingsreeks worden alleen in dit artikel weergegeven voor demonstratiedoeleinden.

Een verbindingsreeks bevat de autorisatiegegevens die nodig zijn voor uw toepassing om toegang te krijgen tot Azure SignalR Service. De toegangssleutel in de verbindingsreeks is vergelijkbaar met een hoofdwachtwoord voor uw service. Beveilig uw toegangssleutels altijd in productieomgevingen. Gebruik Azure Key Vault om uw sleutels veilig te beheren en te roteren en uw verbindingsreeks te beveiligen met behulp van Microsoft Entra-id en toegang te autoriseren met Microsoft Entra ID.

Vermijd het distribueren van toegangssleutels naar andere gebruikers, het coderen ervan of het opslaan van ze ergens in tekst zonder opmaak die toegankelijk is voor anderen. Draai uw sleutels als u denkt dat ze mogelijk zijn aangetast.

Algemene procedures

Er zijn verschillende algemene procedures die moeten worden gevolgd bij het gebruik van een omgekeerde proxy vóór SignalR Service.

Onbewerkte verbindingsreeks worden alleen in dit artikel weergegeven voor demonstratiedoeleinden. Beveilig uw toegangssleutels altijd in productieomgevingen. Gebruik Azure Key Vault om uw sleutels veilig te beheren en te roteren en uw verbindingsreeks te beveiligen met behulp van Microsoft Entra-id en toegang te autoriseren met Microsoft Entra ID.

  • Zorg ervoor dat u de binnenkomende HTTP HOST-header herschrijft met de URL van de Azure SignalR-service, bijvoorbeeldhttps://demo.service.signalr.net. Azure SignalR is een service met meerdere tenants en is afhankelijk van de HOST header die moet worden omgezet naar het juiste eindpunt. Als u bijvoorbeeld Application Gateway voor Azure SignalR configureert, selecteert u Ja voor de optie Overschrijven met nieuwe hostnaam.

  • Wanneer uw client uw omgekeerde proxy doorloopt naar Azure SignalR, stelt u deze in ClientEndpoint als de URL van de omgekeerde proxy. Wanneer uw client onderhandelt met uw hubserver, retourneertde hubserver de URL die is gedefinieerd ClientEndpoint voor de client om verbinding te maken. Kijk hier voor meer informatie.

    Er zijn twee manieren om te configureren ClientEndpoint:

    • Voeg een ClientEndpoint sectie toe aan uw ConnectionString: Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • Configureren ClientEndpoint bij het aanroepen 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>")
        }
    };
})

  • Wanneer een client uw omgekeerde proxy doorloopt naar Azure SignalR, zijn er twee soorten aanvragen:

    • HTTP-postaanvraag waarnaar <reverse-proxy-URL>/client/negotiate/wordt aangeroepen als onderhandelingsaanvraag
    • WebSocket/SSE/LongPolling-verbindingsaanvraag, afhankelijk van uw transporttype waarnaar <reverse-proxy-URL>/client/we een verbindingsaanvraag aanroepen.

    Zorg ervoor dat uw omgekeerde proxy beide transporttypen voor /client/ subpad ondersteunt. Als uw transporttype bijvoorbeeld WebSocket is, moet u ervoor zorgen dat uw omgekeerde proxy zowel HTTP als WebSocket voor /client/ subpad ondersteunt.

    Als u meerdere SignalR-services achter uw omgekeerde proxy hebt geconfigureerd, moet u ervoor zorgen dat negotiate aanvragen en connect aanvragen met dezelfde asrs_request_id queryparameter (wat betekent dat ze voor dezelfde verbinding zijn) worden gerouteerd naar hetzelfde SignalR-service-exemplaar.

  • Wanneer omgekeerde proxy wordt gebruikt, kunt u uw SignalR-service verder beveiligen door openbare netwerktoegang uit te schakelen en privé-eindpunten te gebruiken om alleen persoonlijke toegang van uw omgekeerde proxy naar uw SignalR-service via VNet toe te staan.

Volgende stappen