websockify hieß früher wsproxy und war Teil des noVNC-Projekts.
Auf der einfachsten Ebene übersetzt websockify lediglich den WebSockets-Verkehr in normalen Socket-Verkehr. Websockify akzeptiert den WebSockets-Handshake, analysiert ihn und beginnt dann mit der Weiterleitung des Datenverkehrs zwischen dem Client und dem Ziel in beide Richtungen.
Bemerkenswerte Commits, Ankündigungen und Neuigkeiten werden auf @noVNC gepostet
Wenn Sie Websockify-Entwickler/-Integrator/-Benutzer sind (oder sein möchten), treten Sie bitte der noVNC/websockify-Diskussionsgruppe bei
Fehler und Funktionsanfragen können über Github Issues eingereicht werden.
Wenn Sie Ihre Wertschätzung für websockify zum Ausdruck bringen möchten, können Sie an großartige gemeinnützige Organisationen spenden, beispielsweise an Compassion International, SIL, Habitat for Humanity, Electronic Frontier Foundation, Against Malaria Foundation, Nothing But Nets usw. Bitte twittern Sie @noVNC, wenn Sie dies tun .
Ab websockify 0.5.0 wird nur das HyBi / IETF 6455 WebSocket-Protokoll unterstützt. Das ältere Base64-codierte Datenformat wird nicht unterstützt.
Um den Datenverkehr mit dem WebSocket-URI-Schema „wss://“ zu verschlüsseln, müssen Sie ein Zertifikat und einen Schlüssel generieren, damit Websockify geladen werden kann. Standardmäßig lädt Websockify eine Zertifikatdatei mit dem Namen self.pem
aber die Optionen --cert=CERT
und --key=KEY
können den Dateinamen überschreiben. Sie können mit OpenSSL ein selbstsigniertes Zertifikat generieren. Wenn Sie nach dem allgemeinen Namen gefragt werden, verwenden Sie den Hostnamen des Servers, auf dem der Proxy ausgeführt wird:
openssl req -new -x509 -days 365 -nodes -out self.pem -keyout self.pem
Damit ein selbstsigniertes Zertifikat funktioniert, müssen Sie es Ihrem Client/Browser verständlich machen. Sie können dies tun, indem Sie es als akzeptiertes Zertifikat installieren oder dasselbe Zertifikat für eine HTTPS-Verbindung verwenden, zu der Sie zuerst navigieren und diese genehmigen. Browser geben Ihnen im Allgemeinen nicht das „Vertrauenszertifikat“ aus? Sie werden dazu aufgefordert, indem Sie einen WSS-Socket mit einem ungültigen Zertifikat öffnen. Daher müssen Sie es mit einer dieser beiden Methoden akzeptieren lassen.
Die Ports können vom Browser als Unterscheidungsmerkmale für Verbindungen betrachtet werden. Wenn die URL Ihrer Website beispielsweise https://my.local:8443 und Ihre WebSocket-URL wss://my.local:8001 lautet, navigieren Sie zunächst zu https:/ /my.local:8001, fügen Sie die Ausnahme hinzu, navigieren Sie dann zu https://my.local:8443 und fügen Sie eine weitere Ausnahme hinzu. Dann kann eine über :8443 bereitgestellte HTML-Seite WSS für :8001 öffnen
Wenn Sie ein kommerzielles/gültiges SSL-Zertifikat mit einem oder mehreren Zwischenzertifikaten haben, fassen Sie diese in einer Datei zusammen, zuerst das Serverzertifikat, dann das/die Zwischenzertifikat(e) von der Zertifizierungsstelle usw. Zeigen Sie mit der Option --cert
auf diese Datei und dann auch zum Schlüssel mit --key
. Verwenden Sie schließlich --ssl-only
nach Bedarf.
Diese sind für den Grundbetrieb nicht notwendig.
Dämonisierung: Wenn die Option -D
angegeben ist, läuft websockify im Hintergrund als Daemon-Prozess.
SSL (der wss:// WebSockets-URI): Dies wird von websockify automatisch erkannt, indem es das erste vom Client gesendete Byte ausspioniert und dann den Socket umschließt, wenn die Daten mit „x16“ oder „x80“ beginnen (was SSL anzeigt).
Sitzungsaufzeichnung: Diese Funktion ermöglicht die Aufzeichnung des vom Client gesendeten und empfangenen Datenverkehrs in einer Datei mithilfe der Option --record
.
Mini-Webserver: Websockify kann normale Webanfragen auf demselben Port wie der WebSockets-Proxy erkennen und darauf reagieren. Diese Funktionalität wird mit der Option --web DIR
aktiviert, wobei DIR das Stammverzeichnis des bereitzustellenden Webverzeichnisses ist.
Ein Programm verpacken: siehe den Abschnitt „Ein Programm verpacken“ weiter unten.
Protokolldateien: websockify kann alle Protokollierungsinformationen in einer Datei speichern. Diese Funktionalität wird mit der Option --log-file FILE
aktiviert, wobei FILE die Datei ist, in der die Protokolle gespeichert werden sollen.
Authentifizierungs-Plugins: websockify kann eine Authentifizierung für Websocket-Verbindungen und, wenn Sie --web-auth
verwenden, auch für normale Webanfragen verlangen. Diese Funktionalität wird mit den Optionen --auth-plugin CLASS
und --auth-source ARG
aktiviert, wobei CLASS normalerweise eine von auth_plugins.py und ARG die Konfiguration des Plugins ist.
Token-Plugins: Eine einzelne Instanz von websockify kann Clients mit mehreren verschiedenen vorkonfigurierten Zielen verbinden, abhängig von dem vom Client mithilfe des token
URL-Parameters gesendeten Token oder dem Hostnamen, der zum Erreichen von websockify verwendet wird, wenn Sie --host-token
verwenden. Diese Funktionalität wird mit den Optionen --token-plugin CLASS
und --token-source ARG
aktiviert, wobei CLASS normalerweise eine aus token_plugins.py und ARG die Konfiguration des Plugins ist.
Die primäre Implementierung von websockify erfolgt in Python. In unseren Schwesterrepositorys websockify-js (JavaScript/Node.js) und websockify-other (C, Clojure, Ruby) sind mehrere alternative Implementierungen in anderen Sprachen verfügbar.
Darüber hinaus gibt es mehrere andere externe Projekte, die das Websockify-„Protokoll“ implementieren. Weitere Informationen finden Sie in der Funktionsmatrix für alternative Implementierungen.
Zusätzlich zum Proxying von einer Quelladresse zu einer Zieladresse (die sich möglicherweise auf einem anderen System befindet) hat websockify die Möglichkeit, ein Programm auf dem lokalen System zu starten und den WebSockets-Verkehr an einen normalen TCP-Port weiterzuleiten, der dem Programm gehört/an das Programm gebunden ist.
Dies wird durch die LD_PRELOAD-Bibliothek ( rebind.so
) erreicht, die bind()-Systemaufrufe des Programms abfängt. Der angegebene Port wird auf einen neuen High-Port mit freiem Localhost/Loopback verschoben. websockify leitet dann den an den ursprünglichen Port geleiteten WebSockets-Verkehr per Proxy an den neuen (verschobenen) Port des Programms weiter.
Der Programmumbruchmodus wird aufgerufen, indem das Ziel durch --
ersetzt wird, gefolgt von der Programmbefehlszeile zum Umbrechen.
`./run 2023 -- PROGRAM ARGS`
Die Option --wrap-mode
kann verwendet werden, um anzugeben, welche Aktion ausgeführt werden soll, wenn das umschlossene Programm beendet oder dämonisiert wird.
Hier ist ein Beispiel für die Verwendung von websockify zum Umschließen des vncserver-Befehls (der sich selbst im Hintergrund erstellt) für die Verwendung mit noVNC:
`./run 5901 --wrap-mode=ignore -- vncserver -geometry 1024x768 :1`
Hier ist ein Beispiel für das Umschließen von Telnetd (von krb5-telnetd). telnetd wird beendet, nachdem die Verbindung geschlossen wurde, sodass der Wrap-Modus so eingestellt ist, dass der Befehl erneut erscheint:
`sudo ./run 2023 --wrap-mode=respawn -- telnetd -debug 2023`
Die wstelnet.html
-Seite im websockify-js-Projekt demonstriert einen einfachen WebSockets-basierten Telnet-Client (verwenden Sie „localhost“ und „2023“ für den Host bzw. den Port).
Laden Sie eine der Versionen oder die neueste Entwicklungsversion herunter, extrahieren Sie sie und führen Sie python3 setup.py install
als Root in dem Verzeichnis aus, in das Sie die Dateien extrahiert haben. Normalerweise wird dadurch auch Numpy installiert, um eine bessere Leistung zu erzielen, sofern Sie es nicht bereits installiert haben. Numpy ist jedoch optional. Wenn Sie numpy nicht installieren möchten oder es nicht kompilieren können, können Sie setup.py bearbeiten und die Zeile install_requires=['numpy'],
entfernen, bevor Sie python3 setup.py install
ausführen.
Anschließend sollte websockify in Ihrem Pfad verfügbar sein. Führen Sie websockify --help
aus, um zu bestätigen, dass es korrekt installiert ist.
Sie können websockify auch mit Docker, Podman, Singularity, udocker oder Ihrer bevorzugten Container-Laufzeitumgebung ausführen, die OCI-Container-Images unterstützt.
Der Einstiegspunkt des Bildes ist der run
.
So erstellen Sie das Image:
./docker/build.sh
Sobald es erstellt ist, können Sie es einfach mit denselben Argumenten starten, die Sie dem Befehl run
geben würden, und sich um die Zuweisung der Portzuordnungen kümmern:
docker run -it --rm -p <port>:<container_port> novnc/websockify <container_port> <run_arguments>
Um beispielsweise Datenverkehr vom lokalen Port 7000 an 10.1.1.1:5902 weiterzuleiten, können Sie Folgendes verwenden:
docker run -it --rm -p 7000:80 novnc/websockify 80 10.1.1.1:5902
Wenn Sie Dateien einschließen müssen, wie zum Beispiel für die Optionen --web
oder --cert
können Sie die erforderlichen Dateien einfach im Volume /data
mounten und dann auf die übliche Weise darauf verweisen:
docker run -it --rm -p 443:443 -v websockify-data:/data novnc/websockify --cert /data/self.pem --web /data/noVNC :443 --token-plugin TokenRedis --token-source myredis.local:6379 --ssl-only --ssl-version tlsv1_2