websockify
v0.12.0
websockify s'appelait auparavant wsproxy et faisait partie du projet noVNC.
Au niveau le plus élémentaire, websockify traduit simplement le trafic WebSockets en trafic socket normal. Websockify accepte la négociation WebSockets, l'analyse, puis commence à transférer le trafic entre le client et la cible dans les deux sens.
Des engagements, des annonces et des actualités notables sont publiés sur @noVNC
Si vous êtes un développeur/intégrateur/utilisateur websockify (ou souhaitez le devenir), veuillez rejoindre le groupe de discussion noVNC/websockify
Les bogues et les demandes de fonctionnalités peuvent être soumis via les problèmes github.
Si vous souhaitez montrer votre appréciation pour websockify, vous pouvez faire un don à une organisation à but non lucratif telle que : Compassion International, SIL, Habitat for Humanity, Electronic Frontier Foundation, Against Malaria Foundation, Nothing But Nets, etc. Veuillez tweeter @noVNC si vous le faites. .
À partir de websockify 0.5.0, seul le protocole HyBi / IETF 6455 WebSocket est pris en charge. L'ancien format de données codé en Base64 n'est pas pris en charge.
Pour chiffrer le trafic à l'aide du schéma URI WebSocket 'wss://', vous devez générer un certificat et une clé que Websockify pourra charger. Par défaut, Websockify charge un nom de fichier de certificat self.pem mais les options --cert=CERT et --key=KEY peuvent remplacer le nom du fichier. Vous pouvez générer un certificat auto-signé à l'aide d'openssl. Lorsqu'on vous demande le nom commun, utilisez le nom d'hôte du serveur sur lequel le proxy sera exécuté :
openssl req -new -x509 -days 365 -nodes -out self.pem -keyout self.pem
Pour qu’un certificat auto-signé fonctionne, vous devez le faire comprendre à votre client/navigateur. Vous pouvez le faire en l'installant en tant que certificat accepté ou en utilisant ce même certificat pour une connexion HTTPS vers laquelle vous accédez d'abord et approuvez. Les navigateurs ne vous donnent généralement pas le « certificat de confiance ? invite en ouvrant un socket WSS avec un certificat invalide, vous devez donc le faire accepter par l'une de ces deux méthodes.
Les ports peuvent être considérés comme des connexions distinctives par le navigateur, par exemple, si l'URL de votre site Web est https://my.local:8443 et que l'URL de votre WebSocket est wss://my.local:8001, accédez d'abord à https:/ /my.local:8001, ajoutez l'exception, puis accédez à https://my.local:8443 et ajoutez une autre exception. Ensuite, une page html servie sur :8443 pourra ouvrir WSS vers :8001
Si vous disposez d'un certificat SSL commercial/valide avec un ou plusieurs certificats intermédiaires, concaténez-les dans un seul fichier, le certificat du serveur d'abord, puis le(s) intermédiaire(s) de l'autorité de certification, etc. Pointez sur ce fichier avec l'option --cert puis également à la clé avec --key . Enfin, utilisez --ssl-only si nécessaire.
Ceux-ci ne sont pas nécessaires au fonctionnement de base.
Démonisation : lorsque l'option -D est spécifiée, websockify s'exécute en arrière-plan en tant que processus démon.
SSL (l'URI wss:// WebSockets) : ceci est détecté automatiquement par websockify en reniflant le premier octet envoyé par le client, puis en encapsulant le socket si les données commencent par « x16 » ou « x80 » (indiquant SSL).
Enregistrement de session : Cette fonctionnalité qui permet d'enregistrer le trafic envoyé et reçu du client dans un fichier à l'aide de l'option --record .
Mini-serveur Web : websockify peut détecter et répondre aux requêtes Web normales sur le même port que le proxy WebSockets. Cette fonctionnalité est activée avec l'option --web DIR où DIR est la racine du répertoire Web à servir.
Envelopper un programme : voir la section "Envelopper un programme" ci-dessous.
Fichiers journaux : websockify peut enregistrer toutes les informations de journalisation dans un fichier. Cette fonctionnalité est activée avec l'option --log-file FILE où FILE est le fichier dans lequel les journaux doivent être enregistrés.
Plugins d'authentification : websockify peut exiger une authentification pour les connexions websocket et, si vous utilisez --web-auth , également pour les requêtes Web normales. Cette fonctionnalité est activée avec les options --auth-plugin CLASS et --auth-source ARG , où CLASS est généralement celle de auth_plugins.py et ARG est la configuration du plugin.
Plugins de jetons : une seule instance de websockify peut connecter les clients à plusieurs cibles préconfigurées différentes, en fonction du jeton envoyé par le client à l'aide du paramètre URL token , ou du nom d'hôte utilisé pour atteindre websockify, si vous utilisez --host-token . Cette fonctionnalité est activée avec les options --token-plugin CLASS et --token-source ARG , où CLASS est généralement celle de token_plugins.py et ARG est la configuration du plugin.
La principale implémentation de websockify est en python. Il existe plusieurs implémentations alternatives dans d'autres langages disponibles dans nos référentiels frères websockify-js (JavaScript/Node.js) et websockify-other (C, Clojure, Ruby).
De plus, il existe plusieurs autres projets externes qui implémentent le « protocole » websockify. Consultez la matrice des fonctionnalités d’implémentation alternative pour plus d’informations.
En plus du proxy d'une adresse source vers une adresse cible (qui peut se trouver sur un système différent), websockify a la capacité de lancer un programme sur le système local et de proxy le trafic WebSockets vers un port TCP normal détenu/lié par le programme.
Ceci est accompli par la bibliothèque LD_PRELOAD ( rebind.so ) qui intercepte les appels système bind() par le programme. Le port spécifié est déplacé vers un nouveau port haut libre localhost/loopback. websockify transmet ensuite le trafic WebSockets dirigé vers le port d'origine vers le nouveau port (déplacé) du programme.
Le mode wrap du programme est invoqué en remplaçant la cible par -- suivi de la ligne de commande du programme à wrapper.
`./run 2023 -- PROGRAM ARGS`
L'option --wrap-mode peut être utilisée pour indiquer l'action à entreprendre lorsque le programme encapsulé se termine ou se démonise.
Voici un exemple d'utilisation de websockify pour envelopper la commande vncserver (qui se met en arrière-plan) pour une utilisation avec noVNC :
`./run 5901 --wrap-mode=ignore -- vncserver -geometry 1024x768 :1`
Voici un exemple d'encapsulation de telnetd (à partir de krb5-telnetd). telnetd se ferme après la fermeture de la connexion, le mode wrap est donc défini pour réapparaître la commande :
`sudo ./run 2023 --wrap-mode=respawn -- telnetd -debug 2023`
La page wstelnet.html du projet websockify-js présente un client telnet simple basé sur WebSockets (utilisez respectivement « localhost » et « 2023 » pour l'hôte et le port).
Téléchargez l'une des versions ou la dernière version de développement, extrayez-la et exécutez python3 setup.py install en tant que root dans le répertoire où vous avez extrait les fichiers. Normalement, cela installera également numpy pour de meilleures performances, si vous ne l'avez pas déjà installé. Cependant, numpy est facultatif. Si vous ne souhaitez pas installer numpy ou si vous ne pouvez pas le compiler, vous pouvez modifier setup.py et supprimer la ligne install_requires=['numpy'], avant d'exécuter python3 setup.py install .
Ensuite, websockify devrait être disponible sur votre chemin. Exécutez websockify --help pour confirmer qu'il est correctement installé.
Vous pouvez également exécuter websockify à l'aide de Docker, Podman, Singularity, udocker ou de votre environnement d'exécution de conteneur préféré prenant en charge les images de conteneur OCI.
Le point d'entrée de l'image est la commande run .
Pour construire l'image :
./docker/build.sh
Une fois construit, vous pouvez simplement le lancer avec les mêmes arguments que vous donneriez à la commande run et en prenant soin d'attribuer les mappages de ports :
docker run -it --rm -p <port>:<container_port> novnc/websockify <container_port> <run_arguments>
Par exemple, pour transférer le trafic du port local 7000 vers 10.1.1.1:5902, vous pouvez utiliser :
docker run -it --rm -p 7000:80 novnc/websockify 80 10.1.1.1:5902
Si vous devez inclure des fichiers, comme par exemple pour les options --web ou --cert vous pouvez simplement monter les fichiers requis dans le volume /data et vous pouvez ensuite les référencer de la manière habituelle :
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
