websockify
v0.12.0
websockify era anteriormente denominado wsproxy e fazia parte do projeto noVNC.
No nível mais básico, o websockify apenas traduz o tráfego de WebSockets em tráfego de soquete normal. O Websockify aceita o handshake WebSockets, analisa-o e começa a encaminhar o tráfego entre o cliente e o destino em ambas as direções.
Commits, anúncios e notícias notáveis são postados em @noVNC
Se você é um desenvolvedor/integrador/usuário do websockify (ou deseja ser), junte-se ao grupo de discussão noVNC/websockify
Bugs e solicitações de recursos podem ser enviados por meio de problemas no GitHub.
Se você quiser mostrar apreço pelo websockify, você pode doar para grandes organizações sem fins lucrativos, como: Compassion International, SIL, Habitat for Humanity, Electronic Frontier Foundation, Against Malaria Foundation, Nothing But Nets, etc. .
A partir do websockify 0.5.0, apenas o protocolo HyBi/IETF 6455 WebSocket é suportado. Não há suporte para o antigo formato de dados codificados em Base64.
Para criptografar o tráfego usando o esquema de URI WebSocket 'wss: //', você precisa gerar um certificado e uma chave para o Websockify carregar. Por padrão, o Websockify carrega um nome de arquivo de certificado self.pem mas as opções --cert=CERT e --key=KEY podem substituir o nome do arquivo. Você pode gerar um certificado autoassinado usando openssl. Quando solicitado o nome comum, use o nome do host do servidor onde o proxy estará rodando:
openssl req -new -x509 -days 365 -nodes -out self.pem -keyout self.pem
Para que um certificado autoassinado funcione, você precisa fazer com que seu cliente/navegador o entenda. Você pode fazer isso instalando-o como certificado aceito ou usando o mesmo certificado para uma conexão HTTPS na qual você navega primeiro e aprova. Os navegadores geralmente não fornecem o "certificado de confiança?" prompt abrindo um soquete WSS com certificado inválido, portanto, você precisa aceitá-lo por qualquer um desses dois métodos.
As portas podem ser consideradas como conexões distintivas pelo navegador, por exemplo, se a URL do seu site for https://my.local:8443 e a URL do seu WebSocket for wss://my.local:8001, primeiro navegue até https:/ /my.local:8001, adicione a exceção, navegue até https://my.local:8443 e adicione outra exceção. Então, uma página HTML veiculada em :8443 poderá abrir o WSS em :8001
Se você tiver um certificado SSL comercial/válido com um ou mais certificados intermediários, concatene-os em um arquivo, primeiro o --cert do servidor, depois o(s) intermediário(s) da CA, etc. também para a chave com --key . Finalmente, use --ssl-only conforme necessário.
Estes não são necessários para a operação básica.
Daemonização: Quando a opção -D é especificada, o websockify é executado em segundo plano como um processo daemon.
SSL (o URI wss:// WebSockets): Isso é detectado automaticamente pelo websockify, detectando o primeiro byte enviado do cliente e, em seguida, agrupando o soquete se os dados começarem com 'x16' ou 'x80' (indicando SSL).
Gravação de sessão: Este recurso permite gravar o tráfego enviado e recebido do cliente em um arquivo usando a opção --record .
Mini-servidor web: o websockify pode detectar e responder a solicitações normais da web na mesma porta que o proxy WebSockets. Esta funcionalidade é ativada com a opção --web DIR onde DIR é a raiz do diretório web a ser servido.
Preparar um programa: consulte a seção "Envolver um programa" abaixo.
Arquivos de log: o websockify pode salvar todas as informações de log em um arquivo. Esta funcionalidade é ativada com a opção --log-file FILE onde FILE é o arquivo onde os logs devem ser salvos.
Plug-ins de autenticação: o websockify pode exigir autenticação para conexões websocket e, se você usar --web-auth , também para solicitações normais da web. Esta funcionalidade é ativada com as opções --auth-plugin CLASS e --auth-source ARG , onde CLASS geralmente é um de auth_plugins.py e ARG é a configuração do plugin.
Plug-ins de token: uma única instância do websockify pode conectar clientes a vários destinos pré-configurados diferentes, dependendo do token enviado pelo cliente usando o parâmetro URL token ou do nome do host usado para acessar o websockify, se você usar --host-token . Esta funcionalidade é ativada com as opções --token-plugin CLASS e --token-source ARG , onde CLASS geralmente é um de token_plugins.py e ARG é a configuração do plugin.
A implementação principal do websockify está em python. Existem várias implementações alternativas em outras linguagens disponíveis em nossos repositórios irmãos websockify-js (JavaScript/Node.js) e websockify-other (C, Clojure, Ruby).
Além disso, existem vários outros projetos externos que implementam o "protocolo" websockify. Consulte a Matriz de recursos de implementação alternativa para obter mais informações.
Além de fazer proxy de um endereço de origem para um endereço de destino (que pode estar em um sistema diferente), o websockify tem a capacidade de iniciar um programa no sistema local e fazer proxy do tráfego de WebSockets para uma porta TCP normal de propriedade/vinculada ao programa.
Isso é feito pela biblioteca LD_PRELOAD ( rebind.so ) que intercepta chamadas de sistema bind() pelo programa. A porta especificada é movida para uma nova porta alta livre de localhost/loopback. O websockify então faz proxy do tráfego de WebSockets direcionado à porta original para a nova porta (movida) do programa.
O modo de quebra do programa é invocado substituindo o destino por -- seguido pela linha de comando do programa para quebrar.
`./run 2023 -- PROGRAM ARGS`
A opção --wrap-mode pode ser usada para indicar qual ação tomar quando o programa empacotado sair ou for daemonizado.
Aqui está um exemplo de uso do websockify para agrupar o comando vncserver (que é o próprio plano de fundo) para uso com noVNC:
`./run 5901 --wrap-mode=ignore -- vncserver -geometry 1024x768 :1`
Aqui está um exemplo de encapsulamento do telnetd (de krb5-telnetd). telnetd sai depois que a conexão é fechada, então o modo wrap é definido para reaparecer o comando:
`sudo ./run 2023 --wrap-mode=respawn -- telnetd -debug 2023`
A página wstelnet.html no projeto websockify-js demonstra um cliente telnet simples baseado em WebSockets (use 'localhost' e '2023' para o host e a porta, respectivamente).
Baixe um dos lançamentos ou a versão de desenvolvimento mais recente, extraia-o e execute python3 setup.py install como root no diretório onde você extraiu os arquivos. Normalmente, isso também instalará o numpy para melhor desempenho, caso você ainda não o tenha instalado. No entanto, numpy é opcional. Se você não deseja instalar o numpy ou não consegue compilá-lo, você pode editar setup.py e remover a linha install_requires=['numpy'], antes de executar python3 setup.py install .
Posteriormente, o websockify deverá estar disponível em seu caminho. Execute websockify --help para confirmar que está instalado corretamente.
Você também pode executar o websockify usando Docker, Podman, Singularity, udocker ou seu tempo de execução de contêiner favorito que oferece suporte a imagens de contêiner OCI.
O ponto de entrada da imagem é o comando run .
Para construir a imagem:
./docker/build.sh
Uma vez construído, você pode simplesmente iniciá-lo com os mesmos argumentos que daria ao comando run e cuidando da atribuição dos mapeamentos de portas:
docker run -it --rm -p <port>:<container_port> novnc/websockify <container_port> <run_arguments>
Por exemplo, para encaminhar o tráfego da porta local 7000 para 10.1.1.1:5902 você pode usar:
docker run -it --rm -p 7000:80 novnc/websockify 80 10.1.1.1:5902
Se você precisar incluir arquivos, como por exemplo para as opções --web ou --cert você pode simplesmente montar os arquivos necessários no volume /data e então referenciá-los da maneira usual:
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
