Esta é a parte final do artigo, aqui está o início
Na última vez, escrevi sobre como implementei o monitoramento de dispositivos; agora falaremos sobre gerenciamento. Em discussões com 'técnicos' do lado do Cliente, frequentemente encontro uma percepção limitada das capacidades de dispositivos tão pequenos (com recursos de memória e desempenho modestos); muitos acreditam que 'o máximo que precisamos é enviar um reboot, para algo mais sério, chamaremos uma equipe'.
Mas a prática mostra que não é bem assim. Aqui está uma pequena lista de tarefas típicas frequentes:
- Diagnóstico de rede e resolução de problemas. Por trás da porta ethernet do seu roteador, geralmente reside outro dispositivo, que possui seu próprio endereço IP interno. Às vezes, é possível (ou necessário) 'pingar' esse dispositivo. Ou gerenciamento de túnel — se o roteador, operando através de um modem 3G, de repente não consegue estabelecer um túnel, mas o próprio roteador está visível.
- Manutenção do sistema. Atualização de firmware, upgrade de scripts de serviço.
- Equilibrista. Isso poderia ser chamado de 'excentricidades', mas o conceito de 'equilibrista', como cito, ‘a habilidade de um artista de circo de manter o equilíbrio em uma posição instável do corpo’ — se aplica mais. Situações como essas surgem devido à limitação de orçamento do cliente. Abaixo, cito alguns exemplos, mas como não têm relação direta com o tema da narrativa, os coloquei em notas.
Monitoramento Wi-FiO tema da moda nos últimos cinco anos, principalmente entre as redes de varejo federais. Você passeia lentamente pelos corredores da loja, enquanto seu celular, com o Wi-Fi ligado, tenta se conectar a alguma rede, enviando regularmente pacotes de Request Probe que podem ser analisados para contar quantas vezes você visita esta loja, quais rotas você faz e assim por diante. Depois, os dados são coletados, analisados, desenhos de mapas de calor são gerados e os gerentes usam essas imagens para 'arrancar' dinheiro da administração ou investidores. Mas, enquanto isso... 'não há dinheiro, mas vocês se aguentem...', e o resultado (real) já precisa ser mostrado, entra a velha canção 'Sim, sim, depois, com certeza, vamos instalar tudo o que vocês desejarem, mas agora precisamos mostrar resultados para o Cliente! A propósito, esquecemos de mencionar, o Cliente permitiu que nosso equipamento se conectasse ao seu hotspot via Wi-Fi, mas de forma generalizada, apenas como se fôssemos clientes convidados'. E assim, precisamos fazer roteadores-equilibristas — levantando várias subinterfaces Wi-Fi, uma das quais se conecta ao hotspot, e a outra monitora o ambiente circundante, carregando freneticamente os resultados do tcpdump para o próprio dispositivo, depois compacta o conteúdo do arquivo em um arquivo e, arriscando-se a 'excesso de comilança', tenta enviar o conteúdo para um servidor FTP. Não é de se admirar que o roteador-equilibrista frequentemente 'desista' e precise ser 'reanimado' remotamente.
RadiusAqui a situação pode ser descrita de maneira mais simples com a afirmação do cliente: “Queremos uma rede descentralizada de hotspots que funcionem em equipamentos cujo modelo não é conhecido antecipadamente, através de canais que ainda não sabemos quais serão. Ah, esquecemos de mencionar que queremos não só exibir anúncios para os clientes, mas também analisar tudo ao redor do local de instalação do hotspot. Não, ainda não sabemos para quê, mas vamos descobrir, não duvide, conseguimos pensar nessa ideia.”
E não devemos esquecer que, devido a uma série de circunstâncias indefinidas, a gestão deve ocorrer em condições não padrão, quando não podemos nos conectar ao roteador diretamente através de IP: porta e devemos simplesmente esperar a manifestação de atividade dele. Se abstrairmos, o diálogo entre o servidor e o roteador pode ser representado assim:
- Roteador: Olá. Eu sou o roteador tal, há tarefas para mim?
- Servidor: roteador tal, eu te registrei, então você está vivo. Aqui está a tarefa: pode me mostrar o resultado do comando ifconfig?
- Roteador: olá. eu sou o roteador tal, da última vez você pediu para mostrar o resultado do ifconfig, aqui está. há algo que eu precise fazer?
- Servidor: roteador tal, eu te registrei, então você está vivo. Não há tarefas para você.
A pergunta mais interessante é: como o roteador remoto pode enviar um certo volume de informações? Na parte anterior, eu descrevi que o roteador, devido à limitação de recursos, possui apenas um wget "reduzido", que funciona somente através de GET e nada mais, não há cliente ftp nem curl. Para ser mais preciso, precisamos de um método universal, independentemente das características da construção da imagem. Eu optei por usar wget. Na verdade, não é que eu "optei" — eu simplesmente não tinha escolha 🙂
Uma ressalva imediataMinha solução para gestão é funcional, não muito limitada e estou certo — é meio torta, mesmo que agrade a maioria dos meus clientes. Como poderia ser feito de forma adequada — escrever uma pequena utilidade que envia dados binários via POST pela porta 80. Incluir essa utilidade no firmware do roteador e já, através do bash, interagir com ela. Mas a realidade é que: a) precisa ser rápido b) talvez seja necessário fazer tudo no 'zoológico' existente de roteadores c) 'não faça mal!' — se o roteador está funcionando e cumprindo outras tarefas, tente fazer alterações que não afetem a funcionalidade existente.
Vamos à implementação. Suponha que seu cliente deseja reiniciar o roteador a partir do zabbix de forma fácil e simples, com um 'clique do mouse'. Hoje, começaremos a descrição da implementação a partir do zabbix.
No menu "Administração" -> "Scripts", adicionamos um novo script. Nomeamos de "Reboot", e como comando escrevemos "php /usr/share/zabbix/reboot.php {HOST.HOST}".
Em seguida: Menu "Monitoramento" -> "Dados Recentes" -> "Clique com o botão direito no nó de rede desejado". Assim ficará o menu após a adição do script.
Portanto, o script reboot.php deve ser colocado no diretório /usr/share/zabbix (pode ser diferente para você, eu uso o diretório raiz do zabbix).
Uma ressalva para segurançaPara facilitar a explicação no script, estou usando apenas o id do roteador, mas não uso a senha. Na versão em produção, isso não é recomendado! O motivo pelo qual fiz isso: porque é uma grande questão — onde armazenar as senhas dos roteadores? Nos próprios "dados de inventário" do Zabbix? Uma prática controversa. Uma alternativa: restringir o acesso externo ao próprio arquivo reboot.php
Arquivo reboot.php
set_charset("utf8");
// "Enviamos" o comando reboot alterando o campo task na tabela users. No campo task, pode-se enviar qualquer comando.
$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
$sql_users->bind_param('s', $user);
$sql_users->execute();
$sql_users->close();
?>É isso. A questão que permanece é "como obter o resultado da execução do comando do lado do dispositivo". Vamos analisar a tarefa com o comando ifconfig. É possível enviar um comando como este para o dispositivo:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, onde:
message=`ifconfig` — atribuímos à variável $message o resultado da saída do comando ifconfig
wget " — nosso script a.php, que registra os roteadores e recebe mensagens deles
u=user&p=password!&m=$message — as credenciais e o valor da variável de consulta m — atribui o conteúdo da variável $message
-O /tmp/out.txt — a saída para o arquivo /tmp/out.txt não é necessário neste caso, mas se não especificar esse parâmetro, o wget não funciona
Por que isso funciona de forma problemáticaPorque é uma vulnerabilidade potencial de segurança. O erro mais inofensivo que pode acontecer é que, na saída do seu comando, por exemplo, haja um símbolo "&". Portanto, é necessário filtrar tudo que é enviado dos roteadores e tudo que chega ao servidor. Sim, estou envergonhado, de verdade. Em minha defesa, posso apenas dizer — que todo o artigo é dedicado a como gerenciar roteadores com firmware não definido de antemão, com canais de comunicação não definidos de antemão.
E também uma preparação para o futuro: ainda não descobri como refletir os resultados (por exemplo, o resultado da execução de um comando) que chegam ao servidor usando os meios padrão do Zabbix.
Lembro que todo o código-fonte pode ser retirado do repositório Git, no endereço:
Fonte: habr.com
