Hoy tenemos un evento de la serie "PROdemo: Laboratorio de soluciones de software", un proyecto especial del equipo de OCS Soft. La reunión está dedicada a la revisión y demostración de la solución Termit 2.3, un sistema de acceso terminal de OrionSoft.
En el programa: • Revisión de los cambios en la nueva versión: mejoras en la seguridad, mejoras en la interfaz de usuario. • Demostración de un escenario de aplicación de la solución en caso de necesidad de construir soluciones resistentes a desastres (reserva de centros de datos). • Demostración de la integración con sistemas de equilibrio de red de terceros. Integración con los productos de la empresa xPointNetwork.
Ponentes: Alexander Kalinin y Pavel Mametyev, expertos técnicos de OCS.
El tema de hoy está relacionado con el producto recientemente lanzado: Termit versión 2.3. Alexander Kalinin comenzó a hablar sobre las novedades y mejoras que aparecieron en esta versión, sobre los planes más cercanos del proveedor para el desarrollo de esta área.
Las mejoras y novedades en la versión 2.3 se dividieron en varias categorías, pero la más amplia es la de seguridad. Se trata de la autenticación multifactor.
El acceso terminal para usuarios externos para aumentar la seguridad requería autenticación multifactor. Apareció la posibilidad de integrar la configuración de Termit para utilizar un servidor de terceros, en el que se puede implementar el segundo factor o incluso varios factores. Apareció la posibilidad de conectar en el marco de una instalación varios directorios LDAP. En nuestro escenario, esto es muy importante, porque estamos considerando variantes de proyectos complejos, en los que se produce una transición suave de un sistema de directorio LDAP a otro. Es decir, en este caso se puede dividir el proceso, y en algún momento encontrarse en un estado intermedio, utilizando tanto un directorio como otro. Una novedad muy importante es la compatibilidad con Kerberos para clientes. Es decir, actualmente en la versión 2.3 ya se puede utilizar este método de autenticación. Esto es muy cómodo para los usuarios. No necesitan introducir datos de acceso adicionales al iniciar el cliente Termit.
Existe la posibilidad de autenticar un cliente disponible mediante un certificado. Apareció la posibilidad de redirigir tarjetas inteligentes a la sesión terminal, lo que también aumenta el ámbito de aplicación de esta solución.
Cambios en la gestión.
Se amplía el modelo de roles, apareció un nuevo rol. Se llama auditor de seguridad de la información. Los usuarios a los que se les asigna este rol tienen la posibilidad de obtener información sobre la infraestructura, acceso a los registros, pero sin la posibilidad de realizar cambios. Aparecieron mejoras en la categoría de aplicaciones y escritorios, es decir, la agrupación. Aquí el proveedor comenzó a moverse en una dirección similar a la dirección de movimiento de los líderes extranjeros que se fueron. Allí también había una asignación de aplicaciones y categorías. Ahora se puede asignar una aplicación por categorías directamente a un grupo de usuarios. Apareció una separación de la lista de aplicaciones y escritorios. Y una función pequeña, pero visualmente muy importante, ahora puede cargar iconos para las aplicaciones y escritorios publicados. La interfaz se vuelve más agradable, amigable para los usuarios.
Cambios que afectaron a la aplicación cliente. Se ha desarrollado un cliente X2Go propio para macOS. Contiene la funcionalidad necesaria para la autenticación, relacionada con los cambios de seguridad, y es compatible con SSO.
Autenticación por protocolo Kerberos. El proveedor también se está moviendo hacia el desarrollo de toda la pila de elementos, en particular, se ha escrito su propio cliente RDP para Windows. Un punto importante es que se ha añadido soporte en el lado de los clientes en la configuración de DPI. Lo único es que, actualmente, todo esto se configura en los clientes y en el marco de las políticas, esto aún no se ha implementado. Se ha mejorado el portapapeles, es bidireccional y permite intercambiar datos a través del portapapeles tanto con clientes Windows, Linux, macOS, servidor terminal Linux y viceversa.
En cuanto al soporte de los sistemas operativos en los que se despliegan los componentes de Termit.
El proveedor sigue a sus socios y líderes del mercado nacional. Por esta razón, apareció la posibilidad de desplegar componentes en las nuevas versiones del sistema operativo Astra 1.8 y RED OC 8.0. Y también se mantiene la posibilidad de desplegar tanto en OpenSST, en sistemas operativos mundiales y nacionales, también se admite Alt Linux. En particular, nuestro laboratorio de demostración está desplegado precisamente en Alt Linux. El soporte de estos sistemas operativos se ha añadido a prácticamente todos los módulos del sistema, brokers, balanceadores, servidores terminales, gateways y sistemas operativos de escritorio.
Ahora pasemos a los planes más cercanos del proveedor.
Este año, el proveedor ha planeado dos lanzamientos: el lanzamiento 2.4, que saldrá en agosto de este año, y el lanzamiento 2.5, cuyo lanzamiento está previsto para finales de este año o principios del próximo. Todo depende de la rapidez con la que se implemente la funcionalidad declarada.
El proveedor Orion soft está empezando a avanzar hacia la implementación de VDI en su producto. ¿Qué se deduce de esto? Habrá soporte para nuevos protocolos, en particular, el protocolo Loudplay, bastante extendido para canales débiles, para canales que requieren optimización. Dado que VDI es un proceso de despliegue automático de máquinas personales virtuales, habrá una integración natural con la plataforma de virtualización para automatizar este proceso. Como plataforma de virtualización para Termit se utilizará zVirt. Es decir, no será posible utilizar plataformas de virtualización de terceros como plataforma para Termit. Será posible crear servidores terminales-plantilla, máquinas virtuales, grupos de máquinas virtuales. Habrá una opción tanto de clones completos como de clones vinculados, linked-clones. Todas las máquinas virtuales se implementarán tanto con conexión estática a la sesión como con conexión dinámica. Se implementarán perfiles móviles para no tener que vincularse a máquinas virtuales concretas y la posibilidad de actualizarlas. Y se implementará un ciclo de vida de las máquinas virtuales que permitirá actualizar los pools de máquinas virtuales sin reinstalar los sistemas.
En cuanto a la versión 2.5. En esta versión se declara la implementación del despliegue automático de la infraestructura Termit zVirt, la integración con SDN de zVirt, lo que también permitirá optimizar el proceso de despliegue dinámico de pools de máquinas virtuales. Aparecerán políticas para el paso de dispositivos. En esta parte ya se implementarán políticas con las que se podrán gestionar los parámetros de la sesión de usuario desde el servidor. Y se declara la implementación de un cliente web. Además, junto con este lanzamiento, aparecerán nuevas ediciones del producto Termit VDI y zVirt VDI. Es decir, podrá adquirir el mismo zVirt a un precio determinado, para una tarea determinada. De este modo, tendrá la oportunidad de optimizar los gastos.
Ahora hablemos del escenario que hemos implementado en nuestro stand. El escenario es el siguiente. Se supone que hay dos sitios, que no están conectados entre sí. Los elementos de cada sitio se ubicaban en uno de los sitios. Los usuarios podían conectarse tanto a un sitio como a otro.
En este caso, hemos implementado el siguiente esquema: hay dos instalaciones, sitio 0 y sitio 1. En cada sitio hay un clúster de balanceador de carga tolerante a fallos. El balanceador de carga se llama xPoint UppScaler. Este es un producto de la compañía xPointNetwork, este es un proveedor chino que está presente en el mercado desde hace bastante tiempo, desde 2018. Prepara soluciones de balanceo de carga de clase corporativa que permiten implementar la tolerancia a fallos de todo el sistema. Existe la posibilidad de organizar el balanceo de carga de todos sus servicios dentro de un mismo sistema. No tendrá que introducir varios balanceadores de carga para cada sistema. Existe la posibilidad de una configuración compleja del estado de los servicios balanceados. Y uno de los momentos más importantes, en particular de esta tarea, es el soporte del balanceo de carga global, que permitirá unificar los servicios geodistribuidos. En este caso, hay un clúster de balanceo de carga, un par tolerante a fallos en un sitio en el sitio 0 y un segundo par de balanceadores de carga en otro sitio, el sitio 1.
Estos balanceadores de carga están unidos en una única configuración GSLB. Es decir, participan en el proceso de resolución de nombres. Al solicitar un recurso, en particular, aquí Termit, vlab, OCS.ru, el cliente resolverá el nombre y se le devolverá una u otra dirección, ubicada en un sitio o en otro. En el caso de que todos los sistemas funcionen con normalidad, se producirá el balanceo de carga entre los diferentes sitios, mientras que el cliente se autorizará en un sitio o en otro, menos cargado en ese momento. En caso de fallo de uno de los brokers de Termit, por ejemplo, en el sitio 0, al cliente con el nombre Termit, vlab, OCS.ru también se le resolverán dos direcciones IP virtuales. El tráfico del cliente ya se redistribuirá de forma diferente. Uno de los brokers se excluirá del balanceo de carga.
Y la tercera opción muestra una variante de catástrofe, cuando uno de los sitios deja de funcionar por completo. En este caso, todos los nodos de un sitio no estarán disponibles y el nombre Termit, vlab, OCS.ru se resolverá sólo en una dirección IP, fijada para el sitio en funcionamiento. E incluso si en este caso uno de sus brokers también no está disponible, los servicios estarán en estado no operativo, entonces de todos modos el cliente recibirá una respuesta, podrá autorizarse, los servidores terminales podrán registrarse en el broker y el cliente podrá acceder a su sesión.
Ahora voy a demostrar cómo se configura esto en el lado del balanceo de carga.
Tenemos dos clústeres. El primer clúster está ubicado en el sitio principal, el sitio 0. Consta de dos nodos, dos balanceadores de carga. También hay un segundo clúster. Allí también hay un par tolerante a fallos.
En cada uno de los clústeres están configurados servidores virtuales. Aquí hemos realizado la configuración de acuerdo con las recomendaciones del proveedor. En principio, esta instrucción es suficiente para realizar la configuración también en este balanceador de carga. Hay un servidor virtual de balanceo de carga para las conexiones de los clientes, hay un servidor virtual para la conexión de los servidores terminales, para el registro en los brokers y, por ejemplo, el cambio de redirección desde el puerto no protegido desde el 80 al 443. También se implementa en el lado del balanceador de carga. Permite no transmitir este tráfico a los brokers, sino que la redirección se produce en la etapa de conexión al balanceador de carga. También aquí se puede ver que se puede determinar el estado de los servicios balanceados. En particular, en el momento actual está configurada la comprobación del puerto de prueba, que se utiliza para determinar el estado de funcionamiento del broker. También en el proceso de explotación, en caso de realizar alguna manipulación necesaria con los brokers, se pueden desconectar desde aquí. Por ejemplo, pasar a mantenimiento uno de los brokers. Después de realizar este procedimiento, todas las conexiones de los clientes se redirigirán a uno de los brokers. Además, ambos sitios están unidos en una única configuración GSLB. Es decir, esto ya es una parte relacionada con el balanceo de carga global, con el proceso de resolución de nombres. Hay un nombre común. Aquí se implementa la forma en que hemos creado una zona separada, relacionada con GSLB, y el nombre que utilizará el cliente para conectarse. Para esta zona, los balanceadores de carga actúan como servidor DNS autoritativo. El proceso de resolución devolverá una dirección IP u otra. El estado de esta dirección se determinará mediante la prueba que se haya configurado. Aquí, por ejemplo, simplemente se hará ping a esta dirección IP. Se pueden configurar comprobaciones más complejas: puerto abierto o una solicitud determinada.
¿Cómo se verá esto desde el lado del cliente? Al conectarnos, si nos dirigimos a la dirección común Termit, vlab, OCS.ru, al final llegamos a la dirección IP virtual, que pertenece al sitio 1. Si excluimos este sitio del balanceo de carga global, o deja de funcionar, podemos simular esto desconectando el servicio GSLB conectado en el servidor virtual. Después de pasar por el mismo enlace, ya llegamos a otro sitio. Es decir, no se producirá un fallo del servicio. El cliente se conectará al sitio disponible en ese momento.
En principio, en esto, probablemente, consiste la descripción del escenario implementado. Hay dos sitios no conectados a través de la interfaz gráfica. Han aparecido categorías de aplicaciones, es decir, se pueden crear diferentes categorías, por ejemplo, Internet, aplicaciones de oficina. Para las aplicaciones ha aparecido la posibilidad de indicar iconos, que se mostrarán en el lado de una forma más comprensible para los usuarios. En cuanto a la configuración global y los catálogos OLDUB, es decir, en el momento actual tenemos conectado aquí un catálogo OLDUB, pero existe la posibilidad de añadir otro catálogo OLDUB, y dentro del existente conectado aquí se puede configurar la autenticación Kerberos. En este caso, si se configura, podrá autorizarse, autenticarse en el cliente, utilizando un ticket obtenido anteriormente al autenticarse en el sistema operativo.
Ilustraciones proporcionadas por el servicio de prensa de las compañías Orion Soft y OCS
Ahora en la página principal
