En , hablé sobre la historia de la creación de Veliam y sobre la decisión de su difusión a través del sistema SaaS. En este artículo, hablaré sobre lo que se tuvo que hacer para que el producto pasara de ser local a público. Sobre cómo comenzamos la difusión y con qué problemas nos encontramos.
Planificación
La actual parte del servidor para los usuarios estaba en Linux. Casi en cada organización hay servidores Windows, lo cual no se puede decir de Linux. La principal fortaleza de Veliam son las conexiones remotas a servidores y equipos de red detrás de NAT. Pero esta funcionalidad estaba muy estrictamente atada a que el router debía ser necesariamente Microtik. Y esto claramente no satisfaría a muchos. Primero, comencé a pensar en agregar soporte para los routers de los fabricantes más comunes. Pero entendí que esto sería una carrera interminable para ampliar la lista de empresas compatibles. Además, incluso aquellos que ya son compatibles pueden tener un conjunto diferente de comandos para cambiar las reglas de NAT de un modelo a otro. La única salida que veía a la situación era un VPN.
Dado que decidimos distribuir el producto, pero no como código abierto, no pudimos incluir diversas bibliotecas con licencias abiertas como la GPL. Este es un tema aparte; tras la decisión de vender el producto, tuvimos que revisar la mitad de las bibliotecas debido a que eran GPL. Cuando se desarrollaba para uso propio, era aceptable. Pero no es adecuado para la distribución. El primer VPN que viene a la mente es OpenVPN. Pero es GPL. También existía la opción de usar SoftEther VPN de Japón. Su licencia permitía incluirlo en nuestro producto. Después de un par de días probando diferentes formas de integrarlo para que el usuario no tuviera que configurar nada ni conocer SoftEther VPN, obtuvimos un prototipo. Todo funcionaba como debía. Sin embargo, por alguna razón, esa configuración nos incomodaba y finalmente decidimos no seguir adelante con ella. Naturalmente, abandonamos esta opción solo después de idear otra. Al final, todo se implementó sobre conexiones TCP normales. Algunas conexiones funcionan a través de un coordinador, mientras que otras van directamente a través de la tecnología Nat Hole Punching (NHP), que también se implementó en Free Pascal. Debo decir que previamente no había oído hablar de NHP. No se me habría ocurrido que se pudieran vincular 2 dispositivos de red, ambos detrás de un NAT, directamente. Estudié el tema, comprendí el principio de funcionamiento y comencé a programar. Lo planeado se llevó a cabo, el usuario se conecta con un clic al dispositivo detrás de NAT a través de RDP, SSH o Winbox sin ingresar contraseñas ni configurar el VPN. Además, la mayor parte de estas conexiones pasa por alto nuestro coordinador, lo que es beneficioso para el ping y el costo de mantenimiento de estas conexiones.
Traduciendo la parte del servidor de Linux a Windows
Hubo varios problemas al pasar a Windows. El primero es que el wmic integrado en Windows no permite hacer consultas WQL. Y en nuestro sistema, todo ya estaba basado en ello. Y había algo más, pero ahora no recuerdo por qué finalmente decidimos dejar de usarlo. Posiblemente las diferencias entre las versiones de Windows. Y el segundo problema es el multihilo. No encontrando una buena utilidad externa con una licencia 'aceptable' para nosotros, volví a abrir el IDE Lazarus y escribí la utilidad necesaria. La entrada es una lista de objetos y las consultas específicas que se necesitan hacer, y como respuesta recibo los datos. Y todo esto en modo multihilo. Excelente.
Después de configurar pthreads para PHP en Windows, pensé que todo funcionaría perfectamente, pero no fue así. Después de un tiempo de depuración, me di cuenta de que pthreads parecía funcionar, pero en nuestra sistema no lo hacía. Quedó claro que había alguna peculiaridad en el funcionamiento de pthreads en Windows. Y así fue. Leí la documentación y allí se decía que para Windows el número de hilos está limitado, además de que, si no recuerdo mal, de manera implícita. Esto se convirtió en un problema. Porque cuando comencé a reducir el número de hilos en los que la aplicación funcionaba, esta realizaba el trabajo muy lentamente. Nuevamente abrí la IDE y se agregó funcionalidad para el ping multihilo de objetos en esa misma utilidad. Y, ya de paso, también se incluyó el escaneo de puertos. Después de esto, la necesidad de pthreads para PHP desapareció, y ya no se utiliza. Luego, se añadieron varias funciones más a esta utilidad y sigue funcionando hasta el día de hoy. Después de eso, se creó un instalador para Windows que incluía Apache, PHP, MariaDB, la propia aplicación PHP y un conjunto de utilidades para interactuar con el sistema, escritas en Free Pascal. En cuanto al instalador, pensé que resolvería eso rápidamente, ya que es algo muy común y necesario para casi todo software. O no busqué de la manera correcta, o algo más. Pero siempre encontraba productos que eran o bien poco flexibles, o caros y además también poco flexibles. Sin embargo, encontré un instalador gratuito en el cual se puede prever cualquier necesidad. Este es InnoSetup. Escribo sobre esto aquí porque tuve que buscarlo, quizás le ahorre tiempo a alguien.
Renuncia al plugin en favor de su cliente
Anteriormente escribí que la parte del cliente era un navegador con un "plugin". Hubo momentos en los que, tras una actualización de Chrome, el diseño se veía un poco desajustado, o cuando Windows se actualizaba y se perdían los esquemas de URI personalizados. No quería tener ese tipo de sorpresas en la versión pública del producto. Además, los esquemas de URI personalizados empezaron a fallar tras cada actualización de Windows, ya que Microsoft eliminaba todas las ramas que no pertenecían a ellos en la sección correspondiente. También, Google Chrome ahora no permite recordar la elección de abrir o no la aplicación desde un esquema de URI personalizado, y formula esta pregunta en cada clic sobre el objeto de monitoreo. En general, era necesario un funcionamiento adecuado con el sistema local del usuario, algo que el navegador no proporcionaba. La opción más sencilla en tal esquema parecía ser crear su propio navegador, como muchos están haciendo ahora con Electron. Sin embargo, ya se habían escrito muchas cosas en Free Pascal, incluida la parte del servidor, por lo que decidimos hacer el cliente en el mismo lenguaje, en lugar de crear un zoológico de tecnologías. Así se escribió un cliente con Chromium a bordo. Después de eso, comenzó a adquirir varios complementos.
La versión
Finalmente elegimos un nombre para el sistema. Estuvimos considerando varias opciones mientras llevábamos a cabo el proceso de transformación de la versión local a SaaS. Dado que inicialmente planeábamos salir no solo al mercado interno, uno de los criterios principales para elegir el nombre fue la disponibilidad de un dominio sin usar o no muy caro en la zona ".com". Algunas funciones/módulos aún no se habían portado de la versión local a Veliam, pero decidimos lanzar con la funcionalidad actual y completar el resto en forma de actualizaciones. En la primera versión no había HelpDesk, Veliam Connector, no se podían cambiar los umbrales de activación de las notificaciones y muchas otras cosas. Compramos un Certificado de Firma de Código, firmamos las partes del cliente y del servidor. Creamos un sitio web para el producto, comenzamos los procedimientos de registro del software, de la marca registrada, etc. En resumen, estamos listos para empezar. Una ligera euforia por el trabajo realizado y por la posibilidad de que alguien use tu producto, aunque no teníamos dudas al respecto. Y entonces, alto. Un socio dijo que no se puede salir al mercado sin notificaciones en los mensajes. Se puede prescindir de muchas otras cosas, pero no de esto. Después de breves discusiones, se añadió la integración con Telegram, que fue satisfactoria para nosotros. De todos los mensajeros actuales, este es el único que ofrece acceso a su API de forma gratuita y sin procedimientos complicados de aprobación. Por otro lado, WhatsApp sugiere contactar a proveedores que cobran precios considerables por el uso de sus servicios, todas las solicitudes de acceso sin intermediarios fueron ignoradas. Y Viber… No sé quién lo usa ahora, ya que el spam y la publicidad son excesivos. A finales de diciembre, después de varias pruebas internas y pruebas entre amigos, abrimos el registro para todos y pusimos el software disponible para descarga.
Inicio de la difusión
Desde el principio entendimos que necesitábamos un pequeño flujo de usuarios del sistema para que probaran el producto en modo operativo y dieran algún primer feedback. Varias publicaciones compradas en VK dieron sus frutos. Llegaron las primeras registraciones.
Es importante decir que ingresar al mercado sin un nombre de empresa conocido y ofrecer funcionalidad de monitoreo sin agente, que requiere introducir credenciales de sus servidores y estaciones de trabajo, es muy difícil. Esto asusta a muchas personas. Desde el principio entendimos que habría problemas y estábamos preparados técnica y moralmente para enfrentarlos. Todas las conexiones remotas, a pesar de que RDP y SSH ya están cifrados por defecto, se cifran adicionalmente con nuestro software usando el estándar AES. Todos los datos de los servidores locales se transmiten a la nube a través de HTTPS. Las credenciales se almacenan en un formato cifrado. Las claves de cifrado para todos los subsistemas de cada cliente son individuales. Para las conexiones remotas se utilizan claves de cifrado de sesión.
Todo lo que podemos hacer en esta situación para que la gente se sienta más tranquila es ser lo más transparentes posible, trabajar en la seguridad y no cansarnos de responder a las preguntas que les inquietan.
Para muchos, la conveniencia y funcionalidad del software superan el miedo, y se registran. Algunas personas en publicaciones en VK han dicho que este software no se puede usar porque recopila sus contraseñas y es una empresa completamente desconocida. Hay que decir que esta opinión no era única. Muchos simplemente no entienden que, al instalar otro software propietario en el servidor, que funciona como un servicio, este también tiene plenos derechos en el sistema y no necesita credenciales para hacer cosas ilegales (es obvio que se puede cambiar el usuario desde el que se inicia el servicio, pero aquí también se puede introducir cualquier cuenta). De hecho, las preocupaciones de la gente son comprensibles. Instalar software en un servidor es algo habitual, pero introducir credenciales es un poco aterrador e íntimo, ya que buena parte de las personas utiliza una única contraseña para todos los servicios, y da pereza crear una cuenta separada incluso para las pruebas. Pero en este momento hay una gran cantidad de servicios en los que la gente confía sus credenciales y más. Y nosotros nos esforzamos por ser uno de ellos.
Muchos comentarios eran del tipo que habíamos robado esto de algún lugar. Nos sorprendió un poco. Bueno, es la opinión de una persona, pero tales comentarios aparecían en varias publicaciones de diferentes personas. Al principio no sabíamos cómo reaccionar. Si sentir tristeza porque algunas personas piensan que en Rusia nadie puede hacer nada por sí mismo, y solo se puede robar, o alegrarnos de que creen que solo se puede robar algo así.
Ahora hemos completado el procedimiento para obtener el Certificado de Firma de Código EV. Para obtenerlo, es necesario pasar por una serie de verificaciones y enviar un montón de documentos sobre la empresa, algunos de los cuales deben ser certificados por un abogado. Obtener el certificado de firma de código EV en condiciones de pandemia es un tema aparte para un artículo. El procedimiento se extendió durante un mes. Y fue un mes de no esperar, sino de constantes solicitudes de documentos adicionales. Puede que la pandemia no tenga nada que ver, y que a todos les haya tomado tanto tiempo el procedimiento. Compartan.
Algunos dicen que no vamos a usarlo porque no tenemos el certificado del FSTEC. Tenemos que explicar que no podemos obtenerlo y no lo haremos porque para obtener ese certificado, la encriptación debe ser conforme a GOST, y planeamos distribuir el software no solo en Rusia y usamos AES.
Todos estos comentarios generaban cierta incertidumbre acerca de si era posible promocionar un producto que necesita que se ingresen cuentas, sin estar en el radar. Incluso considerando que sabíamos que habría quienes tuvieran una actitud muy negativa al respecto. Después de que la cantidad de registros superó mil, dejamos de pensar en eso. Especialmente después de que además de la negatividad de aquellos que ni siquiera probaron el producto, comenzaron a aparecer también comentarios muy agradables. Debo decir que esos comentarios positivos son el mayor motivador para el desarrollo del producto.
Añadiendo funcionalidad de acceso remoto para empleados
Una de las tareas más comunes de los clientes es "conceder a Iván acceso a su computadora desde casa". Configuramos una VPN en Mikrotik y creamos cuentas para los usuarios. Pero realmente es un problema. Los usuarios no son capaces de seguir las instrucciones y realizar los pasos para conectarse a la VPN. Existen diferentes versiones de Windows. En una versión todo se conecta bien, en otra se necesita un protocolo diferente. Y, en general, esto siempre ha estado relacionado con la reconfiguración del equipo de red, que actuaba como servidor de VPN, y no todos los empleados tienen acceso a él, lo que resultaba incómodo.
Pero ya tenemos conexiones remotas a servidores y equipos de red. ¿Por qué no aprovechar el transporte ya existente y crear una pequeña utilidad que se pueda entregar al usuario para conectarse fácilmente? Solo quería que el usuario no tuviera que introducir nada complicado. Simplemente un botón "conectar". Pero, ¿cómo va a entender esta utilidad a dónde conectarse si solo tiene un botón? La idea era compilar la aplicación necesaria en línea en nuestros servidores. El administrador del sistema presiona el botón "descargar acceso directo", y se envía una orden a nuestra nube para compilar un binario individual con la información integrada para conectarse al servidor o computadora deseada por RDP. En general, esto se podría hacer. Pero es un proceso largo; el administrador tendría que esperar primero a que el binario se compile y luego a que se descargue. Por supuesto, se podría añadir simplemente un segundo archivo de configuración, pero ya serían dos archivos, y por simplicidad, el usuario necesita uno. Un archivo, un botón y nada de instaladores. Después de investigar un poco en Google, llegué a la conclusión de que si se añade algún tipo de información al final de un “.exe” compilado, no se estropea (bueno, casi). Se puede añadir cualquier cosa, incluso Guerra y Paz, y funcionará como antes. Sería un pecado no aprovechar esto. Ahora se puede descomprimir la aplicación directamente en el cliente, que por cierto se llama Veliam Connector, y simplemente anexar la información necesaria para la conexión al final. Y la propia aplicación sabe qué hacer con eso. ¿Por qué escribí "bueno, casi" más arriba entre paréntesis? Porque por esta comodidad, hay que pagar el precio de que la aplicación pierde su firma de la clave electrónica. Pero en este momento, consideramos que es un precio pequeño por tal comodidad.
Licencias de módulos de terceros
Como mencioné anteriormente, una vez que se decidió hacer el producto accesible públicamente y no solo para uso interno, tuvimos que trabajar arduamente y buscar sustituciones para algunos módulos que no permitían incluirse en nuestro producto. Pero, después del lanzamiento, descubrimos accidentalmente algo bastante desagradable. En el Veliam Server, que estaba del lado del cliente, teníamos la base de datos MariaDB. Y esta tiene licencia GPL. La licencia GPL implica que el software debe ser de código abierto, y si nuestro producto incluye MariaDB, que tiene esta licencia, entonces nuestro producto también debe estar bajo esta licencia. Pero, afortunadamente, el objetivo de esta licencia es el código abierto, no castigar en los tribunales a quienes cometen un error accidentalmente. Si el titular de los derechos presenta una reclamación, debe notificar por escrito a la parte infractora, la cual tiene 30 días para corregir la infracción. Nosotros mismos detectamos nuestro error y no recibimos cartas, y rápidamente comenzamos a explorar opciones para resolver el problema. La salida resultó evidente: migrar a SQLite. Esta base de datos no tiene restricciones de licencia. La mayoría de los navegadores modernos utilizan SQLite, al igual que muchas otras aplicaciones. Encontré en internet información de que SQLite se considera la base de datos más extendida del mundo, precisamente por los navegadores, aunque no busqué pruebas, así que eso es información inexacta. Comencé a estudiar lo que implicaba la migración a SQLite.
Esto se convierte en una tarea no trivial cuando hay varios cientos de servidores instalados en clientes con MariaDB y datos en ella. Algunas características de MariaDB no están disponibles en SQLite. Por ejemplo, en el código se utilizaron consultas del tipo
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Esta construcción no solo realiza una selección de la tabla, sino que también bloquea esas filas de datos. Y también tuvimos que reescribir varias otras construcciones. Pero además de tener que reescribir muchas consultas, también tuvimos que idear un mecanismo que, al actualizar el Veliam Server en el cliente, migre todos los datos a la nueva base de datos y elimine la antigua. Además, las transacciones no funcionaban en SQLite y eso fue un problema real. Pero, tras investigar en las vastedades de la red, encontré sin problemas que se pueden habilitar las transacciones en SQLite simplemente enviando un comando al conectarse.
PRAGMA journal_mode=WAL;Al final, la tarea se ha completado y ahora la parte del servidor de los clientes funciona con SQLite. No hemos notado ningún cambio en el funcionamiento del sistema.
Nuevo HelpDesk
Fue necesario portar el sistema HelpDesk de la versión interna a la versión SaaS, pero con algunos cambios. Lo primero que se quería hacer era la integración con el dominio del cliente en lo que respecta a la autorización transparente de los usuarios en el sistema. Ahora, para acceder al HelpDesk y dejar una solicitud en el sistema, el usuario solo hace clic en el acceso directo en el escritorio y se abre el navegador. El usuario no introduce ninguna credencial. Un módulo para Apache SSPI, que forma parte de Veliam Server, autoriza automáticamente al usuario con la cuenta de dominio. Para dejar una solicitud en el sistema, cuando el usuario está fuera de la red corporativa, presiona un botón y recibe un enlace por correo electrónico, con el cual se autoriza en el sistema HelpDesk sin contraseñas. Si el usuario es desactivado o eliminado en el dominio, su cuenta en HelpDesk también dejará de funcionar. De este modo, el administrador del sistema no necesita preocuparse por las cuentas tanto en el dominio como en HelpDesk. Si un empleado es despedido, se desactiva la cuenta en el dominio y listo, no podrá acceder al sistema ni desde la red corporativa ni a través del enlace. Para que esta integración funcione, el administrador del sistema necesita crear un GPO que y .
Lo segundo que consideramos absolutamente necesario para los sistemas HelpDesk, al menos para nosotros, es la conexión al solicitante directamente desde la solicitud con un solo clic. Además, las conexiones deben realizarse incluso si el administrador del sistema se encuentra en otra red. Para el outsourcing esto es obligatorio, y también es muy necesario para los administradores de sistemas internos. Ya hay varios productos que manejan perfectamente la tarea de conexiones remotas. Y hemos decidido crear integraciones para ellos. Ahora hemos hecho la integración para VNC, y en el futuro planeamos agregar Radmin y TeamViewer. Usando nuestro transporte de red para conexiones remotas a la infraestructura, hemos asegurado que VNC se conecte a estaciones de trabajo remotas detrás de NAT. Lo mismo sucederá con Radmin. Ahora, para conectarse a un usuario, solo hay que hacer clic en el botón “conectar al solicitante” en la propia solicitud. Se abre el cliente VNC y se conecta al solicitante, sin importar si están en la misma red o si uno está en casa en zapatillas. Previamente, el administrador del sistema debe instalar el VNC Server en todas las estaciones de trabajo mediante políticas de grupo.
Ahora mismo estamos migrando a un nuevo HelpDesk y utilizamos la integración con el dominio y VNC. Es muy conveniente para nosotros. Ahora podemos dejar de pagar por TeamViewer, que utilizamos durante más de tres años para nuestra atención al cliente.
¿Qué planeamos hacer a continuación?
Cuando lanzamos el producto, no ofrecimos planes de pago, simplemente limitamos el plan gratuito a 50 objetos de monitoreo. Creímos que cinco docenas de dispositivos de red y servidores serían suficientes para todos. Y pronto comenzaron a llegar solicitudes para aumentar el límite. Decir que estábamos un poco sorprendidos sería un eufemismo. ¿Acaso nuestro software había llamado la atención de empresas con tal cantidad de servidores? Ampliamos el límite de forma gratuita para aquellos que hicieron tales solicitudes. A algunos les preguntamos, en respuesta a sus pedidos, por qué necesitaban tanto, ¿acaso tenían esa cantidad de servidores y equipos de red? Y resultó que los administradores de sistemas comenzaron a usar el sistema de una manera que nunca habíamos planeado. Todo resultó ser simple: comenzaron a monitorear no solo servidores, sino también estaciones de trabajo con nuestro software. De allí el gran número de solicitudes para ampliar los límites. Ahora ya hemos introducido planes de pago y los límites se pueden ampliar de forma autónoma.
Los servidores casi siempre trabajan con almacenamiento de red o con discos locales en un arreglo RAID. Y, en un principio, creamos el producto para ellos. Y el monitoreo SMART no era relevante para esta tarea. Sin embargo, dado que la gente adaptó el software para monitorear estaciones de trabajo, surgieron solicitudes para implementar el monitoreo SMART. Pronto lo implementaremos.
Con la llegada de Veliam Connector, ya no es necesario desplegar un servidor VPN en la red corporativa, hacer RDGW o simplemente redirigir puertos a las máquinas necesarias para conectarse por RDP. Muchas personas utilizan nuestro sistema solo para estas conexiones remotas. Veliam Connector solo está disponible para Windows, y algunos usuarios de empresas se conectan desde sus laptops en casa con MacOS a estaciones de trabajo o terminales en la red corporativa. Así que el administrador del sistema se ve obligado, debido a unos pocos usuarios, a volver a la cuestión de la redirección de puertos o VPN. Por eso, ahora estamos terminando la versión de Veliam Connector para MacOS. Los usuarios de su querido equipo de Apple también podrán conectarse a la infraestructura corporativa con un solo clic.
Me encanta que, con una gran cantidad de usuarios en el sistema, no hay que romperse la cabeza sobre lo que la gente necesita y lo que sería más conveniente. Ellos mismos escriben sus deseos, así que hay muchos planes de desarrollo a corto plazo.
Paralelamente, planeamos ahora traducir el sistema al inglés y expandirlo al extranjero. Aún no sabemos cómo vamos a distribuir el producto fuera de nuestro país, estamos buscando opciones. Quizás más adelante habrá un artículo separado sobre esto. Tal vez alguien de los que lea este artículo pueda sugerir la dirección correcta, o tal vez sepa cómo hacerlo y ofrezca sus servicios. Agradeceremos cualquier ayuda.
Fuente: habr.com
