Protocolo VATPS

Antecedentes

Este protocolo se apoya sobre el protocolo TCP. El protocolo VATPS no se trata pues de una alternativa, si no de una capa propia que añadimos sobre la base de TCP. Es una evolución del protocolo VATP añadiendo una capa TLS/SSL, el estándar de seguridad en comunicaciones. Esto permite que toda la comunicación entre todos los componentes de Velneo y el servidor Velneo vServer vayan cifrados.

Este uso de TCP por parte del protocolo VATPS sería análogo al que hace el protocolo HTTPS del protocolo TCP, sobre el que se ejecuta.

La capa que añadimos a la base TCP incluye todos los comandos necesarios para la edición de proyectos (envío y recepción de proyectos, adjuntos, etc.), la gestión del servidor (usuarios, instancias, carpetas compartidas, SDV, etc.), la ejecución de aplicaciones (envío de proyectos, caché de proyectos, envío de datos, caché de datos, ejecución de procesos en el servidor, etc.), ejecución de funciones remotas, comandos para SDV, etc., y son estos comandos los que conforman, junto a la base TCP, el conjunto del protocolo VATP.

El protocolo VATPS, por tanto, incluye TCP, aprovechando todas sus características y versatilidad.

Características principales

Multi-hilo

Las aplicaciones se ejecutan con total fluidez, ya que los objetos visuales están diseñados para usar múltiples hilos, evitando que la interfaz se bloquee en ningún momento.

Optimizado para WAN

El uso de sockets envolventes consigue un gran rendimiento en la ejecución de aplicaciones, incluso con un bajo ancho de banda. Las aplicaciones pueden conseguir velocidad de LAN por una WAN.

Seguridad en las comunicaciones

Este protocolo permite establecer conexiones seguras estándar TLS/SSL lo que provee de privacidad e integridad a las comunicaciones en red entre todos los componentes de Velneo. Es decir, no solo la comunicación se envía cifrada entre los componentes, si no que es inviolable, ya que garantiza que nadie puede modificar la información que se transmite, además de garantizarnos con qué servidor nos hemos conectado.

Caché de datos y objetos

Se gestionan automáticamente caches tanto de datos como de objetos, imágenes, textos, etc., con lo que se consigue un gran rendimiento además de reducir el tráfico de red.

Con la tecnología de refresco terciario todas las caches se mantienen actualizadas permanentemente.

Para mejorar el rendimiento de la parte cliente éste genera una caché local de archivos en el ámbito del usuario. Esta caché es generada por máquina y usuario, es decir, que si en una misma máquina se inician sesiones de usuario diferentes, cada usuario tendrá su propia caché local.

Esta caché es generada físicamente en el directorio home del sistema del usuario, en una carpeta llamada Velneo.

En esta caché local se almacena lo siguiente:

• Los proyectos que se ejecuten (en una sub-carpeta llamada cacherun). En formato encriptado y no editable.

• Los ficheros adjuntos declarados en los proyectos que se ejecuten (en la misma sub-carpeta que los proyectos).

• Los archivos de conexión de impresoras lógicas a físicas (en una sub-carpeta llamada printers).

El hacer uso de la caché de aplicación redundará en una mejora en los tiempos de ejecución de la misma ya que, al pedírsela a Velneo vServer para su ejecución, si ya la tenemos en caché, no tendrá que enviarla de nuevo, sino que se hará uso de la de la caché. Por tanto, Velneo vServer solamente tendrá que enviarla al cliente en su primera ejecución y cuando haya nuevas versiones de la misma.

El protocolo

Los distintos componentes de la plataforma: Velneo vAdmin, Velneo vDevelop, Velneo vClient, Velneo vDataclient, Velneo vInstallBuilder, Velneo vModApache y Velneo vTranslator se comunican con Velneo vServer a través de un protocolo propio de la plataforma denominado VATPS que se establece sobre el protocolo de comunicaciones TCP/IP estándar.

El protocolo VATPS (Velneo Application Transfer Protocol Secure) permite tanto la gestión de Velneo vServer como la edición y ejecución de proyectos. Además, se encuentra especialmente optimizado para su uso en cualquier tipo de red, independientemente de su velocidad o calidad, por lo que actúa perfectamente tanto en redes locales LAN como en redes de internet WAN, permitiendo operaciones con gran volumen de información.

El protocolo VATPS tiene reservado el puerto 690 en todos los sistemas. Dicha reserva ha sido realizada por IANA (Internet Assigned Numbers Authority), organismo internacional que autoriza tales reservas, auspiciado por ICANN (Internet Corporation for Assigned Names and Numbers) organismo internacional regulador. El registro puede consultarse en la página web de IANA.

Este puerto está considerado dentro del rango “Well Known ports”, al mismo nivel que los puertos asignados para los protocolos HTTP (80), Correo electrónico (POP3 110, SMTP 25) o protocolos tan seguros como HTTPS (443).

Tal y como podemos leer en el registro, IANA advierte que este rango no pueden usarse sin la autorización del propio organismo tal y como se define en el RFC4340, Sección 19.9.

Velneo vServer admite la configuración de cualquier puerto para la escucha de comunicaciones, por lo que no es obligatorio el uso del puerto 690, que puede ser sustituido por cualquier puerto admitido por los sistemas.

Para conectarse a través del protocolo VATPS con Velneo vServer los distintos componentes usan un identificador uniforme de recurso (URI) o localizador uniforme de recurso (URL) que incluye las siguientes partes:

[vatps://]domino:puerto

Donds los distintos elementos se definen como:

VATPS: esquema que define el protocolo. Si no lo especificamos, asumirá el valor vatps://.

dominio: nombre o ip de la máquina a la que se desea acceder a través del protocolo.

puerto: puerto habilitado para la escucha en Velneo vServer y al que se desea acceder. El puerto por defecto será 690 y, si no se indica, se asumirá éste.

vatps://v7clould.velneo.com

vatps://v7clould.velneo.com:1000

Configuración y certificados

La configuración comienza por obtener nuestro certificado digital. Contamos con 2 opciones:

• Adquirirlo en una entidad certificadora. La opción más segura y recomendada para aquellos desarrolladores que necesiten máxima seguridad en sus conexiones. Ver el punto Incluir un certificado TLS/SSL propio de la documentación.

• Usar un certificado autofirmado o el incluido por Velneo por defecto dentro del propio Velneo vServer: En este caso, cuando los componentes se conecten nos aparecerá un aviso de error SSL informando de que debemos añadir una excepción para ese certificado. Esta opción no se recomienda para servidores de producción.

El servidor carga el certificado al iniciarse. Una vez iniciado, comprueba todos los días si se han actualizado los ficheros del certificado y, si han sido actualizados, cargará el nuevo certificado.

El servidor emitirá diariamente un aviso en el panel de salida de mensajes de Velneo vAdmin durante los 7 días previos a que el certificado vaya a caducar, indicando los días que quedan para que caduque. Ejemplo:

Faltan 2 días para que el certificado ssl caduque

Una vez ha caducado el certificado, si no lo hemos actualizado, mostrará un mensaje indicando que el certificado ya ha caducado.

Al establecerse la conexión TLS/SSL se seleccionará la opción más segura en ese momento, determinada por el sistema y las librerías TLS/SSL. Normalmente será TLS 1.3.

En el acerca de… de cualquier componente de Velneo se puede ver la configuración de la conexión.

Por programación, la clase VSSLInfo permite obtener información de la conexión en las aplicaciones.

Para indicar un certificado que no sea el interno que incorpora Velneo vServer, hay que especificarlo en el registro del sistema. Haz clic aquí para ampliar información al respecto.

No se soportan certificados que requieran certificados intermedios.

El servidor carga el certificado al iniciarse. Una vez iniciado, comprueba todos los días si se han actualizado los ficheros del certificado y, si han sido actualizados, cargará el nuevo certificado.

Iniciar un componente cliente de Velneo con VATPS

Ver información sobre cómo conectarnos a un servidor de Velneo.

Al establecerse la conexión TLS/SSL se seleccionará la opción más segura en ese momento, determinada por el sistema y las librerías TLS/SSL. Normalmente será la versión 1.3 de TLS/SSL.

Si se produce un error de TLS/SSL, aparece en la barra de estado de la ventana de conexión una opción para ver las excepciones que se han producido y permite ignorarlas.

Es decir, los componentes clientes siempre permitirán la conexión pese a los posibles errores de TLS/SSL que pueda haber.

En el caso de que queramos controlar los errores o incluso hacer que se cierre Velneo vClient si hay errores de TLS/SSL es algo que tendremos que programar y para ello podemos hacer uso de la clase VSSLInfo del API de Velneo para JavaScript, ya que dispone de funciones para comprobar los posibles errores de validez del certificado, dominio, etc.

No es posible conectarnos usando VATPS contra un servidor que no admita conexión segura ni viceversa, conectarnos por VATP contra un servidor que requiera conexión segura.

Funcionamiento en Velneo cloud

En Velneo Cloud la configuración de certificados es automática y transparente para el usuario.

Si necesitas configurar tu propio dominio de empresa tienes aquí toda la información.

Verificación de Certificados

La verificación de certificados garantiza la veracidad del certificado del servidor con el cual establecemos la conexión.

La verificación se realiza de forma automática al conectarnos al servidor, previamente a enviar información al servidor, con lo que garantizamos que, además de que la información viaja de forma confidencial e íntegra, se envía al servidor con el que realmente queremos establecer la conexión. (Consulta cómo activarlo en el cliente en versiones anteriores al final).

En caso de error en el establecimiento de la conexión segura, nos lo indicará en la ventana de conexión y podremos revisar los errores detectados (caducidad de los certificados, certificados erróneos, etc.).

Además, en el caso de que confiemos en el certificado pese a los errores, el usuario puede establecer excepciones de seguridad para el servidor al que nos conectamos, como se hace en los navegadores web. En ese caso, se guardará la huella del certificado, con lo que, si se produce un cambio en el certificado del servidor al que se conecta, se avisará al usuario y se le solicitará de nuevo que incluya la excepción si es necesario y confía en él pese a los errores.

En nuestra aplicación, siempre podemos comprobar el certificado usado y comprobar que es correcto, haciendo uso para ello de la clase VSSLInfo de la API de Velneo para Javascript, que nos dará información relativa a la conexión y el certificado empleado.

Para configurar certificados en el servidor, ver el apartado Cómo incluir certificados propios en el servidor.

Velneo vServer incluye un certificado propio de pruebas que ha de ser sustituido por nuestro propio certificado.

Para los componentes que ha de instalar y verificar el desarrollador (Velneo vModApache, Velneo ODBC Driver, vRemoteFunctionV7.dll) es opcional forzar la verificación del certificado. Se hace con la clave conocida verificarCertificado como en versiones anteriores.

El uso de Velneo vClient con la opción -platform minimal por defecto no verifica el certificado. Si queremos que lo haga debemos configurar la clave conocida verificarCertificado como en versiones anteriores. Si genera algún tipo de conflicto a la hora de verificar el certificado, para poder crear la excepción debemos conectarnos previamente Velneo vClient sin la opción -platform minimal a esa VRL y añadir la excepción TLS/SSL.

Para conexiones externas al servidor al que estamos conectados

Si desde la aplicación accedemos a otros servidores, mediante funciones remotas, conexiones SDV, etc., estos servidores funcionan de igual forma con respecto a las conexiones VATPS y los certificados. En el caso de certificado erróneo, la función remota o la conexión SDV no podrá establecerse, pudiéndose añadir una excepción usando Velneo vClient.

Posibles incidencias con certificados en el cliente en Windows

El certificado que se debe usar en el servidor debe estar completo (fullchain), incluyendo los certificados autorizadores intermedios.

En Windows, en el caso de no tener el certificado completo, se puede producir lentitud en el establecimiento de las conexiones.

Si quieres saber más sobre cómo configurar correctamente tu servicio VATPS consulta esta página.

Temporalmente, se puede usar en el componente cliente la clave noWaitForEncrypted con el valor: F58C2306D2DCE3E0D652950F34580AAA4BA05406, en la clave HKEY_CURRENT_USER\SOFTWARE\Velneo\beta del registro de Windows. Esta clave se puede usar hasta que se actualice en el servidor el certificado.