☰

Aktivieren von WebSockets (SignalR) mit einem Barracuda WAF

tag-icon • tag-icon iis websocket barracuda web-application-firewall
Aktivieren von WebSockets (SignalR) mit einem Barracuda WAF

Ich reiße mir derzeit bei der Arbeit die Haare aus, weil ich versuche, ein Problem mit einer Webanwendung zu lösen, die SignalR über WebSockets verwendet, wobei der Datenverkehr durch eine Barracuda Web Application Firewall (WAF) geleitet wird. Jeder Versuch, signalr/connectüber WebSockets eine Verbindung zum Endpunkt herzustellen, schlägt mit einer 400 Bad Request fehl. Die Verbindung wird dann auf WebServer-Polling zurückgesetzt, was zwar funktioniert, aber nicht das ist, was wir wollen.

Die gestellten Anfragen werden an unsere Barracuda Web Application Firewall gesendet und dann an unsere IIS-Webserver mit Lastenausgleich weitergeleitet. Wir verwenden IIS 8.5 auf Windows Server 2012R2 und die Anwendung ist eine .Net 4.6.2-Webanwendung.

Das gleiche Setup (ohne Verwendung eines Barracuda WAF) funktioniert problemlos.

Bisher habe ich

Aktivierte Websockets im WAF gemäß diesem Artikelhttps://campus.barracuda.com/product/webapplicationfirewall/doc/49054741/how-to-enable-websocket. Ich bekomme immer noch denselben 400-Fehler.

Überprüft, um sicherzustellen, dass die WebSocketFunktion auf meinen IIS-Servern aktiviert ist.

SignalR-Debugging/Tracing in der Web.Config aktiviert, wie inhttps://docs.microsoft.com/en-us/aspnet/signalr/overview/testing-and-debugging/enabling-signalr-tracingDies führt zu Protokolldateien, weist aber nicht auf Fehler hin.

Ich bin nicht sicher, was ich sonst noch überprüfen soll?

Antwort1

So, ich habe mein Problem herausgefunden. Ich habe herausgefunden, dass wir unseren Datenverkehr eigentlich zuerst über einen Azure Load Balancer an unsere WAF senden. Wenn ich die Header in den WAF-Zugriffsprotokollen auslogge, kann ich sehen, dass der ConnectionHeader keinen Wert hat, was mein Client, wie ich weiß, als sendet Upgrade.

Es scheint ein Problem bei der Verwendung eines Azure Load Balancers zu sein. Daher untersuche ich stattdessen die Verwendung eines Azure Application Gateways.

Im Moment kann ich dies jedoch zum Laufen bringen, indem ich die WAF den ConnectionHeader für mich hinzufügen lasse, indem ich eine Regel zum Umschreiben des Headers konfiguriere, um diesen Header an meine IIS-Server zu senden.

Erforderliche Header für WebSockets

Connection: Upgrade Upgrade: websockets

  1. Öffnen Sie die Barracuda WAF-Verwaltungssite.
  2. Zur Website -> Website-Übersetzungen

  3. Fügen Sie unter „HTTP Request Rewrite“ eine neue Rewrite-Regel hinzu …

    1. Geben Sie einen Regelnamen an.
    2. Legen Sie eine Sequenznummer fest.
    3. Wählen Sie „Header neu schreiben“ als Aktion aus.
    4. Geben Sie „Verbindung“ als Header-Namen ein.
    5. Verwenden Sie * als alten Wert, der alle Werte ersetzt.
    6. Geben Sie als Rewrite-Wert „Upgrade“ ein, damit dieser stattdessen gesendet wird.
    7. Verwenden Sie es Header Upgrade eq websocketals Umschreibebedingung. Dadurch wird die Regel nur angewendet, wenn der UpgradeHeader den Wert enthält websocket.
    8. Klicken Sie auf „Hinzufügen“.

Jetzt versuche ich, die Anwendung erneut zu laden, und bumm, die Verbindung zu /signalr/connect mit WebSockets-Transport ist erfolgreich!

Weitere Informationen finden Sie auf meinerBlogeintrag

verwandte Informationen