[Frage] [V4.0 IP1] Reverse Proxy Konfig für NodeRed WebSocket

[Marinux]

Hallo,

ich kämpfe mit der Einstellung für WebSocket Unterstützung wenn ich den ReverseProxy für NodeRed nutzen möchte.

Dabei versuche ich den Dashboard Websocket für NodeRed der unter dem Pfad ws://Dashboard-IP:1880/ui/socket.io/ erreichbar ist über den Reverse Proxy einzubinden. Allerdings scheint "socket.io" nicht akzeptiert zu werden bei der Eingabe in die betreffenden zwei Input-Felder. Die Fehlermeldung, wie im Bild auch zu sehen, lautet: "Speichern nicht möglich. Alias für websocket invalid" Ich vermute es liegt am Punkt. Kann das jemand bestätigen oder mache ich bei der Einbindung was falsch?



Wenn ich WebSocket Reverse Proxying aktiviere ohne was in die Inputfelder zu hinterlegen, dann führt das leider auch nicht zum Erfolg.


Generell wird in allen Szenarien ein HTTP 400 Fehler erzeugt wenn das Dashboard eine Verbindung versucht zum WebSocket aufzumachen.

[Chris M.]

Ich hab mein NodeRED als Netzwerk "host" am laufen.


Und der Reverse Proxy sieht dann so aus:


Auf andere Art hab ich NodeRED nicht zum laufen bekommen. Und so läuft es nun schon seit langem und sehr stabil.

[gbglace]

Ich habe das mit den ganzen Proxy noch nie verstanden.

Mein NR Container läuft hier als MAC-VLAN und bisher funktioniert alles was ich damit anstellen wollte.

[Eraser]

Ich auch nicht
Mein NR-Container läuft sogar ohne Mac-VLAN

Kann jemand erklären, wo die Vorteile darin liegen zwischen den Varianten?
-) Ohne Mac-VLAN
-) Mit Mac-VLAN
-) Proxy

Danke

[Marinux]

@Chris M., dann hast du vermutlich keine WebSocket Unterstützung und das NodeRed fällt auf ein Polling des Servers zurück. Das ist sehr ineffizient. Du kannst das z.B. in den Developer Tools deines Browser sehen, dass in sehr kurzen Abständen Anfragen an den NodeRed Server gestellt werden. Wenn du das vergleichst mit dem Aufruf des Dashboards ohne Proxy, dann siehst du das nicht. Stattdessen öffnet sich am Anfang eine WebSocket Verbindung, die dann genutzt wird bidirektional Daten zu übertragen.

@gbglace, auch ich nutze MacVLAN, das ist für meine Frage aber m.E. irrelevant.

@gbglace @Eraser , der Vorteil des Reverse Proxies ist, dass NodeRed über HTTPS erreicht werden kann was sonst nicht der Fall ist. Ich binde z.B. TWS Grafana Dashboards in mein NodeRed Dashboard ein. Das führt dann in vielen Browser/Geräte Konstellationen zu Problemen, weil damit HTTP und HTTPS Inhalte vermengt werden.

[Eraser]

Und Mac-VLAN mit einer dedizierten IP für NR wird benötigt für den ReverseProxy wahrscheinlich oder?

[StefanW]

Hi Wolfgang,

nein. Das sind zwei verschiedene paar Stiefel.

Stell Dir einen Reverse-Proxy als jemanden vor, der für Dich surft, also alle Deine Klicks, die Du dem Proxy schickst, erkennst, der dann einen Browser bei sich aufmacht und nochmal klickt und das Ergebnis das er erhält, dann als "Screenshot" an Dich zurück schickt.

Ein Reverse Proxy surft für Dich. Er ist Webserver und "Browser" in einem. Dem eigentlich angesprochenen Server, z.B. Node Red erscheint es, als würde der proxy des TWS bei ihm surfen (also von der IP her). Deinem Browser erscheint es so, als würde er nur mit dem Proxy sprechen (von der IP her). Der Proxy übersetzt transparent zwischen beiden hin und her.

Der Vorteil besteht darin, dass der Proxy hierbei eine TLS-Verbindung zur Deinem Browser aufbaut (während die Verbindung des Proxys zum eigentlichen Server unverschlüsselt sein kann) und eine mögliche Impersonation (also Anmeldung, das nutzen wir bei Grafana, da wirst automatisch angemeldet vom Proxy) und dafür, dass damit IPs genutzt werden können, die ansonsten nicht aufrufbar sind.

Wenn nun eine Anwendung im Docker Container mit den üblichen privaten Adressen von Docker laufen, dann gibt es von außen nicht unbedingt ein Routing drauf und Du kommst von außen nicht drauf. Mit dem Proxy ist das kein Problem, weil der Proxy wird über die IP des TWS angesprochen und intern kennt der TWS den Weg zur IP der Docker Adressen.

Alternativ kann man MacVLAN machen, dann kann man der Anwendung im Docker Container eine Adresse aus dem lokalen Netz geben, die dann auch gefunden wird. Aber ist eben ein anderes paar Stiefel als der Proxy. Beides zusammen sollte auch gehen.

Das ist jetzt keine vollständige Abhandlung, weil nicht in allen Fällen geht Proxy (die URLs müssen einen übersetzbaren Aufbau haben) und MacVLAN setzt schon ein gewisses Verständnis von Netzen vorraus.

lg

Stefan

[Eraser]

Danke für die Erklärung Stefan.

Was ich jetzt noch nicht verstehe ist, welchen Vorteil es hat über eine separate IP (bei MacVLAN) oder/und über einen Proxy auf die Weboberfläche von NR zuzugreifen, wenn man angenommenerweise so wie bei mir ich mit dem PC sowieso im gleichen privaten Netz wie der TW schon bin.

[MrWilson]

Leute,

ich möchte wirklich nicht stänkern, auch ich interessiere mich für das Thema, aber die Ausführungen haben eigentlich nichts mit der Fragestellung zu tun und sollten abgetrennt werden.

[StefanW]

Wolfgang,

geh doch bitte mal auf die Seite mit dem Reverse Proxy des Timberwolf Servers und klicke dort auf das blaue i. Da sind die vier Zugriffsverfahren auf Docker Ressourcen erklärt.

Der Text hat mich mal einen Tag gekostet.

Stefan