В , hablé sobre los antecedentes de la creación de Veliam y la decisión de distribuirlo a través del sistema SaaS. En este artículo hablaré sobre lo que tuve que hacer para que el producto no fuera local, sino público. Sobre cómo empezó la distribución y qué problemas encontraron.
planificación
El backend actual para los usuarios estaba en Linux. Casi todas las organizaciones tienen servidores Windows, lo que 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 ligada al hecho de que el enrutador tenía que ser Mikrotik. Y esto obviamente no satisfaría a muchos. Primero comencé a pensar en agregar soporte para enrutadores de los proveedores más comunes. Pero entendí que se trataba de una carrera interminable para ampliar la lista de empresas apoyadas. Además, aquellos que ya son compatibles pueden tener un conjunto diferente de comandos para cambiar las reglas NAT de un modelo a otro. La única salida a la situación parecía ser una VPN.
Como decidimos distribuir el producto, pero no como código abierto, se hizo imposible incluir varias bibliotecas con licencias abiertas como GPL. Este es generalmente un tema aparte, después de tomar la decisión de vender el producto, tuve que revisar la mitad de las bibliotecas debido a que eran GPL. Cuando escribían para ellos mismos, era normal. Pero no apto para distribución. La primera VPN que me viene a la mente es OpenVPN. Pero es GPL. Otra opción era utilizar la VPN japonesa SoftEther. Su licencia le permitió incluirlo en su producto. Luego de un par de días de diversas pruebas sobre cómo integrarlo de tal manera que el usuario no necesite configurar nada de nada y conocer SoftEther VPN, se obtuvo un prototipo. Todo era como debería ser. Pero por alguna razón este plan todavía nos confundió y finalmente lo abandonamos. Pero, naturalmente, se negaron después de que se les ocurrió otra opción. Al final, todo se hizo mediante conexiones TCP normales. Algunas conexiones funcionan a través de un coordinador, otras directamente a través de la tecnología Nat Hole Punching (NHP), que también se implementó en Free Pascal. Debo decir que nunca antes había oído hablar de NHP. Y nunca se me ocurrió que era posible conectar 2 dispositivos de red, ambos directamente detrás de NAT. Estudié el tema, entendí el principio de funcionamiento y me senté a escribir. El plan se realiza, el usuario se conecta con un clic al dispositivo deseado detrás de NAT a través de RDP, SSH o Winbox sin ingresar contraseñas ni configurar una VPN. Además, la mayoría de estas conexiones pasan por nuestro coordinador, lo que tiene un buen efecto en el ping y el coste del mantenimiento de estas conexiones.
Transferir el lado del servidor de Linux a Windows
Hubo varios problemas al cambiar a Windows. La primera es que el wmic integrado en Windows no permite realizar consultas WQL. Y en nuestro sistema ya todo estaba construido sobre ellos. Y había algo más, pero ahora se me ha olvidado por qué finalmente abandonaron su uso. Posiblemente diferencias entre las versiones de Windows. Y el segundo problema es el subproceso múltiple. Al no encontrar una buena utilidad de terceros con una licencia "aceptable" para nosotros, lancé nuevamente el IDE de Lazarus. Y escribí la utilidad necesaria. La entrada es la lista requerida de objetos y qué consultas específicas deben realizarse, y en respuesta recibo datos. Y todo ello en modo multiproceso. Excelente.
Después de configurar pthreads para PHP Windows, pensé que todo comenzaría de inmediato, pero ese no fue el caso. Después de un tiempo de depuración, me di cuenta de que pthreads parecía funcionar, pero no en nuestro sistema. Quedó claro que existe alguna peculiaridad al trabajar con pthreads en Windows. Y así fue. Leí la documentación y allí estaba escrito que para Windows el número de subprocesos es limitado y, que yo recuerde, implícitamente. Esto se convirtió en un problema. Porque cuando comencé a reducir la cantidad de subprocesos en los que se ejecutaba la aplicación, hizo el trabajo muy lentamente. Abrí el IDE nuevamente y se agregó a la misma utilidad la funcionalidad para hacer ping a objetos con múltiples subprocesos. Bueno, allí también se están realizando muchos escaneos de puertos. En realidad, después de esto, la necesidad de pthreads para PHP desapareció y ya no se usa. Además, se agregaron varias funcionalidades más a esta utilidad y todavía funciona hasta el día de hoy. Posteriormente, se montó 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 rápidamente este problema, porque... Esto es algo muy común y necesario para casi todos los programas. O estaba buscando en el lugar equivocado o algo más. Pero constantemente me encontraba con productos que no eran lo suficientemente flexibles o eran caros y además inflexibles. Y, sin embargo, encontré un instalador gratuito en el que será posible satisfacer cualquier deseo. Este es InnoSetup. Estoy escribiendo sobre esto aquí porque tuve que buscarlo en caso de que le ahorre tiempo a alguien.
Rechazo del complemento a favor de su cliente
Anteriormente escribí que la parte del cliente era un navegador con un "complemento". Hubo momentos en que Chrome se actualizó y el diseño estaba un poco torcido, luego se actualizó Windows y el esquema de URI personalizado desapareció. Realmente no quería tener este tipo de sorpresas en la versión pública del producto. Además, la URI personalizada comenzó a desaparecer después de cada actualización de Windows. Microsoft simplemente eliminó todas las ramas que no eran sus en la sección requerida. Además, Google Chrome ahora no le permite recordar la elección de abrir o no una aplicación desde el uri personalizado, y hace esta pregunta cada vez que hace clic en un objeto de monitoreo. Bueno, en general era necesaria una interacción normal con el sistema local del usuario, algo que el navegador no proporciona. La opción más sencilla en este esquema parece ser simplemente crear su propio navegador, como muchos lo están haciendo ahora a través de Electron. Pero ya se habían escrito muchas cosas en Free Pascal, incluso en la parte del servidor, por lo que decidimos hacer el cliente en el mismo idioma y no crear un zoológico. Así se redactó un cliente con Chromium a bordo. Después de eso, comenzó a adquirir varios flejes.
Lanzamiento
Finalmente elegimos un nombre para el sistema. Revisamos constantemente varias opciones mientras estaba en marcha el proceso de conversión de la versión local a SaaS. Dado que inicialmente planeamos ingresar no solo al mercado interno, el criterio principal para seleccionar un nombre fue la presencia de un dominio desocupado o no muy caro en la zona ".com". Algunas funciones/módulos aún no se han portado de la versión local a Veliam, pero decidimos lanzarlos con la funcionalidad actual y completar el resto como actualizaciones. En la primera versión no había HelpDesk, Veliam Connector, era imposible cambiar los umbrales para los activadores de notificaciones y mucho más. Compramos un Certificado de firma de código y firmamos las partes del cliente y del servidor. Redactamos un sitio web para el producto, iniciamos trámites para registrar software, una marca comercial, etc. En general, estamos listos para comenzar. Una ligera euforia por el trabajo realizado y por el hecho de que quizás alguien utilice su producto, aunque no teníamos dudas al respecto. Y luego para. El socio dijo que es imposible ingresar al mercado sin notificaciones a través de mensajeros. Es posible sin muchas otras cosas, pero no sin esto. Después de un poco de debate, se añadió la integración con Telegram, lo que nos convenía. De todos los programas de mensajería instantánea actuales, este es el único que proporciona acceso a sus API de forma gratuita y sin complejos procedimientos de aprobación. El mismo WhatsApp sugiere ponerse en contacto con proveedores que cobran mucho dinero por utilizar sus servicios; todas las cartas solicitando acceso sin juntas fueron ignoradas. Bueno, Viber... No sé quién lo usa ahora, porque... El spam y la publicidad están fuera de serie. A finales de diciembre, después de una serie de pruebas internas y entre amigos, se abrió el registro para todos y el software estuvo disponible para su descarga.
Inicio de distribución
Desde el principio entendimos que necesitábamos un pequeño flujo de usuarios del sistema para que pudieran probar el producto en modo combate y dar sus primeros comentarios. Varias publicaciones compradas en VK dieron sus frutos. Han llegado las primeras inscripciones.
Aquí hay que decir que es muy difícil ingresar al mercado cuando su empresa no tiene un nombre famoso y, al mismo tiempo, brindar una funcionalidad de monitoreo sin agentes en la que necesita ingresar cuentas desde sus servidores y estaciones de trabajo. Esto asusta a mucha gente. Comprendimos desde el principio que esto plantearía problemas y estábamos preparados para ello tanto técnica como moralmente. Todas las conexiones remotas, a pesar de que RDP y SSH ya están cifradas de forma predeterminada, nuestro software las cifra adicionalmente utilizando el estándar AES. Todos los datos de los servidores locales se transfieren a la nube a través de HTTPS. Las cuentas se almacenan de forma cifrada. Las claves de cifrado para todos los subsistemas son individuales para todos los clientes. Para conexiones remotas, generalmente se utilizan claves de cifrado de sesión.
Lo único que podemos hacer en esta situación para que la gente se sienta más tranquila es ser lo más abiertos posible, trabajar por la seguridad y no cansarnos de responder a las preguntas de la gente.
Para muchos, la comodidad y funcionalidad del software superan el miedo y lo registran. Algunas personas escribieron en publicaciones publicadas en VK que este software no se puede utilizar porque Esta es una colección de sus contraseñas y, en general, una empresa sin nombre. Hay que decir que más de una persona tuvo esta opinión. Muchas personas simplemente no entienden que cuando instalan otro software propietario en un servidor que se ejecuta como un servicio, este también tiene todos los derechos en el sistema y no necesitan cuentas para hacer algo ilegal (está claro que puedes cambiar el usuario desde el cual se lanza el servicio, pero aquí también se puede ingresar cualquier cuenta). De hecho, los temores de la gente son comprensibles. Instalar software en un servidor es algo común, pero ingresar a una cuenta da un poco de miedo e intimidad, ya que una buena mitad de las personas tienen la misma contraseña para todos los servicios, y crear una cuenta separada incluso para una prueba es una tarea perezosa. Pero en este momento hay una gran cantidad de servicios en los que la gente confía sus credenciales y más. Y nos esforzamos por convertirnos en uno de ellos.
Hubo muchos comentarios que decían que lo robamos en alguna parte. Esto nos sorprendió un poco. Bueno, está bien, la opinión de una persona, pero esos comentarios se encontraron en varias publicaciones de diferentes personas. Al principio no supieron cómo reaccionar ante esto. O estar triste porque algunas personas tienen la opinión de que en Rusia nadie puede hacer nada por sí solo, sino sólo robar, o alegrarse de que piensen que esto sólo se puede robar.
Ya hemos completado el procedimiento para obtener un Certificado de firma de código EV. Para obtenerlo, es necesario pasar una serie de controles y enviar una serie de documentos sobre la empresa, algunos de los cuales deben estar certificados por un abogado. Obtener un certificado EV Code Sign durante una pandemia es un tema aparte para un artículo. El trámite duró un mes. Y no fue un mes de espera, sino de constantes solicitudes de documentos adicionales. ¿Quizás la pandemia no tuvo nada que ver y el trámite tomó tanto tiempo para todos? Compartir.
Algunos dicen que no lo usaremos porque no existe un certificado FSTEC. Tenemos que explicar que no podemos obtenerlo ni lo haremos, porque para obtener este certificado, el cifrado debe realizarse de acuerdo con GOST y planeamos distribuir el software no solo en Rusia y usar AES.
Todos estos comentarios arrojan algunas dudas de que sea posible promocionar un producto que requiere ingresar cuentas sin que sea conocido públicamente. Aunque sabíamos que habría quienes tendrían una actitud muy negativa hacia esto. Después de que el número de inscripciones superó el millar, dejamos de pensar en ello. Sobre todo después de que, además de la negatividad de quienes ni siquiera habían probado el producto, empezaron a aparecer críticas muy agradables. Hay que decir que estas críticas positivas son el mayor motivador para el desarrollo de productos.
Agregar funcionalidad de acceso remoto para empleados
Una de las tareas frecuentes de los clientes es "darle a Vanya acceso a su computadora desde casa". Creamos VPN en Mikrotik y creamos cuentas para los usuarios. Pero este es un problema real. Los usuarios no pueden ver las instrucciones ni seguirlas paso a paso para conectarse a través de VPN. Diferentes versiones de Windows. En un Windows todo conecta bien, en otro se necesita un protocolo diferente. Y en general, esto siempre estuvo asociado con la reconfiguración del equipo de red, que actuaba como servidor VPN, y no todos los empleados tienen acceso a él y esto era un inconveniente.
Pero ya contamos con conexiones remotas a servidores y equipos de red. ¿Por qué no utilizar un transporte ya preparado y crear una pequeña utilidad separada que simplemente pueda entregársela al usuario para que se conecte? Solo quería asegurarme de que el usuario no ingresara nada abstruso allí. Sólo un botón "conectar". Pero, ¿cómo entenderá esta utilidad dónde conectarse si solo tiene un botón? Surgió la idea de crear la aplicación necesaria en línea en nuestros servidores. El administrador del sistema hace clic en el botón "descargar acceso directo" y se envía un comando a nuestra nube para crear un binario individual con información cableada para conectarse al servidor/computadora deseada a través de RDP. En general, esto podría hacerse. Pero esto lleva mucho tiempo; el administrador tendría que esperar primero hasta que se compile el binario y luego se descargue. Por supuesto, sería posible simplemente agregar un segundo archivo con la configuración, pero ya son 2 archivos y, por simplicidad, el usuario necesita uno. Un archivo, un botón y sin instaladores. Después de leer un poco en Google, llegué a la conclusión de que si agregas algo de información al final del “.exe” compilado, entonces no se deteriora (bueno, casi). Al menos puedes agregar guerra y paz allí, y funcionará como antes. Sería un pecado no aprovechar esto. Ahora puede simplemente descomprimir la aplicación sobre la marcha, directamente en el cliente, por cierto, se llama Veliam Connector, y simplemente agregar la información necesaria para conectarse al final. Y la propia aplicación sabe qué hacer con ella. ¿Por qué escribí “bueno casi” entre paréntesis un poco más arriba? Porque hay que pagar por esta comodidad porque la aplicación pierde su firma digital. Pero en esta etapa, creemos que es un pequeño precio a pagar por tal conveniencia.
Licencias de módulos de terceros
Ya escribí anteriormente que después de que se decidió hacer que el producto estuviera disponible públicamente, y no solo para nuestro propio uso, tuvimos que trabajar duro y buscar reemplazos para algunos módulos que no permitían incluirnos en nuestro producto. Pero después del lanzamiento, se descubrió accidentalmente algo muy desagradable. Veliam Server, que estaba en el lado del cliente, incluía el DBMS MariaDB. Y 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 debe estar bajo esta licencia. Pero, afortunadamente, el propósito de esta licencia es de código abierto y no castigar a quienes accidentalmente cometen errores en los tribunales. Si el titular de los derechos de autor tiene un reclamo, lo notifica por escrito al infractor y debe eliminar la infracción dentro de los 30 días. Nosotros mismos descubrimos nuestro error y no recibimos ninguna carta e inmediatamente comenzamos a considerar opciones para resolver el problema. La solución resultó ser obvia: cambiar a SQLite. Esta base de datos no tiene restricciones de licencia. La mayoría de los navegadores modernos utilizan SQLite y muchos otros programas. Encontré información en Internet de que SQLite es considerado el DBMS más extendido en el mundo, precisamente por los navegadores, pero no busqué pruebas, por lo que esta es información inexacta. Comencé a estudiar los peligros de cambiar a SQLite.
Esto se convierte en una tarea no trivial cuando los clientes tienen varios cientos de servidores instalados con MariaDB y datos en ellos. Algunas funciones de MariaDB no están disponibles en SQLite. Bueno, por ejemplo, en el código usamos consultas como
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 los datos de la fila. Y también hubo que reescribir varios diseños más. Pero además del hecho de que tuvimos que reescribir muchas consultas, también tuvimos que idear un mecanismo que, al actualizar el servidor Veliam del cliente, trasladara todos los datos al nuevo DBMS y eliminara el anterior. Además, las transacciones en SQLite no funcionaban y esto era un problema real. Pero después de leer la inmensidad de la World Wide Web, descubrí sin problemas que las transacciones en SQLite se pueden habilitar pasando un simple comando al conectarse.
PRAGMA journal_mode=WAL;Como resultado, la tarea se completó y ahora la parte del servidor del cliente se ejecuta en SQLite. No notamos ningún cambio en el funcionamiento del sistema.
Nueva mesa de ayuda
Fue necesario migrar el sistema HelpDesk de la versión interna a la versión SaaS, pero con algunos cambios. Lo primero que quería hacer era la integración con el dominio del cliente en términos de autorización de usuario transparente en el sistema. Ahora, para iniciar sesión en HelpDesk y dejar una solicitud en el sistema, el usuario simplemente hace clic en el acceso directo en el escritorio y se abre el navegador. El usuario no ingresa ninguna credencial. El módulo para Apache SSPI, que forma parte de Veliam Server, autoriza automáticamente al usuario bajo una cuenta de dominio. Para dejar una solicitud en el sistema cuando el usuario se encuentra fuera de la red corporativa, hace clic en un botón y recibe en su correo electrónico un enlace a través del cual inicia sesión en el sistema HelpDesk sin contraseñas. Si un usuario es deshabilitado o eliminado en un dominio, la cuenta de HelpDesk también dejará de funcionar. Por lo tanto, el administrador del sistema no necesita monitorear las cuentas tanto en el dominio como en el propio HelpDesk. Un empleado renuncia: desconecta su cuenta en el dominio y listo, no inicia sesión en el sistema ni desde la red corporativa ni a través de un enlace. Para que esta integración funcione, el administrador del sistema necesita crear un GPO, que и .
Lo segundo que consideramos extremadamente necesario para los sistemas HelpDesk, al menos para nosotros, es conectarnos con el solicitante directamente desde la aplicación con un solo clic. Además, las conexiones deben realizarse si el administrador del sistema está en una red diferente. Para la subcontratación esto es obligatorio, pero para los administradores de sistemas a tiempo completo también suele ser muy necesario. Ya existen varios productos que hacen un excelente trabajo con las conexiones remotas. Y decidimos hacer integraciones para ellos. Ahora nos hemos integrado para VNC y en el futuro planeamos agregar Radmin y TeamViewer. Utilizando nuestro transporte de red para conexiones de infraestructura remota, hicimos que VNC se conectara a estaciones de trabajo remotas detrás de NAT. Lo mismo ocurrirá con Radmin. Ahora, para conectarse con un usuario, solo necesita hacer clic en el botón "conectarse con el solicitante" en la propia aplicación. El cliente VNC se abre y se conecta con el solicitante, independientemente de si está en la misma red o sentado en casa en pantuflas. Primero, el administrador del sistema, mediante GPO, debe instalar VNC Server en las estaciones de trabajo de todos.
Ahora nosotros mismos estamos cambiando al nuevo HelpDesk y utilizando la integración con el dominio y VNC. Esto es muy conveniente para nosotros. Ahora podemos evitar pagar por TeamViewer, que utilizamos desde hace más de tres años para ejecutar nuestro servicio de soporte.
¿Qué planeamos hacer a continuación?
Cuando lanzamos el producto, no hicimos ninguna tarifa paga, sino que simplemente limitamos la tarifa gratuita a 50 objetos de monitoreo. Pensamos que cinco docenas de dispositivos de red y servidores deberían ser suficientes para todos. Y luego empezaron a llegar solicitudes para aumentar el límite. Decir que nos quedamos un poco sorprendidos es no decir nada. ¿Están realmente interesadas en nuestro software las empresas que tienen tantos servidores? Ampliamos el límite de forma gratuita para quienes realizaron dichas solicitudes. En respuesta a su solicitud, les preguntamos a algunos por qué necesitaban tanto, si realmente tenían tantos servidores y equipos de red. Y resultó que los administradores del sistema comenzaron a utilizar el sistema de formas que no habíamos planeado en absoluto. Todo resultó simple: nuestro software comenzó a monitorear no solo los servidores, sino también las estaciones de trabajo. De ahí que haya muchas peticiones para ampliar los límites. Ahora ya hemos introducido tarifas pagas y los límites se pueden ampliar de forma independiente.
Los servidores casi siempre funcionan con sistemas de almacenamiento o discos locales en una matriz RAID. E inicialmente hicimos el producto para ellos. Y el monitoreo SMART no era interesante para esta tarea. Pero teniendo en cuenta el hecho de que la gente ha adaptado software para monitorear las estaciones de trabajo, han aparecido solicitudes para la implementación del monitoreo SMART. Lo implementaremos pronto.
Con la llegada de Veliam Connector, se hizo innecesario implementar un servidor VPN en la red corporativa, o hacer RDGW, o simplemente reenviar puertos a las máquinas necesarias para conectarse a través de RDP. Mucha gente utiliza nuestro sistema sólo para estas conexiones remotas. Veliam Connector está disponible sólo para Windows y algunos usuarios de empresas se conectan desde portátiles domésticos con MacOS a estaciones de trabajo o terminales de la red corporativa. Y resulta que el administrador del sistema se ve obligado, debido a varios usuarios, a volver al tema del reenvío o VPN. Por lo tanto, ahora estamos terminando de hacer una versión de Veliam Connector para MacOS. Los usuarios de su tecnología Apple favorita también tendrán la oportunidad de conectarse a la infraestructura corporativa con un solo clic.
Realmente me gusta el hecho de que, al tener una gran cantidad de usuarios del sistema, no es necesario devanarse los sesos sobre lo que la gente necesita y qué será más conveniente. Ellos mismos escriben sus deseos, por lo que hay muchos planes de desarrollo para el futuro próximo.
Paralelamente, ahora estamos planeando comenzar a traducir el sistema al inglés y distribuirlo en el extranjero. Aún no sabemos cómo distribuiremos el producto fuera de nuestro país, estamos buscando opciones. Quizás haya un artículo aparte sobre esto más adelante. Quizás alguien que haya leído este artículo pueda sugerir el vector requerido, o él mismo sepa y sepa cómo hacerlo y ofrecerá sus servicios. Agradeceríamos su ayuda.
Fuente: habr.com