Meu projeto não realizado. Rede de 200 roteadores MikroTik

Olá pessoal. Este artigo é destinado a quem possui muitos dispositivos Mikrotik no parque e deseja fazer a unificação máxima para não se conectar a cada dispositivo individualmente. Neste artigo, descreverei um projeto que, infelizmente, não alcançou condições de combate devido a fatores humanos. Em resumo: mais de 200 roteadores, configuração rápida e treinamento da equipe, unificação por região, redes de filtragem e hosts específicos, a capacidade de adicionar regras facilmente a todos os dispositivos, registro e controle de acesso.

O que está descrito abaixo não afirma ser um caso final, mas espero que seja útil para você ao planejar suas redes e minimizar erros. Talvez alguns pontos e decisões não lhe pareçam corretos - se assim for, escreva nos comentários. As críticas neste caso serão uma experiência em um cofrinho comum. Portanto, o leitor, observe os comentários, talvez o autor tenha cometido um erro grave - a comunidade ajudará.

O número de roteadores é de 200 a 300, espalhados em diferentes cidades com qualidade de conexão à Internet. É necessário fazer tudo de maneira bonita e rápida para explicar aos administradores locais como tudo funcionará.

Então, onde começa qualquer projeto. Claro, com TK .

1. Organização de um plano de rede para todas as filiais de acordo com os requisitos do cliente, segmentação de rede (de 3 a 20 redes em filiais, dependendo do número de dispositivos).
2. Configure dispositivos em cada filial. Verificando a largura de banda real do provedor em diferentes condições de trabalho.
3. Organização da proteção do dispositivo, gerenciamento da lista branca, detecção automática de ataques com lista negra automática por um certo período de tempo, minimização do uso de vários meios técnicos utilizados para interceptar o acesso de controle e recusar o serviço.
4. Organização de conexões VPN seguras com filtragem de rede de acordo com os requisitos do cliente. Pelo menos 3 conexões VPN de cada filial ao centro.
5. Com base no parágrafo 1, 2. Escolha as maneiras ideais de criar vpn tolerante a falhas. A tecnologia de roteamento dinâmico, se justificada corretamente, pode ser selecionada pelo contratado.
6. Organização da priorização de tráfego por protocolos, portas, hosts e outros serviços específicos que o cliente utiliza. (VOIP, hosts com serviços importantes)
7. Organização de monitoramento e registro de eventos do roteador para resposta da equipe de suporte técnico.

Como entendemos, em vários casos, o TK é compilado a partir de requisitos. Eu mesmo formulei esses requisitos, depois de ouvir os principais problemas. Eu admiti a possibilidade de que outra pessoa pudesse assumir a implementação desses pontos.

Quais ferramentas serão usadas para atender a esses requisitos:

1. Pilha ELK (depois de algum tempo, entendeu-se que o fluentd será usado em vez do logstash).
2. Ansible. Para facilitar a administração e o compartilhamento do acesso, usaremos o AWX.
3. GITLAB. Não há necessidade de explicar. Onde sem controle de versão de nossas configurações.
4. PowerShell Haverá um script simples para a geração inicial da configuração.
5. Wiki Doku para escrever documentação e manuais. Nesse caso, use habr.com.
6. O monitoramento será feito através do zabbix. Um diagrama de conexão será desenhado lá para entendimento geral.

Momentos das configurações do EFK

No primeiro parágrafo, descreverei apenas a ideologia pela qual os índices serão construídos. Existem muitos
excelentes artigos sobre como configurar e receber logs de dispositivos executando o mikrotik.

Vou me debruçar sobre alguns pontos:

1. De acordo com o esquema, vale a pena considerar o recebimento de logs de diferentes locais e em diferentes portos. Para isso, usaremos um agregador de logs. E também queremos fazer agendamentos universais para todos os roteadores com a possibilidade de compartilhar o acesso. Em seguida, construímos os índices da seguinte maneira:


Assim, podemos combinar roteadores e segmentos de acordo com o plano- mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Por que complicar isso? Entendemos que teremos 200 ou mais dispositivos. Não acompanhe tudo. Desde a versão 6.8 do elasticsearch, temos acesso às configurações de segurança (sem a compra de uma licença), para que possamos distribuir os direitos de visualização entre os funcionários do suporte técnico ou os administradores locais do sistema.
Tabelas, gráficos - aqui você só precisa concordar - ou usa o mesmo, ou cada um faz o que lhe convém.

2. Registrando. Se ativarmos o logon nas regras do firewall, faremos os nomes sem espaços. Pode-se observar que, usando uma configuração simples no fluentd, podemos filtrar os dados e criar painéis convenientes. Na imagem abaixo, meu roteador doméstico.



3. De acordo com o local ocupado e os registros. Em média, com 1.000 mensagens por hora, os logs ocupam de 2 a 3 MB por dia, o que, como você vê, não é muito. Elasticsearch versão 7.5.

ANSIBLE.AWX

Felizmente para nós, temos um módulo pronto para roteadores
Eu apontei o AWX, mas os comandos abaixo são apenas sobre o ansible em sua forma mais pura - acho que para aqueles que trabalharam com o ansible não haverá problemas ao usar o gui awx.

Eu admito, honestamente, antes disso, olhei para outros guias onde eles usavam ssh, e todos tinham problemas diferentes com o tempo de resposta e vários outros problemas. Repito, ele não chegou à batalha ", tome essas informações como um experimento que não foi além do suporte de 20 roteadores.

Precisamos usar um certificado ou contabilidade. Cabe a você, eu sou de certificados. Algum ponto sutil sobre direitos. Eu concedo permissões de gravação - pelo menos "redefinir configuração" não pode ser feito.

Não deve haver problemas com a geração, cópia do certificado e importação:



Como você pode ver na configuração acima, compilar seu playbook é fácil. É bom o suficiente para dominar o cli mikrotik. Imagine uma situação em que em todos os roteadores você precise remover a lista de endereços com determinados dados e:


Eu intencionalmente não inseri a lista inteira do firewall aqui. Será individual para cada projeto. Mas uma coisa é certa, use apenas a lista de endereços.

Pelo GITLAB, tudo está claro. Não vou me debruçar sobre esse momento. Tudo é bonito para tarefas separadas, modelos, manipuladores.

Powershell

Haverá 3 arquivos. Por que powershell? Uma ferramenta para gerar configurações pode ser escolhida por qualquer pessoa que esteja mais confortável. Nesse caso, todos têm janelas no PC, então por que fazê-lo no bash quando o powershell é mais conveniente. Para quem é mais conveniente.



Por favor, perdoe-me, não posso definir todas as regras porque não será muito bonito. Você mesmo pode fazer as regras, guiadas pelas melhores práticas.



Alterei intencionalmente os endereços nos exemplos por razões óbvias.

Eu pulei a questão de detectar ataques e comportamento anormal - isso merece um artigo separado. Mas vale ressaltar que nesta categoria você pode usar os valores dos dados de monitoramento com o Zabbix + calculou os dados de ondulação com a elasticsearch.

Em que pontos você precisa se concentrar:

1. Plano de rede. É melhor compor imediatamente de forma legível. Já chega. Infelizmente, muitas vezes vejo que as redes são compiladas de acordo com o princípio: "Um novo ramo apareceu, aqui está você / 24". Ninguém descobre quantos dispositivos devem estar em um determinado local e se haverá mais crescimento. Por exemplo, uma pequena loja aberta, na qual fica claro que o dispositivo não terá mais que 10, por que alocar / 24? Em filiais grandes - pelo contrário, elas alocam / 24 e existem 500 dispositivos - você pode simplesmente adicionar uma rede, mas deseja pensar em tudo imediatamente.
2. Regras de filtragem. Se o projeto assumir que haverá uma separação de redes e uma segmentação máxima. As melhores práticas mudam com o tempo. Antes, eles compartilhavam uma rede de PCs e uma rede de impressoras, agora é bastante normal não compartilhar essas redes. Vale a pena usar o bom senso e não criar muitas sub-redes onde elas não são necessárias e não conectar todos os dispositivos em uma rede.
3. Configurações "douradas" em todos os roteadores. I.e. se você tiver decidido um plano. Vale a pena prever tudo imediatamente e tentar garantir que todas as configurações sejam idênticas - há apenas uma lista de endereços e endereços IP diferentes. Em caso de problemas, o tempo de depuração será menor.
4. Questões organizacionais não são menos importantes que questões técnicas. Freqüentemente, funcionários preguiçosos seguem essas recomendações "manualmente", sem usar configurações e scripts prontos, o que acaba gerando problemas do zero.

Por roteamento dinâmico. OSPF usado com divisão zonal. Mas este é um banco de testes. Em condições de combate, é mais interessante montar essas coisas.

Espero que ninguém tenha ficado chateado por não ter postado a configuração dos roteadores. Eu acho que haverá links suficientes e tudo depende dos requisitos. E, claro, testes, mais testes são necessários.

Desejo a todos que implementem seus projetos no novo ano. Sim, o acesso concedido virá com você !!!