Mi proyecto no realizado. Red de 200 enrutadores MikroTik

Hola a todos Este artículo está dirigido a aquellos que tienen muchos dispositivos Mikrotik en el parque y que desean realizar la unificación máxima para no conectarse a cada dispositivo individualmente. En este artículo, describiré un proyecto que, desafortunadamente, no alcanzó condiciones de combate debido a factores humanos. En resumen: más de 200 enrutadores, configuración rápida y capacitación del personal, unificación por región, redes de filtrado y hosts específicos, la capacidad de agregar fácilmente reglas a todos los dispositivos, registro y control de acceso.

Lo que se describe a continuación no pretende ser un caso terminado, pero espero que le sea útil al planificar sus redes y minimizar los errores. Quizás algunos puntos y decisiones no le parezcan correctos; de ser así, escriba los comentarios. La crítica en este caso será una experiencia en una alcancía común. Por lo tanto, el lector, mire los comentarios, tal vez el autor cometió un grave error: la comunidad ayudará.

El número de enrutadores es de 200-300, dispersos en diferentes ciudades con diferente calidad de conexión a Internet. Es necesario hacer todo maravillosamente y explicar fácilmente a los administradores locales cómo funcionará todo.

Entonces, ¿dónde comienza cualquier proyecto? Por supuesto, con TK .

1. Organización de un plan de red para todas las sucursales de acuerdo con los requisitos del cliente, segmentación de red (de 3 a 20 redes en sucursales según la cantidad de dispositivos).
2. Configurar dispositivos en cada rama. Comprobación del ancho de banda real del proveedor en diferentes condiciones de trabajo.
3. Organización de la protección del dispositivo, gestión de la lista blanca, detección automática de ataques con listas negras automáticas durante un cierto período de tiempo, minimización del uso de diversos medios técnicos utilizados para interceptar el acceso de control y rechazar el servicio.
4. Organización de conexiones vpn seguras con filtrado de red según los requisitos del cliente. Al menos 3 conexiones vpn de cada rama al centro.
5. Basado en el párrafo 1, 2. Elija las formas óptimas para construir VPN tolerantes a fallas. El contratista puede seleccionar la tecnología de enrutamiento dinámico, si se justifica correctamente.
6. Organización de la priorización del tráfico por protocolos, puertos, hosts y otros servicios específicos que utiliza el cliente. (VoIP, hosts con servicios importantes)
7. Organización de monitoreo y registro de eventos del enrutador para la respuesta del personal de soporte técnico.

Como entendemos, en varios casos, TK se compila a partir de los requisitos. Formulé estos requisitos yo mismo, después de escuchar los principales problemas. Admití la posibilidad de que alguien más pueda retomar la implementación de estos puntos.

Qué herramientas se utilizarán para cumplir estos requisitos:

1. Pila ELK (después de un tiempo, se llegó a la conclusión de que se usará fluentd en lugar de logstash).
2. Ansible Para facilitar la administración y compartir el acceso, utilizaremos AWX.
3. GITLAB. No hay necesidad de explicar. Donde sin control de versiones de nuestras configuraciones.
4. PowerShell Habrá un script simple para la generación inicial de la configuración.
5. Wiki de Doku para escribir documentación y manuales. En este caso, use habr.com.
6. El monitoreo se realizará a través de zabbix. Se dibujará un diagrama de conexión para una comprensión general.

Momentos de configuración de EFK

En el primer párrafo describiré solo la ideología por la cual se construirán los índices. Hay muchos
excelentes artículos sobre cómo configurar y recibir registros de dispositivos que ejecutan mikrotik.

Me detendré en algunos puntos:

1. Según el esquema, vale la pena considerar recibir registros de diferentes lugares y en diferentes puertos. Para esto usaremos un agregador de registros. Y también queremos hacer horarios universales para todos los enrutadores con la posibilidad de compartir el acceso. Luego construimos los índices de la siguiente manera:


Por lo tanto, podemos combinar enrutadores y segmentos de acuerdo con el plan: mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. ¿Por qué complicar esto? Entendemos que tendremos 200 o más dispositivos. No hagas un seguimiento de todo. Desde la versión 6.8 de Elasticsearch, tenemos acceso a la configuración de seguridad (sin comprar una licencia), por lo que podemos distribuir los derechos de visualización entre los empleados de soporte técnico o los administradores del sistema local.
Tablas, gráficos, aquí solo tiene que estar de acuerdo, ya sea usar lo mismo o hacer lo que le convenga.

2. Al iniciar sesión. Si habilitamos el inicio de sesión en las reglas del firewall, entonces hacemos los nombres sin espacios. Se puede ver que usando una configuración simple en fluentd, podemos filtrar los datos y hacer paneles convenientes. En la imagen de abajo, mi enrutador doméstico.



3. Según el lugar ocupado y los registros. En promedio, con 1000 mensajes por hora, los registros ocupan 2-3 mb por día, lo cual, como ve, no es tanto. Elasticsearch versión 7.5.

ANSIBLE.AWX

Afortunadamente para nosotros, tenemos un módulo listo para usar para routeros
Apunté sobre AWX, pero los comandos a continuación son solo sobre ansible en su forma más pura: creo que para aquellos que han trabajado con ansible no habrá problemas al usar gui awx.

Admito honestamente, antes de eso miré otras guías donde usaban ssh, y cada uno tenía diferentes problemas con el tiempo de respuesta y muchos otros problemas. Repito, no llegó a la batalla , tome esta información como un experimento que no fue más allá de los 20 enrutadores.

Necesitamos usar un certificado o contabilidad. Depende de usted, estoy por certificados. Algún punto sutil sobre los derechos. Doy permisos de escritura: al menos no se puede hacer "restablecer configuración".

No debería haber problemas para generar, copiar el certificado e importar:



Como puede ver en la configuración anterior, compilar su libro de jugadas es muy fácil. Es lo suficientemente bueno para dominar cli mikrotik. Imagine una situación en la que en todos los enrutadores necesita eliminar la lista de direcciones con ciertos datos, luego:


Intencionalmente no inserté la lista completa del firewall aquí. Será individual para cada proyecto. Pero una cosa es segura, use solo la lista de direcciones.

Por GITLAB, todo está claro. No me detendré en este momento. Todo es hermoso para tareas separadas, plantillas, manejadores.

Powershell

Habrá 3 archivos. ¿Por qué PowerShell? Cualquiera que se sienta más cómodo puede elegir una herramienta para generar configuraciones. En este caso, todos tienen ventanas en la PC, entonces, ¿por qué hacerlo en bash cuando powershell es más conveniente? Para quien es más conveniente.



Perdóname, no puedo establecer todas las reglas porque No será del todo hermoso. Puede hacer las reglas usted mismo, guiado por las mejores prácticas.



Cambié intencionalmente las direcciones en los ejemplos por razones obvias.

Me salteé el punto de detectar ataques y comportamientos anormales; esto merece un artículo aparte. Pero vale la pena señalar que en esta categoría puede usar los valores de monitoreo de datos con Zabbix + resuelto datos de rizo con elasticsearch.

En qué puntos necesita concentrarse:

1. Plan de red. Es mejor hacerlo legible de inmediato. Suficiente es suficiente. Desafortunadamente, a menudo veo que las redes se compilan según el principio: "Ha aparecido una nueva sucursal, aquí tienes / 24". Nadie descubre cuántos dispositivos se supone que deben estar en un lugar determinado y si habrá un mayor crecimiento. Por ejemplo, una pequeña tienda abierta, en la que inicialmente está claro que el dispositivo no tendrá más de 10, ¿por qué asignar / 24? En sucursales grandes, por el contrario, asignan / 24, y hay 500 dispositivos, solo puede agregar una red, pero desea pensar todo de inmediato.
2. Reglas de filtrado. Si el proyecto supone que habrá una separación de redes y una máxima segmentación. Las mejores prácticas cambian con el tiempo. Anteriormente, compartían una red de PC y una red de impresoras, ahora es bastante normal no compartir estas redes. Vale la pena usar el sentido común y no crear muchas subredes donde no sean necesarias y no conectar todos los dispositivos en una red.
3. Configuraciones "doradas" en todos los enrutadores. Es decir si ha decidido un plan Vale la pena prever todo de inmediato e intentar asegurarse de que todas las configuraciones sean idénticas: solo hay una lista de direcciones y direcciones IP diferentes. En caso de problemas, el tiempo de depuración será menor.
4. Los problemas de organización no son menos importantes que los técnicos. A menudo, los empleados perezosos siguen estas recomendaciones "manualmente", sin utilizar configuraciones y secuencias de comandos listas para usar, lo que finalmente genera problemas desde cero.

Por enrutamiento dinámico. OSPF usado con división zonal. Pero este es un banco de pruebas, en condiciones de combate es más interesante configurar tales cosas.

Espero que nadie se haya molestado porque no publiqué la configuración de los enrutadores. Creo que habrá suficientes enlaces, y luego todo dependerá de los requisitos. Y, por supuesto, las pruebas, se necesitan más pruebas.

Deseo que todos implementen sus proyectos en el nuevo año. ¡Sí, el acceso otorgado vendrá contigo!