Web Application Server und Websockets

[truetone]

Hallo zusammen,

ich habe eine Website die WebSockets braucht über das Protokoll wss://

Intern im Netz klappt das prima, keine Probleme. Die Seite soll nun extern erreichbar sein, weshalb ich auf unseren Web Application Proxys (Windows Server 2016 Datacenter) eine Veröffentlichung dafür erstellt habe.
Die WAPs stehen in der DMZ, der Server im internen Netz. Dazwischen liegen 2 Firewalls, die Port 80 und 443 offen haben.

Die Website ist von außen nun problemlos erreichbar aber der WebSocket funktioniert nicht. In der Konsole sehe ich immer folgenden Fehler der mich nicht weiter bringt:

Auch im Reiter Netzwerk sieht man, dass nichts zurück kommt:

Um auszuschließen, dass die Firewall da rein spuckt, habe ich die Website vom WAP selbst mal aufgerufen. Hier klappt es direkt, da hier natürlich nicht über die Webveröffentlichung gegangen wird sondern der Server ja direkt angesprochen über die Firewall.
Die Windows-Firewall habe ich ebenfalls mal testweise deaktiviert, die scheint auch keine Rolle zu spielen.

Im IIS ist das Feature Websocket installiert und für die Default-Seite auch aktiviert.

Hat jemand einen Tipp, was ich noch machen muss, damit die Verbindung sauber aufgebaut werden kann?
Muss man explizit wss:// noch irgendwo freigeben? In der Remotezugriffsverwaltung kann man ja nicht sonderlich viel einstellen.

Danke für Tipps!

 

[scooter010]

Ich denke, das Problem hat vielleicht nichts mit der Firewall zu tun. Gibt die Applikation die korrekten öffentlichen Adressen raus und ist ein ggf. vorhandener Web-Proxy als trusted konfiguriert?

 

[truetone]

Das System arbeitet ausschließlich mit einer einzigen Domain, die intern und öffentlich die selbe ist. Die passen auch alle, genau wie das Protokoll (https mit http/2).
In der Anwendung gibt es keine trusted Proxys. Das habe ich auch schon geprüft. Laut Hersteller reicht eine einfache Reverse Proxy Einstellung. In den Beispielen wird immer von ngins als Reverse Proxy ausgegangen. Aber der Web Application Proxy von Microsoft macht da ja nicht viel anders.

 

[wirelessy]

Nicht jeder Proxy kann WebSockets. Welche Software nutzt du denn als Proxy?

//edit: https://www.oxygenxml.com/doc/versions/24.1.0/ug-waCustom/topics/WA-websocket.html

 

[truetone]

Nicht jeder Proxy kann WebSockets. Welche Software nutzt du denn als Proxy?

Das ist eine Rolle von Windows Server selbst, die nennt sich Remotezugriffsverwaltung. Den nutzt man sehr häufig, wenn man Exchange Server betreibt. Laut Microsoft kann der das schon seit Server 2012

 

[scooter010]

Web Application Proxy von Microsoft

Wenn ein Web-App-Proxy keine Sockets kann... OK, ist Microsoft, kostet vielleicht extra oder ist ein definiertes Feature.

 

[wirelessy]

Wird dann wohl IIS sein. Schau mal den Link von mir oben an.

//e: "Remotezugriffsverwaltung" ist eine andere Rolle/Funktion, die hier mutmaßlich völlig irrelevant ist.

//e2: Oh, scheinbar nicht. Habe es mit RSAT gleichgesetzt.

 

[truetone]

Doch das passt, ist der Webanwendungsproxy.
Den Link kenne ich schon, das habe ich schon 3x geprüft. Auch in der Config-Datei übernimmt er das sauber. Den ganzen Server danach neu gestartet aber er lässt kein wss:// durch

 

[wirelessy]

Kannst du Screenshots von deiner Umsetzung dieser zwei Schritte zeigen?

Ergänzung (28. Mai 2024)

https://serverfault.com/questions/1037407/websocket-based-website-behind-a-reverse-proxy-in-iis

Hier noch ein Problem, weil IIS wohl n bestimmtes Feature nicht kann: https://stackoverflow.com/questions/38933815/iis-8-websockets-with-permessage-deflate

 

[truetone]

Hier meine Konfiguration von der Variable. Wobei ich mir gerade nicht mal sicher bin, ob der IIS da etwas mit zu tun hat. Wenn ich die Default Website mal beende, geht trotzdem alles. Also scheint der da gar nicht so involviert zu sein oder?

 

[wirelessy]

Microsoft hat nicht wirklich andere Webserver im Angebot.
TMG (davon wüsstest du) oder Kestrel (relativ .NET spezifisch). Ich bin 99% sicher, dass es IIS ist.
Die Default-Website ist aber nicht zwangweise deine Proxy-Route.

Hast du die Inbound Rule von g) konfiguriert?
Habe gerade keinen Windows Server zum selbst testen da leider.

Du kannst den kompletten Service stoppen, und schauen ob es was ändert.

 

[truetone]

Ja, das ist das aus dem Post #10 oder?
Also ich klicke links auf den Haupt IIS Knoten, worunter dann halt Anwendungspools und die Sites fallen. Dort habe ich als Features URL-Rewrite ausgewählt und rechts auf Server variables. Oder übersehe ich da etwas?

 

[wirelessy]

https://www.msxfaq.de/internet/wap.htm

"Der neue Web Application Proxy stellt eine Teilmenge der TMG Webveröffentlichung dar"

Spannend. Ich würd den WAP weglassen, und es einfach per IIS machen. Oder nginx.

Ergänzung (28. Mai 2024)

Gerade gesehen, es ist tatsächlich ein standalone service, kein ISS feature.
WAP scheint mir nicht das richtige Werkzeug zu sein, das zielt sehr auf ADFS-Integration ab.

 

[truetone]

Ach okay, da bringst du mich auf eine Idee...
Habe gerade mal eine neue IIS Website erstellt und per SNI auf die Test-Domain gelegt. Nun sehe ich die Website vom IIS (die Testseite). Dann muss ich da drüber gehen anstatt das mit dem Anwendungsproxy zu machen. Wobei ich den Unterschied noch nicht ganz verstehe, was der Anwendungsproxy da anders macht als als Reverse Proxy zu fungieren und die Anfragen stumpf an das ziel weiterzuleiten.

Danke für die Hilfe, da probiere ich morgen mal in Ruhe mit rum, vielleicht ist das der richtige Weg.

 

[wirelessy]

Mit IIS gehts, gerade getestet:

 

[truetone]

Danke für die super Hilfe, das bringt mich weiter!

Mit der Konfiguration klappt es tatsächlich nun! <3
Man muss gar nicht mit dem Web Application Proxy (Remotezugriffsverwaltung) arbeiten, es reicht hier vollkommen aus, nur im IIS eine Seite zu erstellen und dann die URL Rewrite zu konfigurieren wie du beschrieben hast.

Ganz herzlichen Dank!

Ergänzung (29. Mai 2024)

Was mir gerade bei dem 2. und 3. Host noch aufgefallen ist, wo ich das konfiguriere:
Man muss die Servervariable HTTP_SEC_WEBSOCKET_EXTENSIONS auch global hinzufügen, sonst geht es nicht.
Das heißt: Einmal natürlich das Feature Websockets installieren über den Server-Manager, dann im IIS-Manager links in der Navigation den Hauptknoten anklicken (Servername, direkt unter den Punkt Startseite) und dann über URL Rewrite rechts eine neue Variable hinzufügen. Erst dann greift auch die Variable in der Inbound Rule der eigenen Regel beim jeweiligen Host. Zu sehen in meinem Post 12

Vielen Dank nochmals! 😍

 

[wirelessy]

So, wie von mir hinterfragt vorher.
"Wo isn deine Config von g)"

Aber ist doch super so!