ToFoIn v 1. Reserva de puertas de enlace y cambio entre canales externos en FreeBSD

Anotación

En un artículo anterior, se consideró la organización de la redundancia para las puertas de enlace LAN. Como solución, se propuso un script que en ese momento solucionó el problema, pero tenía varios inconvenientes. Después de un tiempo, resultó eliminar estas deficiencias, reescribir parcialmente el código y obtener algo aceptable en la salida. Ahora podemos decir que las secuencias de comandos se prueban lo suficiente como para ser llamadas estables. Para simplificar la comprensión de todo el sistema, los puntos principales para configurar servicios secundarios (en términos del tema del artículo) se duplicarán parcialmente a continuación. La razón es simple: durante este tiempo las reglas de ipfw también fueron modificadas, dns se fue a vivir en AD en Samba4 con un bind-frontend y registros actualizados de forma segura desde isc-dhcpd usando kerberos, así como servidores dns secundarios como bind en las puertas de enlace, CARP configurada ... En general, se ha vuelto mucho más interesante, pero a continuación encontrará más información sobre qué y cómo funciona. Todo lo que se puede dar con referencias a la fuente se diseñará de tal manera que no produzca esencia. Lo que se tomó de otros lugares, pero que ya no está disponible, se dará aquí con comentarios relevantes.

Introduccion

Por lo tanto, hay dos formas de aumentar la inmunidad al ruido del canal de comunicación con el mundo exterior por parte del consumidor: copia de seguridad de la puerta de enlace y reserva del punto de conexión. En otras palabras, en el primer caso, se configura una segunda puerta de enlace, que se activará si falla la primera, en el segundo caso, se organizará un canal de Internet de respaldo en caso de problemas con el principal, y cuanto más se crucen, mejor, obviamente. Si CARP resuelve la primera tarea para FreeBSD, la segunda, después de organizar el segundo canal externo, puede, de nuevo, resolverse de varias maneras. Como mínimo, puede organizar el equilibrio del tráfico o cambiar entre canales. Debido a la gran diferencia en el ancho de banda de los canales externos, la primera opción no me convenía , por lo que el principal culpable de la publicación fue escrito: ToFoIn , un conjunto de scripts de bash que tiene como objetivo resolver problemas de diagnóstico y cambiar a un canal externo que funcione. Después del refinamiento, se puede aplicar a n puertas de enlace ym canales. La situación es débil, donde n y m son más de 2, pero los siguientes scripts deberían funcionar con valores grandes de n y m, porque Lógicamente, el límite no está establecido. En general, sospecho que usando estos scripts es posible resolver una gama bastante amplia de tareas, dependiendo del estado de la conexión, limitada, tal vez, solo por imaginación.


Aproximadamente, una topología de red de este tipo supone en la forma más simple el uso de un conjunto de scripts ToFoIn. Por supuesto, los scripts deben funcionar en el caso de un solo enrutador, pero en este caso, tendrá que cambiar el módulo Daemon fuertemente para eliminar la dependencia de la secuencia de acciones en el estado CARP, que simplemente estará ausente en el sistema. La reserva adicional de estos y otros nodos depende solo del grado de importancia de los servicios correspondientes.

Metas y objetivos

El objetivo del proyecto, como antes, es crear un paquete de software universal y fácilmente escalable enfocado en identificar problemas en conexiones externas e internas y cambiar automáticamente a conexiones viables. En términos generales, la lógica es la siguiente:

• Hay n "enrutadores" con m canales externos en cada uno. Además, todos los "enrutadores" están en una jerarquía estricta y están conectados entre sí mediante CARP en todas las interfaces necesarias.
• Un agente trabaja independientemente en cada máquina, cuya tarea se basa en el estado CARP actual de su máquina:
  
  • Si es una copia de seguridad: detecte y configure la máquina en un enrutador que actualmente es el maestro;
  • Si es maestro: verifique el estado de las conexiones en el momento actual y, si es necesario, cambie entre canales externos.

Solución

La red interna tiene CARP, que proporciona puertas de enlace de respaldo y le permite no cambiar la configuración de otros dispositivos de red en la red interna al cambiar de canal.

Dhcpd funciona en modo primario - secundario y, en general, no importa qué otras funciones juegue su máquina: la conexión entre dhcpd se produce en la red interna, que los enrutadores siempre observan.

El enlace maestro se elimina en AD, que está oculto en la red local, mientras que los servidores de enlace secundario trabajan en los enrutadores de la puerta de enlace en igualdad de condiciones.

Las reglas de ipfw difieren dependiendo de qué canal se considera el canal principal en un momento dado y son reiniciadas por el módulo Daemon cuando se cambian los roles.

Finalmente sobre los propios guiones. Ahora los archivos se encuentran en los directorios apropiados, funcionan desde su usuario y tienen un script de inicio en rc.d. Sudo resuelve las tareas que requieren acceso a la raíz. Existe un script de instalación que tiene en cuenta la posible presencia de una versión instalada, así como un archivo de configuración bastante detallado. Los módulos son los mismos con cambios menores, algunos casi no cambiaron en funcionalidad:

Daemon , como su nombre lo indica, es el proceso principal que ejecuta la prueba y cambia los módulos en un temporizador, y también monitorea CARP.
Probador : aún prueba las comunicaciones externas con el comando ping. (si se está ejecutando, considera que la máquina tiene CARP en el estado Maestro)
Juez : en función de los resultados de la prueba, determina qué canal externo funciona y si la conmutación es necesaria, realiza la conmutación (si está en funcionamiento, considera que la máquina tiene CARP en el estado Maestro).
Scout es un nuevo módulo. Se inicia cuando CARP está en estado de copia de seguridad. Es necesario determinar cuál de los enrutadores restantes es actualmente el principal.
Registrador : responsable del registro de eventos. Es necesario para que la información sobre eventos no se duplique y la revista sea más fácil de leer.
Watchdog : se ejecuta según el cronograma de crontab. Determina la "congelación" de todos los módulos y (siempre que sea posible) intenta resolver los problemas que han surgido. Es decir clavar a todos, simplemente poner.

Además de los scripts en sí, vale la pena considerar algunos archivos más importantes:

Tofoin.conf : un único archivo de configuración.
Tofoin.log : un único archivo de registro de eventos.
Result_ <número de canal interno> es el archivo de trabajo, los resultados de la prueba se agregan aquí, creados en / tmp junto a .pid y otros archivos de trabajo.

Con gusto puedo responder las preguntas sobre el funcionamiento de los módulos, explicando las soluciones en los comentarios.

Parte técnica

Equipo

En comparación con el tiempo anterior, las puertas de enlace se trasladaron a P4, recibieron 1536 Mb de RAM y tres discos duros de 40 Gb (espejo + repuesto). Las tarjetas de red siguen siendo PCI, las PSU son normales, naturalmente en presencia de un UPS.
El aumento de la capacidad está asociado con el hierro liberado y la actualización excesivamente tediosa de la fuente, pero principalmente la primera. Sistema operativo FreeBSD 11.1, FS zfs.

Configuración de componentes del sistema

Software de terceros

Un poco sobre ToFoIn

Todo el texto del proyecto junto con el script de instalación está disponible en gitlab .

Resumen

Resultó ser un conjunto de scripts totalmente funcional y confiable que se adapta bien a la tarea de cambiar al canal de trabajo en el caso de 2 enrutadores con 2 canales de comunicación externos.

Planes

Mis planes para este proyecto se relacionan, quizás, con la reescritura de bash a pure sh para eliminar el software innecesario en el servidor. Por otro lado, ahora todo funciona increíblemente y realmente no tengo ganas de interferir en este proceso, además, cambiar a sh está plagado de construcciones de lenguaje más terribles necesarias para lograr el mismo resultado.
Por lo demás, probablemente, valdría la pena considerar la mejor implementación de los módulos de prueba.

Referencias

← Artículo anterior
→ Página del proyecto ToFoIn en gitlab