Introdução ao Gerenciamento de Redes - parte 6 - ICMP

Muitas vezes as ferramentas mais simples são as mais úteis. Quando precisamos enviar um recado pra alguém, por exemplo, basta escrever um pequeno bilhete. Se precisarmos de uma resposta rápida, podemos usar o SMS, ou um instant messenger.

No gerenciamento de redes também temos ferramentas simples, mas bastante úteis, como o ICMP, um protocolo capaz de informar sobre a disponibilidade dos nós da rede, erros no processamento de pacotes IP ou problemas em seu envio. Esta é a sexta parte do vídeo "Introdução ao Gerenciamento de Redes" feito pelo NIC. br.

A rede da XPTO nem de longe é o caos que era antigamente. Nosso amigo Gustavo já fez muito, você sabe, e as coisas já estão mais tranquilas. Finalmente ele conseguia sair do trabalho no fim do dia na hora certa, então pôde convidar a Carla pra um encontro… O que está preocupando Gustavo é que a Carla já está muito atrasada e não atende ao telefone e nem responde suas mensagens.

Justo hoje que planejava pedi-la em namoro? ! Enquanto a ansiedade toma conta do Gustavo, ele pensa como seria útil se houvesse um protocolo como o ICMP para comunicação entre as pessoas.

Assim, com um simples traceroute ele saberia onde Carla está e teria uma ideia de quanto tempo ela ainda ia demorar. O Gustavo realmente gostava do ICMP, ou Internet Control Message Protocol, e o utilizava sempre na detecção de problemas na rede da XPTO. Ferramentas baseadas no ICMP permitiam que ele fizesse testes de conectividade, davam boas pistas de porque um host ou uma rede estavam inalcançáveis e serviam para uma série de outras tarefas.

Existem duas versões do ICMP. A versão do ICMP utilizada em redes IPv4 é mais simples que a desenvolvida para redes IPv6. No IPv6, além das funções básicas já citadas, o ICMPv6 é utilizado pra muitas outras coisas, mas esse é um assunto pra outra conversa.

Gustavo pensava agora na grande utilidade do ICMP como ferramenta de testes e diagnósticos, e isso vale tanto para o IPv6 quanto para o já antigo e talvez ultrapassado IPv4. Gustavo lembrou-se das inúmeras ocasiões em que precisou de forma rápida saber se havia conectividade entre a rede da XPTO e a de um cliente, e ter uma estimativa da qualidade dessa conexão. O ping é uma ferramenta excelente para isso!

O ping, ou ping6, no IPv6, dependendo do sistema operacional, funciona enviando mensagens ICMP do tipo echo request ao destino e de acordo com a resposta, ou falta dela, permite tirar algumas conclusões: Se uma mensagem de retorno echo reply é recebida, isso indica que há conectividade entre os dispositivos. Neste caso, pode se observar o tempo que os pacotes demoraram para ir ao destino e voltar e se todos os pacotes foram entregues corretamente, medindo a latência e a perda de pacotes na comunicação. Mas deve-se tomar cuidado para não se tirar conclusões precipitadas, pois uma grande quantidade de pacotes perdidos ou um tempo muito alto de latência, no caso do ping, nem sempre indicam problemas reais na rede.

Os roteadores no meio do caminho normalmente tratam o tráfego ICMP com uma prioridade menor do que o tráfego UDP ou TCP. Se eles estiverem sobrecarregados pode ser que descartem ou demorem para encaminhar pacotes ICMP, enquanto o restante do tráfego ainda flui normalmente… Quando não há resposta, isso pode significar que não há conectividade. Mas pode também significar que a rede do outro lado, ou alguma outra no meio do caminho, está filtrando ou não está tratando pacotes ICMP.

Ou seja, quando não há resposta, o ping sozinho realmente não diz muita coisa. Gustavo normalmente busca um diagnóstico um pouco mais completo, usando também o traceroute. O comando pode ser também tracert, dependendo do sistema operacional utilizado.

No caso do IPv6, traceroute6 ou tracert6. Com ele, além de verificar a acessibilidade de um dispositivo, é possível determinar qual caminho o pacote está percorrendo para alcançá-lo, permitindo que se detecte problemas no roteamento de pacotes ou filtros ao longo desse caminho. Para determinar o caminho percorrido pelo pacote, o traceroute usa um truque muito interessante, que depende do Hop Limit ou TTL.

O Hop Limit, no IPv6, ou TTL, no IPv4, é um campo no pacote IP que é decrementado por cada um dos roteadores na rede. Se ele chega a zero, o roteador descarta o pacote. Se não existisse o Hop Limit e houvesse um problema de roteamento fazendo um pacote andar em círculos na rede, ele faria isso eternamente, consumindo banda e outros recursos… Na prática o Hop Limit define por quantos roteadores um pacote pode passar, antes de ir para o céu dos pacotes IP… Para determinar o caminho entre dois hosts, o traceroute envia um pacote ao destino com Hop Limit ou TTL 1.

Esse pacote pode ser UDP, usando uma porta de destino entre 33434 e 33535, ICMP ou um TCP SYN destinado para a porta 80. Como o pacote tem Hop Limit 1, ele só vai chegar até o primeiro roteador, que sem dó alguma irá descartá-lo. O fato do roteador descartar o pacote, em si, não nos serve de nada, mas ao fazer isso ele automaticamente envia uma mensagem ICMP de erro, do tipo Time Exceeded.

Isso permite ao host de origem identificar esse primeiro roteador. Em seguida é enviado um pacote com Hop Limit 2, que é decrementado pelo primeiro roteador e pelo segundo, e então descartado. É o segundo roteador nesse caso que manda a mensagem ICMP Time Exceeded, e é identificado.

O processo se repete permitindo identificar os roteadores ao longo do caminho, até um pacote com Hop Limit suficientemente grande para alcançar o destino ser enviado. Quando se utiliza UDP, que é o padrão, normalmente o destino responde com uma mensagem ICMP do tipo Destination Unreachable com o código Port Unreachable. Na análise do resultado é preciso levar em consideração que os endereços dos roteadores ao longo do caminho nem sempre são das interfaces de rede que receberam o pacote, e sim da interface pela qual a mensagem de erro foi enviada de volta a origem.

A interface pela qual o pacote seria enviado ao próximo nó também pode ter um endereço diferente. Isso pode ocorrer porque o roteamento pode ser assimétro, ou seja, os pacotes podem fazer um caminho diferente entre dois hosts, dependendo do sentido que percorrem. O traceroute também mostra tempos de resposta e as vezes perdas de pacotes, mas essas informações não são confiáveis, pelo mesmo motivo que não são no ping.

As mensagens ICMP são tratadas com baixa prioridade pelos roteadores. O uso de UDP, ICMP ou TCP SYN nos pacotes enviados pode ainda levar a resultados diferentes, dependendo por exemplo de filtros que existem pelo caminho, ou da prioridade com a qual os roteadores tratam os diferentes tipos de tráfego. Gustavo lembrou-se de uma ocasião em que um usuário importante reclamou que não acessava o famoso buscador Oráculo.

Ele primeiro tentou acessar ele mesmo a página web, e não conseguiu, usou então os comandos "ping6 buscadororaculo. com. br" e "ping buscadororaculo.

com. br", para ver se havia ao menos conectividade até o servidor, também com resultados negativos. Usou então o "traceroute6 oraculo.

com. br" e verificou que o pacote aparentemente chegava apenas até o provedor que a XPTO contratava. Isso indicava um possível problema de roteamento no provedor.

Gustavo verificou em uma lista de emails de administradores de redes na Internet, a "Caiu", mantida pelo NIC. br, que havia alguns outros clientes do mesmo provedor reclamando de problemas similares. Abriu um chamado, e em pouco tempo tudo já estava bem.

As vezes Gustavo utiliza o ping e o traceroute em conjunto com ferramentas de captura de pacotes, como tcpdump ou wireshark, que podem auxiliar na detecção dos problemas, já que permitem facilmente a visualização dos tipos exatos de mensagens que estão sendo recebidas ou enviadas. Ele também utiliza o mtr, que é uma espécie de mistura entre traceroute e ping. Na verdade ele acha o mtr melhor e mais fácil de usar do que o ping e o traceroute isolados, só acha uma pena que a ferramenta não venha instalada por padrão em diversos sistemas… Foi Gustavo quem mudou as regras de firewall da XPTO para deixar de bloquear os pacotes ICMP no IPv4, tornando possível o uso de ping e traceroute.

O antigo administrador da rede seguia uma prática bastante comum, bloqueando todas as mensagens ICMP, com a justificativa de se proteger de alguns tipos de ataques. Gustavo fez um filtro seletivo, permitindo as mensagens úteis para diagnosticar problemas na rede e limitando fluxo de alguns pacotes, como o echo reply. Configurar o firewall IPv4 desta forma é bastante recomendado.

Já no IPv6, é fundamental. No IPv6, o bloqueio do ICMPv6 simplesmente impede que a rede funcione. E quanto à Carla?

Bom, enquanto Gustavo relembrava de seus heróicos feitos com ping, traceroute e mtr, ela finalmente chegou. Ahh… E pediu desculpas, pois o trânsito estava congestionado e ela tinha esquecido o celular em casa. Agora, se você quer saber mais… Sobre redes e Internet, sobre gerenciamento de redes com os vídeos do Gustavo, ou até mesmo se quiser saber se ele e a Carla vão finalmente começar a namorar, não deixe de acompanhar nossos vídeos, assinando o canal NICbrVideos, no Youtube!