¡Hola, comunidad!
Después de recibir diversos mensajes informando de caídas frecuentes en el servidor remote.nvda.es, nos pusimos a investigar registros varios y código fuente y llegamos a una terrible conclusión: la versión 2.4 del servidor, así como las anteriores, no es segura. No tiene fallos de seguridad en términos de filtración de datos, inyección de código malicioso o intercepción del tráfico (que sepamos), pero sí de disponibilidad del servicio, que también es un aspecto clave en la seguridad. Tirar uno de estos servidores era tan sencillo como lanzar un script y esperar alrededor de 3 minutos para que se inundara de conexiones. Uno de los mecanismos de seguridad, que resultó ser contraproducente, se encargaba de asestar el golpe de gracia. Diagnosticado el problema, hemos trabajado tan rápido como ha sido posible en la versión 2.5, y en esta entrada hablamos de ella. Cumpliendo lo prometido, ya no se soporta Python 2. Además, se corrigen otros potenciales errores, se actualizan dependencias y se toman medidas para garantizar que una conexión permanece abierta sólo mientras el cliente lo necesita.
El servidor de NVDA Remote, también llamado NVDA Remote Server, es una versión libre y de código abierto creada a partir de un exhaustivo estudio del código fuente y los protocolos del complemento NVDA Remote. Funciona igual que el servidor alojado en nvdaremote.com, con la diferencia de que este se puede instalar en cualquier lugar y en casi cualquier plataforma. De hecho, nosotros disponemos de una copia totalmente operativa, a la que puedes conectarte escribiendo «remote.nvda.es» en el campo «Equipo o servidor» del diálogo de conexión de NVDA Remote o TeleNVDA. Este servidor nació hace unos años, y ha ido evolucionando para corregir errores, ser cada vez más eficiente y brindar una experiencia rápida y segura a todos sus usuarios. Estos son los cambios de la versión 2.5:
- En sistemas Linux, se aumenta el límite de descriptores de fichero a su valor máximo, definido en el sistema operativo. También se usa el módulo selectors en vez del módulo select. Esto elimina la restricción de 1024 conexiones simultáneas como máximo. Otras plataformas mantienen sus propios límites. Por ejemplo, en Windows el límite es de 512, y de momento deberá quedarse ahí.
- Si un cliente se conecta y no negocia una conexión SSL, será expulsado tras un tiempo de espera. Dicho tiempo de espera se define en un nuevo valor de configuración, llamado timeout. Por defecto es de 5 segundos, y podría ser necesario aumentarlo en escenarios con conexiones muy lentas.
- Ahora, se puede configurar cada cuánto tiempo el servidor envía mensajes de ping a los clientes. Por defecto son 5 minutos. Se puede usar la opción ping_time para cambiar este valor. Si un cliente se conecta por SSL y no envía datos, el servidor lo expulsará durante este envío de mensajes.
- Los clientes se desconectarán tras completar con éxito una petición o enviar un mensaje erróneo, siempre que no hayan entrado a un canal. Antes, un cliente diseñado específicamente podía generar varias claves seguidas y unirse a un canal sin desconectarse en ningún momento, por ejemplo.
- Se gestionan adecuadamente posibles excepciones que podían romper el servidor o hacer fallar el hilo de un canal.
- Se ha eliminado un montón de código antiguo, usado para mantener la compatibilidad con Python 2.x.
- Tras consultar la documentación de Systemd, se han configurado todos aquellos ajustes de protección que aíslan al servidor del resto del sistema sin llegar a impedir su funcionamiento. Algunas ubicaciones por defecto cambian para adaptarse a la situación, y varios scripts han dejado de ser necesarios y se han eliminado.
- Al ejecutar el servicio usando Systemd en Linux, se crea una cuenta de usuario dinámicamente que se elimina al detenerlo, por lo que ya no es necesario un usuario permanente.
- El comando
NVDARemoteServer statusahora indicará el uso de disco, red, memoria y CPU si el servicio está gestionado con Systemd en Linux. - Ya no se generan archivos de bytecode al arrancar el servidor en modo depuración. Se supone que son versiones optimizadas del código y aumentan el rendimiento, pero también dejan por ahí una carpeta que tiende a molestar y eliminarse con frecuencia.
- Se ha optimizado la imagen de Docker para que sea más pequeña y con menos capas. Además, ya no descarga archivos externos durante su construcción.
- El archivo docker-compose.yml incluye directivas para construir la imagen con el comando docker compose build, y define límites elevados para los descriptores de fichero.
- En Windows, ahora se usan Python 3.13.6, Pywin32 311, OpenSSL 3.5.2, Pyinstaller 6.15.0 y otras dependencias actualizadas, incluyendo las bibliotecas de tiempo de ejecución de Microsoft.
- En distribuciones basadas en RHEL9, ahora se requiere Python 3.13.
- Si se pasan valores enteros y decimales erróneos en la configuración, el servidor usará los que vienen por defecto.
- Como parte de sus mensajes de arranque, el servidor ahora grabará en el registro o mostrará por consola los valores de configuración que va a usar.
- Otros pequeños retoques, optimizaciones y actualización de la documentación.
Los requisitos del sistema han cambiado respecto a la versión 2.4. Ahora, el servidor sólo funcionará en Windows 7 o posterior, y podrían experimentarse fallos en algunas distribuciones de Linux antiguas. Para descargar esta nueva versión, puedes visitar la página de la publicación en GitHub, o esta carpeta de Google Drive con todas las versiones. Te recomendamos leer la guía de usuario del servidor de NVDA Remote si no sabes por dónde empezar. La hemos actualizado para incluir los nuevos parámetros de configuración de la versión 2.5.
¡Hasta la próxima!
