websockify anteriormente se llamaba wsproxy y era parte del proyecto noVNC.
En el nivel más básico, websockify simplemente traduce el tráfico de WebSockets en tráfico de socket normal. Websockify acepta el protocolo de enlace de WebSockets, lo analiza y luego comienza a reenviar el tráfico entre el cliente y el destino en ambas direcciones.
Los compromisos, anuncios y noticias notables se publican en @noVNC
Si es un desarrollador/integrador/usuario de websockify (o quiere serlo), únase al grupo de discusión noVNC/websockify
Los errores y las solicitudes de funciones se pueden enviar a través de problemas de github.
Si desea mostrar su aprecio por websockify, puede donar a grandes organizaciones sin fines de lucro como: Compassion International, SIL, Habitat for Humanity, Electronic Frontier Foundation, Against Malaria Foundation, Nothing But Nets, etc. Si lo desea, envíe un tweet a @noVNC. .
A partir de websockify 0.5.0, solo se admite el protocolo WebSocket HyBi/IETF 6455. No hay soporte para el formato de datos codificado Base64 anterior.
Para cifrar el tráfico utilizando el esquema URI de WebSocket 'wss://', necesita generar un certificado y una clave para que Websockify lo cargue. De forma predeterminada, Websockify carga un nombre de archivo de certificado self.pem
pero las opciones --cert=CERT
y --key=KEY
pueden anular el nombre del archivo. Puede generar un certificado autofirmado utilizando openssl. Cuando se le solicite el nombre común, utilice el nombre de host del servidor donde se ejecutará el proxy:
openssl req -new -x509 -days 365 -nodes -out self.pem -keyout self.pem
Para que funcione un certificado autofirmado, debe hacer que su cliente/navegador lo comprenda. Puede hacerlo instalándolo como certificado aceptado o usando ese mismo certificado para una conexión HTTPS a la que navega primero y aprueba. Los navegadores generalmente no le brindan el "certificado de confianza". solicite abriendo un socket WSS con un certificado no válido, por lo tanto, debe hacer que lo acepte mediante cualquiera de esos dos métodos.
El navegador puede considerar los puertos como conexiones distintivas, por ejemplo, si la URL de su sitio web es https://my.local:8443 y la URL de su WebSocket es wss://my.local:8001, primero busque https:/ /my.local:8001, agregue la excepción, luego vaya a https://my.local:8443 y agregue otra excepción. Entonces una página html servida sobre :8443 podrá abrir WSS en :8001
Si tiene un certificado SSL comercial/válido con uno o más certificados intermedios, concatenelos en un archivo, primero el certificado del servidor, luego los intermedios de la CA, etc. Apunte a este archivo con la opción --cert
y luego también a la clave con --key
. Finalmente, use --ssl-only
según sea necesario.
Estos no son necesarios para la operación básica.
Demonización: cuando se especifica la opción -D
, websockify se ejecuta en segundo plano como un proceso demonio.
SSL (el URI de WebSockets wss://): websockify lo detecta automáticamente al rastrear el primer byte enviado desde el cliente y luego ajustar el socket si los datos comienzan con 'x16' o 'x80' (lo que indica SSL).
Grabación de sesión: esta función permite grabar el tráfico enviado y recibido del cliente en un archivo mediante la opción --record
.
Miniservidor web: websockify puede detectar y responder a solicitudes web normales en el mismo puerto que el proxy WebSockets. Esta funcionalidad se activa con la opción --web DIR
donde DIR es la raíz del directorio web a servir.
Ajustar un programa: consulte la sección "Ajustar un programa" a continuación.
Archivos de registro: websockify puede guardar toda la información de registro en un archivo. Esta funcionalidad se activa con la opción --log-file FILE
donde ARCHIVO es el archivo donde se deben guardar los registros.
Complementos de autenticación: websockify puede exigir autenticación para conexiones websocket y, si usa --web-auth
, también para solicitudes web normales. Esta funcionalidad se activa con las opciones --auth-plugin CLASS
y --auth-source ARG
, donde CLASS suele ser una de auth_plugins.py y ARG es la configuración del complemento.
Complementos de token: una sola instancia de websockify puede conectar clientes a múltiples objetivos preconfigurados diferentes, dependiendo del token enviado por el cliente usando el parámetro URL token
, o el nombre de host usado para llegar a websockify, si usa --host-token
. Esta funcionalidad se activa con las opciones --token-plugin CLASS
y --token-source ARG
, donde CLASS suele ser una de token_plugins.py y ARG es la configuración del complemento.
La implementación principal de websockify está en Python. Hay varias implementaciones alternativas en otros lenguajes disponibles en nuestros repositorios hermanos websockify-js (JavaScript/Node.js) y websockify-other (C, Clojure, Ruby).
Además, hay varios otros proyectos externos que implementan el "protocolo" websockify. Consulte la Matriz de funciones de implementación alternativa para obtener más información.
Además de realizar proxy desde una dirección de origen a una dirección de destino (que puede estar en un sistema diferente), websockify tiene la capacidad de iniciar un programa en el sistema local y enviar el tráfico de WebSockets a un puerto TCP normal propiedad del programa o vinculado al mismo.
Esto se logra mediante la biblioteca LD_PRELOAD ( rebind.so
) que intercepta las llamadas al sistema bind() realizadas por el programa. El puerto especificado se mueve a un nuevo puerto alto libre de localhost/loopback. websockify luego envía el tráfico WebSockets dirigido al puerto original al nuevo puerto (movido) del programa.
El modo de ajuste del programa se invoca reemplazando el destino con --
seguido de la línea de comando del programa para ajustar.
`./run 2023 -- PROGRAM ARGS`
La opción --wrap-mode
se puede utilizar para indicar qué acción tomar cuando el programa empaquetado sale o se demoniza.
Aquí hay un ejemplo del uso de websockify para empaquetar el comando vncserver (que se pone en segundo plano) para usarlo con noVNC:
`./run 5901 --wrap-mode=ignore -- vncserver -geometry 1024x768 :1`
A continuación se muestra un ejemplo de cómo envolver telnetd (de krb5-telnetd). telnetd sale después de que se cierra la conexión, por lo que el modo de ajuste se configura para reaparecer el comando:
`sudo ./run 2023 --wrap-mode=respawn -- telnetd -debug 2023`
La página wstelnet.html
en el proyecto websockify-js muestra un cliente telnet simple basado en WebSockets (use 'localhost' y '2023' para el host y el puerto respectivamente).
Descargue una de las versiones o la última versión de desarrollo, extráigala y ejecute python3 setup.py install
como root en el directorio donde extrajo los archivos. Normalmente, esto también instalará numpy para un mejor rendimiento, si aún no lo tiene instalado. Sin embargo, numpy es opcional. Si no desea instalar numpy o si no puede compilarlo, puede editar setup.py y eliminar la línea install_requires=['numpy'],
antes de ejecutar python3 setup.py install
.
Luego, websockify debería estar disponible en su camino. Ejecute websockify --help
para confirmar que esté instalado correctamente.
También puede ejecutar websockify usando Docker, Podman, Singularity, udocker o su tiempo de ejecución de contenedor favorito que admita imágenes de contenedor OCI.
El punto de entrada de la imagen es el comando run
.
Para construir la imagen:
./docker/build.sh
Una vez construido, puedes ejecutarlo con los mismos argumentos que le darías al comando run
y encargarte de asignar las asignaciones de puertos:
docker run -it --rm -p <port>:<container_port> novnc/websockify <container_port> <run_arguments>
Por ejemplo, para reenviar tráfico desde el puerto local 7000 a 10.1.1.1:5902 puedes usar:
docker run -it --rm -p 7000:80 novnc/websockify 80 10.1.1.1:5902
Si necesita incluir archivos, como por ejemplo para las opciones --web
o --cert
puede simplemente montar los archivos requeridos en el volumen /data
y luego puede hacer referencia a ellos de la forma habitual:
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