La vida de un ingeniero de redes fue feliz y despreocupada hasta que apareció una puerta de enlace de cifrado certificada. De acuerdo, tratar con soluciones diseñadas para encriptar canales de transmisión de datos de acuerdo con GOST no es una tarea fácil. Es bueno si se trata de productos conocidos y comprensibles. Recordemos el mismo "S-Terra" (ya hemos escrito sobre su S-Terra Gateway ). Pero, ¿qué hacer con soluciones más exóticas basadas en sus propios protocolos de cifrado, por ejemplo, "Continent" (de "Security Code") o ViPNet Coordinator HW (de "Infotex")? En este artículo intentaré facilitar la inmersión en el mundo de ViPNet (algún día también hablaremos de Continent) y contarles qué problemas me enfrenté y cómo los resolví.
Haré una reserva de inmediato de que hablaremos de la versión 4.2.1 certificada por FSB y FSTEC para hoy. En las versiones actuales 4.3.x, han aparecido muchas cosas interesantes, por ejemplo, DGD (Dead Gateway Detection) y un mecanismo de agrupación en clúster modificado, que proporciona una conmutación casi perfecta, pero por ahora este es el futuro. No profundizaré en las profundidades de los comandos y archivos de configuración, centrándome en los comandos clave y las variables, y se puede encontrar una descripción detallada de estas "claves" en la documentación.
Primero, averigüemos cómo funciona todo. Entonces, un coordinador de ViPNet realiza varias funciones. En primer lugar, es una puerta de enlace criptográfica (CG) que le permite implementar tanto la VPN de sitio a sitio como de RA. En segundo lugar, es un servidor-enrutador de sobres que contienen datos de servicio encriptados (directorios y claves) o datos de aplicaciones cliente (intercambio de archivos, correo comercial). Por cierto, es en los directorios donde se almacenan los archivos que contienen información sobre los objetos de la red ViPNet, incluidos sus nombres, identificadores, direcciones, conexiones. El coordinador también es una fuente de información de servicio para sus clientes.
Además, puede canalizar el tráfico desde las computadoras de la red donde el software ViPNet no está instalado. Por cierto, los expertos que trabajan con esta solución a menudo se refieren a los hosts abiertos no como "nodos tunelizados", sino simplemente "túneles". Esto puede resultar confuso para los ingenieros que están acostumbrados a otras soluciones VPN, donde el túnel se refiere a la conexión PtP entre la red.
Como protocolo de encriptación, ViPNet usa IPlir, también desarrollado por Infotex. Para encapsular el tráfico, se utilizan los protocolos de transporte IP / 241 (si el tráfico no sale del dominio de difusión), UDP / 55777 y TCP / 80 (si UDP no está disponible).
El concepto de construcción de conexiones seguras se basa en las llamadas "conexiones", que son de dos tipos. Los primeros (a nivel de nodo) son necesarios para construir una conexión segura entre nodos, los segundos (a nivel de usuario) son necesarios para el funcionamiento de las aplicaciones cliente. Pero hay una excepción: los nodos administradores de ViPNet requieren ambos tipos de comunicación.
¿Qué puede salir mal en este esquema? Como muestra la práctica, hay muchas peculiaridades en el trabajo y no todos los problemas se pueden resolver de forma intuitiva, sin “la ayuda de la audiencia”, pero algo debe darse por sentado.
Coordinador no disponible
“No tenemos ningún coordinador / cliente / túnel disponible. ¿Qué hacer?" - la pregunta más común que se les ocurre a los novatos al configurar ViPNet. La única acción correcta en tal situación es activar el registro de todo el tráfico en los coordinadores y mirar el registro de paquetes IP, que es la herramienta más importante para solucionar todo tipo de problemas de red. Este método ahorra en el 80% de los casos. Trabajar con el registro de paquetes IP también ayuda a comprender mejor los mecanismos de funcionamiento de los nodos de la red ViPNet.
Sobre no entregado
Pero el registro de paquetes IP es, por desgracia, inútil cuando se trata de sobres. Se entregan mediante un módulo de transporte (mftp), que tiene su propio diario y su propia cola. Por defecto, los sobres se envían al coordinador “propio” del cliente (es decir, en el que está registrado el nodo), y luego a través de los canales interservidor que se configuran entre los coordinadores (es decir, no directamente a través de un canal seguro). Esto significa que si desea enviar una carta por correo comercial, el cliente la empacará en un sobre y la enviará primero a su coordinador. Más adelante en el camino puede haber varios coordinadores más, y solo después de eso, el sobre llegará al nodo del destinatario.
De esto se derivan dos conclusiones. En primer lugar, no es necesario comprobar la comunicación entre clientes (pulsando F5 y el icono correspondiente en el menú) para entregar sobres. En segundo lugar, si aún se comprueba la conexión entre ellos, esto no garantiza la entrega, ya que el problema puede estar en uno de los canales entre servidores.
En casos no evidentes, es posible diagnosticar el paso de sobres a través de canales entre servidores o entre un cliente y un coordinador utilizando el diario y la cola de sobres, así como los registros del coordinador. Además, el módulo de transporte del cliente ViPNet se puede configurar para la entrega directa de sobres, la entrega a través de una carpeta compartida o SMTP / POP3 (pero esta es una opción completamente exótica). No nos sumergiremos en estos ajustes.
Consecuencias del parpadeo
Puede resultar problemático actualizar a la versión actual de piezas de hardware antiguas que se han utilizado durante mucho tiempo, por ejemplo, como piezas de repuesto. En el proceso, puede aparecer un error de "hardware no compatible", que indica que tiene una plataforma de hardware realmente no compatible de la línea G1 obsoleta (estos son HW100 E1 / E2 y HW1000 Q1), o problemas en la configuración del BIOS o información incorrecta incorporada en DMI. Ya sea para gestionar DMI por su cuenta, cada uno decide por sí mismo, ya que existe el riesgo de convertir el equipo en un "ladrillo" inútil. Con BIOS, es un poco más fácil: la configuración incorrecta del sistema está en HT (Hyper Threading) desactivado o ACHI (Interfaz de controlador de host avanzado) desactivado para HDD. Para no adivinar cuál es exactamente el problema, puede consultar la unidad flash USB desde la que se está produciendo el firmware.Los archivos con información de diagnóstico se crean en él, en particular, todas las plataformas compatibles se enumeran en el archivo verbose.txt con el resultado de verificar con el suyo. Por ejemplo, el error cpu :: Vendor (# 3) == 'GenuineIntel' 24 veces => [Fallido] probablemente indica que HT está deshabilitado. Por cierto, flashear a menudo se confunde con actualización, pero estos son procesos diferentes. Durante la actualización, se guardan todas las configuraciones y los parámetros descritos anteriormente no se verifican. Y cuando vuelve a flashear, vuelve a la configuración de fábrica.Durante la actualización, se guardan todas las configuraciones y los parámetros descritos anteriormente no se verifican. Y cuando vuelve a flashear, vuelve a la configuración de fábrica.Durante la actualización, se guardan todas las configuraciones y los parámetros descritos anteriormente no se verifican. Y cuando vuelve a flashear, vuelve a la configuración de fábrica.
Configuraciones no informativas
El archivo de configuración principal para HW es "iplir.conf", pero no siempre refleja la configuración actual. El hecho es que en el momento en que se carga el controlador IPlir, esta configuración se interpreta de acuerdo con la lógica establecida, y no toda la información se puede cargar en el controlador (por ejemplo, si hay conflictos de direcciones IP). Los ingenieros que han trabajado con el coordinador de software de Linux probablemente conocen el comando "iplirdiag", que muestra la configuración actual del nodo cargada en el controlador. En HW, este comando también está presente en el modo "escape de administrador".
Las conclusiones más populares son:
iplirdiag -s ipsettings --node-info <id de nodo> ## muestra información sobre el nodo
iplirdiag -s ipsettings --v-tun-table ## muestra todos los túneles cargados en el controlador
Detengámonos un poco en el modo de "escape de administrador". De hecho, esta es una salida del shell ViPNet a bash. Aquí estoy de acuerdo con el proveedor, que recomienda usar este modo solo para diagnósticos y realizar modificaciones solo bajo la supervisión del soporte técnico del proveedor. Esta no es su Debian habitual, aquí cualquier movimiento descuidado puede desactivar el sistema operativo, cuyos mecanismos de protección percibirán su "iniciativa" como una amenaza potencial. Junto con el BIOS bloqueado de forma predeterminada, esto lo condena a reparaciones sin garantía (léase "costosas").
(Des) división de túneles
Otro dato que no todo el mundo sabe: por defecto, el cliente ViPNet funciona en modo de túnel dividido (cuando puede especificar qué tráfico envolver en el túnel y cuál no). ViPNet tiene una tecnología de "Internet abierta" (luego renombrada como "Puerta de enlace segura a Internet"). Mucha gente atribuye erróneamente esta funcionalidad al coordinador más que al cliente. En un cliente que está registrado con un coordinador con esta función, se crean dos conjuntos de filtros preestablecidos. El primero permite la interacción solo con el propio coordinador y sus túneles, el segundo, con otros objetos, pero niega el acceso al coordinador de OI y sus túneles. Además, de acuerdo con el concepto del proveedor, en el primer caso, el coordinador debe tunelizar el servidor proxy o ser el propio servidor proxy. El tráfico del servicio, así como la recepción y transmisión de sobres (tanto de servicio,y aplicaciones) funcionan en cualquier configuración.
TCP-
Una vez me encontré con una aplicación que no quería funcionar de ninguna manera a través del coordinador. Así supe que el coordinador tiene puertos de servicio a través de los cuales se bloquea el tráfico sin cifrar sin posibilidad de configuración alguna. Estos incluyen UDP / 2046,2048,2050 (servicios básicos de ViPNet), TCP / 2047,5100,10092 (para ViPNet Statewatcher) y TCP / 5000-5003 (MFTP). Aquí resumí las funciones del túnel TCP. No es ningún secreto que a los ISP les encanta filtrar puertos UDP altos, por lo que los administradores, en un esfuerzo por mejorar la disponibilidad de sus CN, habilitan la función de túnel TCP. En este caso, los recursos en la DMZ (a través del puerto del túnel TCP) dejan de estar disponibles. Esto se debe al hecho de que el puerto del túnel TCP también se convierte en un puerto de servicio y ya no tiene reglas de firewall ni reglas NAT (traducción de direcciones de red). Es difícil diagnosticar el hecho de queque este tráfico no se registra en el registro de paquetes IP como si no estuviera allí.
Reemplazo del coordinador
Tarde o temprano se plantea la cuestión de sustituir al coordinador por una opción más productiva o temporal. Por ejemplo, reemplazando HW1000 con HW2000 o coordinador de software con PAK y viceversa. La dificultad radica en el hecho de que cada actuación tiene su propio "rol" en el NCC (Network Control Center). ¿Cómo cambiar correctamente el rol sin perder cohesión? Primero, en el NCC cambiamos el rol a uno nuevo, directorios de formularios, pero no los enviamos (!). Luego publicamos un nuevo archivo DST en el UKC e inicializamos el nuevo Coordinador. Después de eso, hacemos un reemplazo y, después de asegurarnos de que todas las interacciones son funcionales, enviamos los libros de referencia.
Clúster y caída del nodo
Una reserva caliente es imprescindible para cualquier sitio grande, por lo que siempre se les ha comprado un grupo de modelos más antiguos (HW1000, HW2000, HW5000). Sin embargo, la creación de un clúster a partir de puertas de enlace de cifrado más compactas (HW50 y HW100) fue imposible debido a la política de licencias del proveedor. Como resultado, los propietarios de sitios pequeños tuvieron que pagar de más y comprar HW1000 (bueno, o sin tolerancia a fallas). Este año, el proveedor finalmente hizo licencias adicionales para los modelos de coordinador junior. Entonces, con el lanzamiento de las versiones 4.2.x, fue posible recopilarlas en un clúster.
Al configurar un clúster por primera vez, puede ahorrar mucho tiempo al no configurar las interfaces en modo asistente o al usar comandos CLI. Puede ingresar inmediatamente las direcciones necesarias en el archivo de configuración del clúster (edición de configuración de conmutación por error), pero no olvide especificar las máscaras. Cuando el demonio de conmutación por error se inicia en modo de clúster, asignará direcciones a las interfaces correspondientes por sí mismo. Al mismo tiempo, muchos temen detener el demonio, asumiendo que las direcciones se cambian a direcciones pasivas o monomodo. No se preocupe: las interfaces conservarán las direcciones que tenían cuando se detuvo el demonio.
En la versión de clúster, hay dos problemas comunes: el reinicio cíclico del nodo pasivo y su falla al cambiar al modo activo. Para comprender la esencia de estos fenómenos, comprendamos el mecanismo de operación del clúster. Entonces, el nodo activo cuenta los paquetes en la interfaz y, si no hay paquetes en el tiempo asignado, envía un ping a testip. Si el ping pasa, entonces se reinicia el contador, si no pasa, entonces se registra la falla de la interfaz y el nodo activo se reinicia. Al mismo tiempo, el nodo pasivo envía solicitudes ARP regulares en todas las interfaces descritas en failover.ini (el archivo de configuración del clúster, que contiene las direcciones que reciben los nodos activos y pasivos). Si el registro ARP de al menos una dirección desaparece, el nodo pasivo cambia al modo activo.
Volvamos a los problemas de los conglomerados. Comenzaré con uno simple: no cambiar al modo activo. Si no hay un nodo activo, pero su dirección mac todavía está presente en la pasiva en la tabla ARP (inet show mac-address-table), debe dirigirse a los administradores del conmutador (o la caché ARP está configurada de esta manera, o hay algún tipo de falla ). La recarga cíclica del nodo pasivo es un poco más complicada. Esto sucede debido al hecho de que el pasivo no ve el registro ARP activo, entra en modo activo y (¡atención!) Sondea al vecino a través del enlace HB. Pero nuestro vecino está en modo activo y tiene más tiempo de actividad. En este momento, el nodo pasivo se da cuenta de que algo anda mal, ya que ha surgido un conflicto de estado, y se reinicia. Esto continúa indefinidamente. Si ocurre este problema, debe verificar la configuración de la dirección IP en failover.ini y la conmutación.Si todas las configuraciones del coordinador son correctas, entonces es el momento de conectar a los ingenieros de red con la pregunta.
Cruce de direcciones
En nuestra práctica, a menudo encontramos la intersección de direcciones tunelizadas detrás de diferentes coordinadores.
Es para estos casos que hay virtualización de direcciones en los productos ViPNet. La virtualización es un tipo de NAT sin monitorear el estado de una conexión uno a uno o rango a rango. Por defecto, esta función está desactivada en los coordinadores, aunque puede encontrar direcciones virtuales potenciales en iplir.conf en la línea "túnel" después de "a" en las secciones de coordinadores vecinos. Para habilitar la virtualización globalmente para toda la lista, en la sección [visibilidad], cambie el parámetro "tunneldefault" a "virtual". Si desea habilitar para un vecino específico, entonces debe agregar el parámetro "tunnelvisibility = virtual" a su sección [id]. También vale la pena asegurarse de que el parámetro tunnel_local_networks esté establecido en "on". Para editar direcciones virtuales, el parámetro tunnel_virt_assignment debe establecerse en modo "manual".En el lado opuesto, debe realizar acciones similares. Los parámetros "usetunnel" y "exclude_from_tunnels" también son responsables de la configuración del túnel. El resultado del trabajo realizado se puede verificar usando la utilidad "iplirdiag", que mencioné anteriormente.
Por supuesto, las direcciones virtuales traen algunos inconvenientes, por lo que los administradores de infraestructura prefieren minimizar su uso. Por ejemplo, cuando las organizaciones se conectan a los sistemas de información (SI) de algunas agencias gubernamentales, estas organizaciones reciben un archivo DST con un rango fijo de túneles del plan de direcciones de IS. Como podemos ver, los deseos de la persona que conecta no se tienen en cuenta. Cómo encajar en este grupo, todos deciden por sí mismos. Alguien migra estaciones de trabajo a una nueva dirección y alguien usa SNAT en el camino desde los hosts hasta el coordinador. No es ningún secreto que algunos administradores usan SNAT para eludir las restricciones de licencia de plataformas inferiores. No nos comprometemos a evaluar la ética de tal "truco de vida", pero no olvidemos que el rendimiento de las propias plataformas todavía tiene un límite,y cuando se sobrecarga, la calidad del canal de comunicación comenzará a degradarse.
Incapacidad para trabajar GRE
Por supuesto, cada solución de TI tiene sus propias limitaciones en los casos de uso admitidos, y ViPNet Coordinator no es una excepción. Un problema bastante molesto es la imposibilidad de trabajar con GRE (y los protocolos que lo usan) desde múltiples fuentes a un solo destino a través de SNAT. Tomemos, por ejemplo, un sistema banco-cliente que configura un túnel PPTP a la dirección pública del banco. El problema es que el protocolo GRE no usa puertos, por lo que después de que el tráfico pasa por NAT, el par de conectores de dicho tráfico se vuelve el mismo (tenemos la misma dirección de destino, el protocolo es el mismo y simplemente traducimos la dirección de origen a una dirección). El coordinador reacciona bloqueando el tráfico en el fondo del error 104 - La conexión ya existe. Se parece a esto:
Por lo tanto, si está utilizando múltiples conexiones GRE, debe evitar aplicar NAT a esas conexiones. Como último recurso, realice una transmisión 1: 1 (aunque esta es una solución poco práctica cuando se utilizan direcciones públicas).
No te olvides del tiempo
Continuamos con el tema del bloqueo con el evento número 4: tiempo de espera de paquetes IP. Aquí todo es banal: este evento ocurre cuando hay una discrepancia entre el tiempo absoluto (excluyendo las zonas horarias) entre los nodos de la red ViPNet (coordinadores y clientes ViPNet). En los coordinadores de HW, la diferencia máxima es de 7200 segundos y se establece en el parámetro "timediff" del archivo de configuración de IPlir. No considero a los coordinadores HW-KB en este artículo, pero vale la pena señalar que en la versión KB2 el timediff es de 7 segundos por defecto, y en KB4 es de 50 segundos, y el evento puede generarse no 4, sino 112, lo que puede ser confuso. un ingeniero acostumbrado a HW "normal".
Tráfico no cifrado en lugar de cifrado
Puede resultar difícil para los principiantes comprender la naturaleza del evento 22 - Paquete IP no cifrado del nodo de red - en el registro de paquetes IP. Significa que el coordinador esperaba tráfico encriptado de esta dirección IP, pero llegó tráfico no encriptado. La mayoría de las veces sucede así:
- ViPNet-, , . IPlir , , , . , : ViPNet-, – . , , , . , , , ViPNet-, . , ViPNet-, ;
- . , , ( ). , , , ;
- . , . , «» . , , , 22 .
(ALG)
Muchos firewalls, incluido ViPNet Coordinator, pueden tener problemas con el paso de SIP a través de NAT. Dado que las direcciones virtuales son NAT interna, el problema puede ocurrir incluso cuando no se usa explícitamente NAT y solo se usan direcciones virtuales. El coordinador tiene un módulo de procesamiento de protocolo de aplicación (ALG) que debería resolver estos problemas, pero no siempre funciona como se desea. No me detendré en el mecanismo del ALG (se puede escribir un artículo separado sobre este tema), el principio es el mismo para todas las UIT, solo cambian los encabezados del nivel de aplicación. Para el correcto funcionamiento del protocolo SIP a través del coordinador, es necesario conocer lo siguiente:
- ALG debe estar habilitado cuando se usa NAT;
- cuando se utiliza direccionamiento virtual, ALG debe estar habilitado en ambos nodos que participan en la interacción (coordinador-coordinador, coordinador-cliente), incluso si la visibilidad virtual está configurada en un solo lado;
- cuando se usa visibilidad real y no hay NAT, debe apagar ALG para que no interfiera con SIP;
- Las líneas ALG 3.xy 4.x son incompatibles (estrictamente hablando, en la línea 3.x no había forma de controlarlo). En tal escenario, el proveedor no puede garantizar el correcto funcionamiento de SIP.
El módulo es controlado por los comandos del grupo "alg module" desde el modo privilegiado (habilitar).
Finalmente
Traté de considerar los problemas más urgentes, identificar sus raíces y hablar de soluciones. Por supuesto, estas no son todas las características de ViPNet, por lo que recomiendo no ser tímido: ponerse en contacto con el soporte y pedir consejo en la comunidad (en el foro del proveedor, en el canal de telegramas, en los comentarios de esta publicación). Y si no quiere sumergirse en todas las dificultades de trabajar con ViPNet o es demasiado laborioso, entonces siempre puede dejar la administración de su red ViPNet en manos de profesionales.
Autor: Igor Vinokhodov, ingeniero de la segunda línea de administración, Rostelecom-Solar