O meu proxecto sen realizar. Rede de 200 enrutadores MikroTik

O meu proxecto sen realizar. Rede de 200 enrutadores MikroTik

Ola a todos. Este artigo está pensado para aqueles que teñen moitos dispositivos Mikrotik na súa flota e queren facer a máxima unificación para non conectarse a cada dispositivo por separado. Neste artigo vou describir un proxecto que, por desgraza, non chegou a condicións de combate por factores humanos. En resumo: máis de 200 enrutadores, configuración rápida e formación do persoal, unificación por rexións, redes de filtrado e hosts específicos, capacidade de engadir regras facilmente a todos os dispositivos, rexistro e control de acceso.

O que se describe a continuación non pretende ser un caso preparado, pero espero que che sexa útil á hora de planificar as túas redes e minimizar os erros. Quizais algúns puntos e solucións non che parezan totalmente correctos; se é así, escribe nos comentarios. A crítica neste caso será unha experiencia para a facenda común. Polo tanto, lector, bótalle un ollo aos comentarios, quizais o autor cometeu un grave erro: a comunidade axudaralle.

O número de enrutadores é de 200 a 300, repartidos por diferentes cidades con diferentes calidades de conexións a Internet. É necesario facelo todo ben e explicar claramente aos administradores locais como funcionará todo.

Entón, onde comeza algún proxecto? Por suposto, con TK.

  1. Organización dun plan de rede para todas as sucursais segundo as necesidades do cliente, segmentación da rede (de 3 a 20 redes en sucursais segundo o número de dispositivos).
  2. Configurar dispositivos en cada rama. Comprobación da velocidade de rendemento real do provedor en diferentes condicións de funcionamento.
  3. Organización da protección do dispositivo, xestión da lista branca, detección automática de ataques con lista negra automática durante un determinado período de tempo, minimizando o uso de diversos medios técnicos utilizados para interceptar o control de acceso e denegar o servizo.
  4. Organización de conexións VPN seguras con filtrado de rede segundo as necesidades do cliente. Mínimo 3 conexións VPN desde cada sucursal ata o centro.
  5. En función dos puntos 1, 2. Seleccione as formas óptimas de crear VPN tolerantes a fallos. Se se xustifica correctamente, a tecnoloxía de enrutamento dinámico pode ser elixida polo contratista.
  6. Organización da priorización do tráfico por protocolos, portos, hosts e outros servizos específicos utilizados polo cliente. (VOIP, hosts con servizos importantes)
  7. Organización do seguimento e rexistro de eventos do router para a resposta do persoal de soporte técnico.

Segundo entendemos, nalgúns casos as especificacións técnicas elabóranse en función dos requisitos. Formulei eu mesmo estes requisitos, despois de escoitar os principais problemas. Admitiu a posibilidade de que alguén se ocupase destes puntos.

Que ferramentas se empregarán para cumprir estes requisitos:

  1. pila ELK (despois dun tempo, quedou claro que se usaría fluentd en lugar de logstash).
  2. Ansible. Para facilitar a administración e o acceso compartido, utilizaremos AWX.
  3. GITLAB. Non hai que explicar aquí. Onde estaríamos sen o control de versións das nosas configuracións?
  4. PowerShell. Haberá un script sinxelo para a xeración inicial da configuración.
  5. Doku wiki, para escribir documentación e guías. Neste caso, usamos habr.com.
  6. O seguimento realizarase a través de zabbix. Tamén se debuxará alí un diagrama de conexión para unha comprensión xeral.

Puntos de configuración EFK

Respecto do primeiro punto, só describirei a ideoloxía pola que se construirán os índices. Hai moitos
excelentes artigos sobre a configuración e a recepción de rexistros de dispositivos que executan mikrotik.

Voume deter nalgúns puntos:

1. Segundo o diagrama, paga a pena considerar a recepción de rexistros de diferentes lugares e en diferentes portos. Para iso usaremos un agregador de rexistros. Tamén queremos facer gráficos universais para todos os enrutadores coa posibilidade de compartir o acceso. Despois construímos os índices do seguinte xeito:

aquí tes unha parte da configuración con fluentd escriba elasticsearch
logstash_format verdadeiro
nome_índice mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
Exércitos busca elástica: 9200
porto 9200

Deste xeito, podemos combinar enrutadores e segmentos segundo o plan: mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Por que facelo tan complicado? Entendemos que teremos 200 ou máis dispositivos. Non podes facer un seguimento de todo. Coa versión 6.8 de elasticsearch, a configuración de seguranza está dispoñible para nós (sen mercar unha licenza), polo que podemos distribuír dereitos de visualización entre empregados de soporte técnico ou administradores de sistemas locais.
Táboas, gráficas -aquí só hai que poñerse de acordo- ou usan as mesmas, ou cada quen fai o que lle convén.

2. Por rexistro. Se activamos o inicio de sesión nas regras do firewall, entón facemos os nomes sen espazos. Pódese ver que usando unha configuración sinxela en fluentd, podemos filtrar datos e facer paneis cómodos. A imaxe de abaixo é o meu enrutador doméstico.

O meu proxecto sen realizar. Rede de 200 enrutadores MikroTik

3. Por espazo ocupado e rexistros. De media, con 1000 mensaxes por hora, os rexistros ocupan entre 2 e 3 MB por día, o que, xa ves, non é tanto. Elasticsearch versión 7.5.

ANSIBLE.AWX

Afortunadamente para nós, temos un módulo preparado para routeros
Mencionei sobre AWX, pero os comandos a continuación só tratan de ansible na súa forma pura; creo que para aqueles que traballaron con ansible, non haberá problemas para usar awx a través da interface gráfica.

Para ser honesto, antes disto mirei outras guías onde usaban ssh, e todas tiñan problemas diferentes co tempo de resposta e unha morea de outros problemas. Repito, non chegou a pelexa , tómase esta información como un experimento que non chegou máis lonxe que un soporte de 20 routers.

Necesitamos usar un certificado ou unha conta. Ti toca decidir, eu estou polos certificados. Algún punto sutil sobre os dereitos. Dou dereitos de escritura - polo menos "reset config" non funcionará.

Non debería haber problemas para xerar, copiar e importar o certificado:

Breve lista de comandosNo teu PC
ssh-keygen -t RSA, responde preguntas, garda a chave.
Copiar en mikrotik:
usuario ssh-keys importar public-key-file=id_mtx.pub usuario=ansible
Primeiro cómpre crear unha conta e asignarlle dereitos.
Comprobando a conexión mediante o certificado
ssh -p 49475 -i /keys/mtx [protexido por correo electrónico]

Rexistrarse en /etc/ansible/hosts
MT01 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible

Ben, un exemplo de manualidades: - nome: add_work_sites
anfitrións: testmt
serie: 1
conexión: network_cli
usuario_remoto: mikrotik.west
gather_facts: si
tarefas:
- nome: engadir Work_sites
routeros_command:
comandos:
— /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip firewall address-list add address=habr.com list=work_sites comment=for_habr

Como podes ver na configuración anterior, crear os teus propios playbooks non é difícil. É suficiente dominar ben cli mikrotik. Imaxinemos unha situación na que necesites eliminar a lista de enderezos con certos datos en todos os enrutadores, entón:

Buscar e eliminarEliminar a lista de enderezos do firewall /ip [busca onde list="gov.ru"]

Non incluín aquí a lista completa do firewall porque... será individual para cada proxecto. Pero unha cousa que podo dicir con certeza, use só a lista de enderezos.

Segundo GITLAB todo está claro. Non vou determe neste punto. Todo é fermoso para tarefas individuais, modelos, controladores.

PowerShell

Aquí haberá 3 ficheiros. Por que powershell? Podes escoller calquera ferramenta para xerar configuracións, a que sexa máis conveniente para ti. Neste caso, todos teñen Windows no seu PC, entón por que facelo en bash cando Powershell é máis conveniente. Cal é máis conveniente?

O guión en si (simple e comprensible):[cmdletBinding()] Param(
[Parámetro(obrigatorio=$true)] [cadea]$EXTERNALIPADDRESS,
[Parámetro(obrigatorio=$true)] [cadea]$EXTERNALIPROUTE,
[Parámetro(obrigatorio=$true)] [cadea]$BWorknets,
[Parámetro(obrigatorio=$true)] [cadea]$CWorknets,
[Parámetro(obrigatorio=$true)] [cadea]$BVoipNets,
[Parámetro(obrigatorio=$true)] [cadea]$CVoipNets,
[Parámetro(obrigatorio=$true)] [cadea]$CClients,
[Parámetro(obrigatorio=$true)] [cadea]$BVPNWORKs,
[Parámetro(obrigatorio=$true)] [cadea]$CVPNWORKs,
[Parámetro(obrigatorio=$true)] [cadea]$BVPNCLIENTS,
[Parámetro(obrigatorio=$true)] [cadea]$cVPNCLIENTS,
[Parámetro(obrigatorio=$true)] [cadea]$NAMEROUTER,
[Parámetro(obrigatorio=$true)] [cadea]$ServerCertificates,
[Parámetro(obrigatorio=$true)] [cadea]$infile,
[Parámetro(obrigatorio=$true)] [cadea]$ficheiro de saída
)

Get-Content $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Replace("EXTROUTE", $EXTERNALIPROUTE)} |
Foreach-Object {$_.Replace("BWorknet", $BWorknets)} |
Foreach-Object {$_.Replace("CWorknet", $CWorknets)} |
Foreach-Object {$_.Replace("BVoipNet", $BVoipNets)} |
Foreach-Object {$_.Replace("CVoipNet", $CVoipNets)} |
Foreach-Object {$_.Replace("CClients", $CClientss)} |
Foreach-Object {$_.Replace("BVPNWORK", $BVPNWORKs)} |
Foreach-Object {$_.Replace("CVPNWORK", $CVPNWORKs)} |
Foreach-Object {$_.Replace("BVPNCLIENTS", $BVPNCLIENTSs)} |
Foreach-Object {$_.Replace("CVPNCLIENTS", $cVPNCLIENTSs)} |
Foreach-Object {$_.Replace("MYNAMERROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile

Perdoade, non podo publicar todas as regras porque... non será moi bonito. Podes crear as regras ti mesmo, guiado polas mellores prácticas.

Por exemplo, aquí tes unha lista de ligazóns que seguín:wiki.mikrotik.com/wiki/Manual:Protexendo_o_seu_enrutador
wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filtro
wiki.mikrotik.com/wiki/Manual:OSPF-exemplos
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual: Winbox
wiki.mikrotik.com/wiki/Manual:Actualizando_RouterOS
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack: aquí cómpre saber que cando se activa a vía rápida, as regras de priorización e configuración do tráfico non funcionarán, útil para dispositivos débiles.

Símbolos para variables:Tómanse como exemplo as seguintes redes:
Rede de traballo 192.168.0.0/24
Rede VOIP 172.22.4.0/24
Rede 10.0.0.0/24 para clientes sen acceso á rede local
192.168.255.0/24 Rede VPN para grandes sucursais
172.19.255.0/24 Rede VPN para pequenos

O enderezo de rede está formado por 4 números decimais, respectivamente A.B.C.D, a substitución funciona co mesmo principio, se ao inicio solicita B, significa que debes introducir o número 192.168.0.0 para a rede 24/0 e para C. = 0.
$EXTERNALIPADDRESS - enderezo dedicado do provedor.
$EXTERNALIPROUTE - ruta predeterminada á rede 0.0.0.0/0
$BWorknets - Rede de traballo, no noso exemplo haberá 168
$CWorknets - Rede de traballo, no noso exemplo será 0
$BVoipNets - Rede VOIP no noso exemplo aquí 22
$CVoipNets - Rede VOIP no noso exemplo aquí 4
$CClientss - Rede para clientes - só acceso a Internet, no noso caso aquí 0
$BVPNWORKs - Rede VPN para grandes sucursais, no noso exemplo 20
$CVPNWORKs - Rede VPN para grandes sucursais, no noso exemplo 255
$BVPNCLIENTS - Rede VPN para pequenas sucursais, o que significa 19
$CVPNCLIENTS: rede VPN para pequenas sucursais, é dicir, 255
$NAMEROUTER - nome do enrutador
$ServerCertificate: o nome do certificado que importou anteriormente
$infile — Especifique o camiño ao ficheiro desde o que imos ler a configuración, por exemplo D:config.txt (preferentemente o camiño inglés sen comiñas e espazos)
$outfile — especifique o camiño onde gardalo, por exemplo D:MT-test.txt

Modifiquei deliberadamente os enderezos dos exemplos por razóns obvias.

Perdín o punto sobre a detección de ataques e comportamentos anómalos; isto merece un artigo aparte. Pero paga a pena sinalar que nesta categoría pode usar os valores de datos de seguimento de Zabbix + datos de rizo procesados ​​de elasticsearch.

A que puntos debes prestar atención:

  1. Plan de rede. É mellor compoñelo inmediatamente nunha forma lexible. Excel será suficiente. Desafortunadamente, moitas veces vexo que as redes se constrúen segundo o principio "Apareceu unha nova rama, aquí está /24 para ti". Ninguén está a descubrir cantos dispositivos se esperan nun determinado lugar ou se haberá un maior crecemento. Por exemplo, abriuse unha pequena tenda na que inicialmente estaba claro que o dispositivo non sería máis de 10, para que asignar /24? Para as grandes sucursais, pola contra, asignan /24 e hai 500 dispositivos: simplemente podes engadir unha rede, pero queres pensar en todo á vez.
  2. Regras de filtrado. Se o proxecto supón que haberá separación de redes e máxima segmentación. As mellores prácticas cambian co paso do tempo. Antes dividíanse unha rede de PC e unha rede de impresoras, pero agora é bastante normal non dividir estas redes. Paga a pena usar o sentido común e non crear moitas subredes onde non sexan necesarias e non combinar todos os dispositivos nunha soa rede.
  3. Configuración "Golden" en todos os enrutadores. Eses. se decidiu un plan. Paga a pena prever todo de inmediato e tentar asegurarse de que todas as opcións son idénticas: só a lista de enderezos e os enderezos IP son diferentes. Se aparecen problemas, o tempo de depuración será menor.
  4. As cuestións organizativas non son menos importantes que as técnicas. Moitas veces, os empregados preguiceiros realizan estas recomendacións "manualmente", sen usar configuracións e scripts preparados, o que finalmente leva a problemas da nada.

Por enrutamento dinámico. Utilizouse OSPF con división de zonas. Pero este é un banco de probas; é máis interesante configurar tales cousas en condicións de combate.

Espero que ninguén se moleste porque non publiquei as configuracións do enrutador. Creo que as ligazóns serán suficientes, e entón todo depende dos requisitos. E, por suposto, probas, son necesarias máis probas.

Desexo que todos realicen os seus proxectos no novo ano. Que o acceso concedido estea contigo!!!

Fonte: www.habr.com

Engadir un comentario