Funcionamento da busca de rede do ADOTI e como evitar problemas de DNS Reverso
Compartilhe
TweetResumo
Como funciona a busca de ativos de rede pelo ADOTI e causas e problemas que ocorrem durante a busca de ativos na rede quando existem erros de DNS reverso.
Mais Informações
Para entendermos o efeito que os problemas no DNS Reverso causam na busca de ativos de rede do ADOTI, primeiro vamos recapitular como funciona a busca de rede por faixa de IP que é o método que o ADOTI utiliza.
Ao configurar uma ou mais faixas de IP em sites do ADOTI e também a opção de busca de rede, o ADOTI utiliza os seguintes passos para distribuir a busca de rede entre os computadores responsáveis por sites remotos:
- O ADOTI monta uma lista dos computadores responsáveis por sites remotos para que cada computador faça uma varredura. Assim a busca se torna distribuída e alguns tipos de detecção que somente funcionam na mesma sub-rede da faixa de IP poderão ser feitas. O computador responsável pela raiz da hierarquia de sites é o próprio servidor do ADOTI;
- Para cada computador responsável encontrado, o ADOTI associa as faixas de IP dos sites abaixo do computador responsável;
- O servidor ADOTI conecta com cada computador responsável enviando as faixas de IP que estes devem buscar. Caso alguma conexão falhe, um evento é gerado e o próprio servidor do ADOTI irá efetuar a varredura dessas faixas de IP.
Agora vamos analisar o que acontece em um computador responsável que recebe faixas de IP para efetuar uma varredura e no servidor quando este cadastra um dispositivo encontrado na rede:
- O ADOTI inicia a busca pelo primeiro IP, incrementando de um em um até o último IP da faixa e enviando um pacote ICMP Echo Request (ping) para este IP. O ADOTI envia vários pacotes simultaneamente e espera a resposta de todos ou um timeout para efetuar a próxima rajada de pings. Esses valores podem ser configurados no registry do ADOTI (valores NetDiscover_PingsPerBurst e NetDiscover_SecondsBetweenPingBursts) caso algum dispositivo de proteção de rede esteja considerando essas rajadas para vários IPs diferentes uma possível tentativa de invasão.
- Uma fila de threads fica esperando pelos pacotes de resposta (ICMP Echo Reply) enviados pelos hosts ativos na rede. Para cada resposta recebida, é realizado uma query reversa para obter o nome do ativo que respondeu ao ping. Caso um nome não seja respondido e o endereço MAC também não tenha sido descoberto, o ativo apenas será incluído no ADOTI se a faixa de IP terminar com um * (ex. 172.21.6.1-172.21.6.50*), pois apenas um endereço IP não pode ser considerado com um identificador para um ativo, já que pode não ser um IP fixo;
- Após identificar o nome de rede do ativo, o ADOTI novamente resolve o nome para o endereço IP do ativo. Caso o endereço seja diferente do endereço que respondeu ao PING, esse ativo está com problema de DNS reverso e será marcado que possui esse erro. O servidor ADOTI irá inserir esse ativo no site cuja faixa de IP seja igual ao caractere cerquilha (#) para posterior análise pelo operador. Se esse site não existir, o servidor irá incluí-lo na sua faixa de IP correspondente;
- Após a identificação do nome do ativo, algumas heurísticas são empregadas (teste da porta TCP 445 que indica um computador executando Windows, VPRO, OID SNMP sysObjectID) para tentar identificar e classificar o dispositivo (qual sua categoria). Também serão aplicadas as regras de identificação de categoria via SNMP criadas no servidor. Também são utilizados protocolos ARP, NETBIOS e SNMP para tentar encontrar o endereço MAC do dispositivo, que também é utilizado pelo ADOTI, além do nome de rede, como identificador único de um dispositivo de rede. O ARP somente funciona na mesma rede onde está o computador responsável, pois funciona por broadcast. Essa é uma das vantagens de se configurar computadores responsáveis por sites remotos;
- Caso existam propriedades para serem coletadas via SNMP para a categoria descoberta no passo anterior, o responsável pela busca efetuará a coleta dos dados;
- Periodicamente durante a busca, o computador responsável envia os dispositivos encontrados na rede para o servidor ADOTI que os insere na base de dados. A inclusão de cada dispositivo é feita procurando antes se o ativo já existe em algum outro site e, se sim, o ativo é movido para o site correto e um evento (alerta) é gerado. O ADOTI utiliza o nome de rede e também o endereço MAC como chave de busca no banco de dados. Assim se um dispositivo foi renomeado, mas o endereço MAC foi obtido na busca e já existe na árvore, o ADOTI ao invés de cadastrar novamente esse ativo com nome diferente, ele renomeia o dispositivo existente. Caso seja a primeira vez que o dispositivo tenha sido encontrado, ele é cadastrado e um evento (alerta) é gerado;
- O servidor atualiza o status do dispositivo de acordo com as configurações definidas no item Configurações->Geral que é encontrada na árvore da console do ADOTI;
- Como a movimentação/cadastro de ativos na árvore é um processo pesado para o banco de dados, existe uma configuração na chave do registry do ADOTI (NetDiscover_LastScanResponseToConsiderAssetUptoDateMinutes) que faz com que o servidor apenas atualize o nome e a data que o ativo respondeu na rede dependendo da última vez que o ativo foi visto em minutos. Caso a busca de rede seja configurada para ser muito frequente (horas invés de dias) e a rede seja muito grande (milhares de ativos), esse valor pode ser configurado para algumas horas ou dias.
Com a visão de como funciona a busca de ativos na rede, podemos verificar que a resolução reversa de nomes (dado um endereço IP descobrir qual é o nome de rede do dispositivo) é um item muito importante para o correto funcionamento do ADOTI. Vamos imaginar o seguinte cenário supondo que existe um problema de resolução reversa de nome para esse IP e não existe um site com faixa igual a (#):
- O ADOTI pingou o IP 192.168.1.3 e obteve resposta. Após efetuar a resolução reversa de nome, foi obtido o nome PC_1234. Depois o ADOTI efetuou a resolução de nome para PC_1234 e obteve o endereço IP 192.168.1.10. Isso indica que o endereço IP 192.168.1.3 não é o IP do PC_1234. Olhando no servidor DNS, descobrimos que 192.168.1.3 é na verdade o computador PC_4321;
- Assim, quem respondeu o ping foi o PC_4321, mas o ADOTI acha que foi o PC_1234, pois o reverso indicou assim;
- O ADOTI irá cadastrar o ativo como PC_1234 na árvore, pois não há site com faixa de IP # para cadastrar esse ativo com problema;
- Suponha que você envie por exemplo o comando de desligar o ativo ou atualizar o inventário clicando com o botão direito sobre o PC_1234 na árvore. O que irá acontecer é que será feita a resolução de nomes para obter seu endereço IP que será 192.168.1.10 e o comando será enviado para este IP. Assim duas situações podem ocorrer:
a.) Existe um computador ligado com o IP 192.168.1.10 e que não é o PC_1234. Este computador que irá receber o comando. O operador acha que enviou o comando para o PC_1234, mas na verdade foi para outro computador;
b.) Não existe um computador ligado com o IP 192.168.1.10, e o servidor irá reportar que o ativo não responde ao comando. Nesse caso o operador fica confuso, pois a console diz que a última resposta a ping foi há alguns minutos atrás e o ativo não responde.
Como isso pode ocorrer? Este problema surge quando o servidor DNS e DHCP não estão corretamente configurados para apagar registros muito antigos. Nesse caso o que houve é que quando o PC_1234 existia na rede, o servidor DHCP forneceu para ele o IP 192.168.1.3 e esse IP foi cadastrado na zona reversa do DNS como sendo PC_1234.
Depois que o PC_1234 passou muito tempo desligado, o servidor DHCP liberou o lease e mais tarde passou o IP 192.168.1.3 para outro equipamento, por exemplo o PC_9876, e agora mais um registro aparece na zona reversa apontando o IP 192.168.1.3 para PC_9876.
Quando o PC_1234 entrou na rede novamente, ganhou o IP 192.168.1.10, pois seu lease havia vencido e novamente esse computador foi desligado. Desta forma, temos duas entradas na zona reversa para o IP 192.168.1.3, uma apontando para PC_1234 e outra para PC_9876. O servidor DNS envia como resposta para uma consulta reversa a entrada mais antiga, no caso PC_1234.
Para evitar esse problema, é necessário configurar para que o servidor DHCP sempre atualize o servidor DNS e também que o servidor DNS faça um “scavenge” procurando por entradas muito antigas (“aged“) e eliminando-as, num processo conhecido como “Aging and Scavenging“. Existem artigos no site da Microsoft de como proceder e também artigos de outras pessoas. Abaixo seguem alguns links interessantes:
Sobre o Artigo
Autor: Leandro Becker ID do Artigo: 628 A informação contida neste artigo aplica-se a: Busca de Rede > Instalação Palavras-chave: , Busca Automática, rede |