Freigeben über

Integrieren von Azure SignalR in Reverseproxys

  • Artikel

Ein Reverseproxyserver kann vor Azure SignalR Service verwendet werden. Reverseproxyserver befinden sich zwischen den Clients und dem Azure SignalR-Dienst und anderen Diensten und können in verschiedenen Szenarien hilfreich sein. Reverseproxyserver können beispielsweise einen Lastenausgleich für unterschiedliche Clientanforderungen auf verschiedene Back-End-Dienste durchführen, Sie können in der Regel unterschiedliche Routingregeln für unterschiedliche Clientanforderungen konfigurieren und eine nahtlose Benutzerumgebung für Benutzer bereitstellen, die auf verschiedene Back-End-Dienste zugreifen. Mithilfe der zentralen Schutzsteuerung können Sie Ihre Back-End-Server auch vor gängigen Exploits schützen. Dienste wie Azure Application Gateway, Azure API Management oder Akamai können als Reverseproxyserver fungieren.

Nachstehend ist eine gängige Architektur mit einem Reverseproxyserver mit Azure SignalR aufgeführt:

Diagramm: Architektur mit Azure SignalR mit einem Reverseproxyserver

Wichtig

Unformatierte Verbindungszeichenfolgen werden in diesem Artikel nur zu Demonstrationszwecken angezeigt.

Eine Verbindungszeichenfolge enthält die Autorisierungsinformationen, die Ihre Anwendung für den Zugriff auf den Azure SignalR-Dienst benötigt. Der Zugriffsschlüssel in der Verbindungszeichenfolge ähnelt einem Stammkennwort für Ihren Dienst. Schützen Sie Ihre Zugriffsschlüssel in Produktionsumgebungen immer sorgfältig. Verwenden Sie Azure Key Vault, um Ihre Schlüssel sicher zu verwalten und zu rotieren, Ihre Verbindungszeichenfolge mithilfe von Microsoft Entra ID zu schützen und den Zugriff mit Microsoft Entra ID zu autorisieren.

Geben Sie Zugriffsschlüssel nicht an andere Benutzer weiter, vermeiden Sie das Hartcodieren, und speichern Sie die Schlüssel nicht als Klartext, auf den andere Benutzer Zugriff haben. Rotieren Sie die Schlüssel, wenn Sie glauben, dass sie möglicherweise gefährdet sind.

Allgemeine Methoden

Es gibt mehrere allgemeine Methoden, die Sie beim Verwenden eines Reverseproxys vor SignalR Service befolgen sollten.

Unformatierte Verbindungszeichenfolgen werden in diesem Artikel nur zu Demonstrationszwecken angezeigt. Schützen Sie Ihre Zugriffsschlüssel in Produktionsumgebungen immer sorgfältig. Verwenden Sie Azure Key Vault, um Ihre Schlüssel sicher zu verwalten und zu rotieren, Ihre Verbindungszeichenfolge mithilfe von Microsoft Entra ID zu schützen und den Zugriff mit Microsoft Entra ID zu autorisieren.

  • Achten Sie darauf, den eingehenden HTTP-HOST-Header mit der Azure SignalR Service-URL erneut zu generieren, z. B. https://demo.service.signalr.net. Azure SignalR ist ein mehrinstanzenfähiger Dienst, der die Auflösung in den richtigen Endpunkt über den HOST-Header durchführt. Wenn Sie z. B. Application Gateway für Azure SignalR konfigurieren, wählen Sie Ja für die Option Mit neuem Hostnamen überschreiben aus.

  • Wenn Ihr Client über Ihren Reverseproxy zu Azure SignalR gelangt, legen Sie ClientEndpoint als Reverseproxy-URL fest. Wenn Ihr Client mit Ihrem Hubserver verhandelt, gibt der Hubserver die URL zurück, die in ClientEndpoint für die Verbindungsherstellung des Clients definiert ist. Ausführlichere Informationen finden Sie hier.

    Es gibt zwei Möglichkeiten, ClientEndpoint zu konfigurieren:

    • Fügen Sie ConnectionString einen Abschnitt ClientEndpoint hinzu: Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • Konfigurieren Sie ClientEndpoint beim Aufrufen von 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>")
        }
    };
})

  • Wenn ein Client über Ihren Reverseproxy zu Azure SignalR gelangt, gibt es zwei Arten von Anforderungen:

    • HTTP-POST-Anforderung an <reverse-proxy-URL>/client/negotiate/, die als Aushandlungsanforderung aufgerufen wird.
    • WebSocket/SSE/LongPolling-Verbindungsanforderung abhängig von Ihrem Transporttyp für <reverse-proxy-URL>/client/, die als Verbindungsanforderung aufgerufen wird.

    Stellen Sie sicher, dass Ihr Reverseproxy beide Transporttypen für den /client/-Unterpfad unterstützt. Wenn beispielsweise WebSocket als Transporttyp verwendet wird, stellen Sie sicher, dass Ihr Reverseproxy sowohl HTTP als auch WebSocket für den /client/-Unterpfad unterstützt.

    Wenn Sie mehrere SignalR-Dienste hinter Ihrem Reverseproxy konfiguriert haben, stellen Sie sicher, dass die negotiate-Anforderung und die connect-Anforderung mit demselben asrs_request_id-Abfrageparameter (d. h. sie gelten für dieselbe Verbindung) an dieselbe SignalR Service-Instanz weitergeleitet werden.

  • Wenn ein Reverseproxy verwendet wird, können Sie Ihren SignalR-Dienst zusätzlich absichern, indem Sie den öffentlichen Netzwerkzugriff deaktivieren und private Endpunkte verwenden, um nur privaten Zugriff von Ihrem Reverseproxy auf Ihren SignalR-Dienst über VNet zuzulassen.

Nächste Schritte