Entenda alguns comandos para Rede

Entenda o que são ICMP, ping e traceroute

O ICMP - Internet Control Message Protocol - é um protocolo que faz parte da pilha TCP/IP, enquadrando-se na camada de rede (nível 3), a mesma camada do protocolo IP - Internet Protocol. O seu uso mais comum é feito pelos utilitários ping e traceroute. O ping evia pacotes ICMP para verificar se um determinado host está disponível na rede. O traceroute faz uso do envio de diversos pacotes UDP ou ICMP e, através de um pequeno truque, determina a rota seguida para alcançar um host.

Este artigo descreve as interações entre cliente e servidor implementadas por estes dois utilitários.

Ping

Quando queremos determinar se um determinado host está disponível na rede interna ou mesmo na Internet, frequentemente utilizamos o utilitário ping como um dos primeiros recursos de troubleshooting. O fato de um host não responder ao ping não quer dizer que ele esteja realmente fora da rede, pois este serviço pode estar desabilitado neste host por questões de segurança. O comando, provavelmente já conhecido pelo leitor, é:

ping <host>

Exemplo:

[root@malkovich linux-2.6.3]# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=127 time=4.22 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=127 time=1.02 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=127 time=1.01 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=127 time=1.99 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=127 time=1.03 ms
--- 192.168.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 1.019/1.857/4.221/1.241 ms

A resposta acima indica que o host 192.168.0.1 está disponível. No final algumas estatísticas de tempo e percentual de respostas positivas e negativas são apresentadas.

No exemplo seguinte vemos um caso em que não obtemos resposta do host.

[root@malkovich linux-2.6.3]# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
--- 192.168.0.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3998ms

É chamado de cliente o host que inicia a comunicação, ou seja, a partir do qual o usuário executa o comando de teste de disponibilidade. Servidor é o alvo do teste, pois este deve possuir um serviço habilitado para ser capaz de receber o pacote do cliente e respondê-lo.

O cliente envia primeiro um pacote do tipo ICMP Echo Request, ou simplesmente ICMP Echo. Abaixo está a captura deste pacote na rede. Note o tipo do protocolo no cabeçalho IP (ICMP) e o tipo do pacote no cabeçalho ICMP (Echo request).

Internet Protocol, Src Addr: 192.168.0.2 (192.168.0.2), Dst Addr: 192.168.0.1 (192.168.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 84
Identification: 0x0000 (0)
Flags: 0x04
Fragment offset: 0
Time to live: 64
Protocol: ICMP (0x01)
Header checksum: 0xb955 (correct)
Source: 192.168.0.2 (192.168.0.2)
Destination: 192.168.0.1 (192.168.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x5905 (correct)
Identifier: 0x9409
Sequence number: 0x0001
Data (56 bytes)

Quando o servidor recebe este pacote ele responde com um pacote do tipo ICMP Echo Reply. Veja abaixo a captura deste pacote.

Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.2 (192.168.0.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 84
Identification: 0xa078 (41080)
Flags: 0x00
Fragment offset: 0
Time to live: 127
Protocol: ICMP (0x01)
Header checksum: 0x19dd (correct)
Source: 192.168.0.1 (192.168.0.1)
Destination: 192.168.0.2 (192.168.0.2)
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x6105 (correct)
Identifier: 0x9409
Sequence number: 0x0001
Data (56 bytes)

 

Este processo se repete até que o usuário cancele o ping com um <CONTROL><C>. O utilitário então calcula as estatísticas e as exibe na tela. O usuário também pode controlar, através de opções do comando, quantos pacotes devem ser enviados, o intervalo de tempo entre eles, e o tamanho do pacote. Na verdade a área de dados do pacote não carrega nenhuma informação útil, entretanto, pode ser aumentada para testar a rede com pacotes de tamanhos diferentes. Existe atualmente um limite para o tamanho do pacote, pois um pacote muito grande pode provocar o reboot de alguns sistemas Windows, sendo este o conhecido ping of death, ou ping da morte.

Traceroute

Um dos campos do cabeçalho IP é chamado TTL - Time to Live - e determina por quantas passagens em roteadores este pacote pode sobreviver. A cada passagem em um roteador ou host este campo é decrementado de 1. Este mecanismo é utilizado para evitar que pacotes percorram a rede eternamente, rodando de um lado para outro. Verifique acima que o nosso pacote de ICMP Echo Request possui um TTL igual a 64. Se um pacote possui um TTL de 1 e este deve passar por um roteador antes de alcançar o seu destino final, este roteador irá descartá-lo ao verificar o TTL do pacote e retornar um pacote ICMP do tipo ICMP Time Exceeded para o host que o enviou. Neste pacote de resposta o roteador se identifica como origem da mensagem Time Exceeded. É nessa característica do protocolo que o utilitário traceroute se baseia para traçar uma rota entre dois pontos da rede.

Suponha que o host 1 esteja separado do host 2 por dois roteadores, chamados router A e router B. A partir do host 1 é executado um traceroute para o host 2. O utilitário cria um pacote UDP destinado ao host 2, mas configura o seu TTL para 1. O router A recebe este pacote e, apesar de saber para onde rotear o pacote, ao decrementar o TTL este torna-se 0 (zero) o que siginifica que este pacote deve ser descartado, retornando um ICMP Time Exceeded para o host 1. Quando o traceroute recebe esta resposta ele tem o endereço do primeiro roteador no caminho entre os dois hosts. O primeiro roteador é mostrado para o usuário.  Em seguida, o traceroute cria outro pacote UDP, com o TTL de 2. O pacote sobrevive ao primeiro roteador mas é descartado no segundo. Quando recebe o ICMP Time Exceeded do segundo roteador temos o endereço dele, que também é mostrado na saída do traceroute. O passo seguinte é um pacote com TTL de 3 o qual alcança o host 2. Os pacotes UDP são sempre enviados com uma porta de destino inválida, o que força que o host 2, ao receber o pacote, retorne um pacote ICMP Destination Unreachable. O traceroute sabe então que o caminho completo foi descoberto e mostra ao usuário o endereço do host 2, indicando que o trace foi finalizado.

Como ilustração, executei um traceroute do IP 192.168.1.2 (host virtual A) para o IP 192.168.0.1 (host C). Como roteador entre essas duas máquinas está um Linux (host B) com os IP 192.168.1.1 e 192.168.0.2. Portanto, o caminho do pacote deve ser A <-> B <-> C. O comando foi executado a partir de A:

[root@malkovich root]# traceroute -q 1 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 38 byte packets
1 192.168.1.1 (192.168.1.1) 8.243 ms
2 192.168.0.1 (192.168.0.1) 12.298 ms
3 192.168.0.1 (192.168.0.1) 21.193 ms

 

A opção -q 1 é para que o traceroute envie apenas um pacote a cada interação, o default são 3. A opção -I também poderia ser usada para instruir que sejam usados pacotes ICMP Echo Request e não pacotes UDP.

A sequência de troca de pacotes é a seguinte:

Seq Source --> Destination Protocol Description
1 192.168.1.2 --> 192.168.0.1 UDP Source Port: 33406 Destination Port: 33435 (TTL=1)
2 192.168.1.1 --> 192.168.1.2 ICMP Time-to-live exceeded
3 192.168.1.2 --> 192.168.0.1 UDP Source Port: 33406 Destination Port: 33436 (TTL=2)
4 192.168.0.1 --> 192.168.1.2 ICMP Time-to-live exceeded
5 192.168.0.1 --> 192.168.1.2 ICMP Destination unreachable
6 192.168.1.2 --> 192.168.0.1 UDP Source Port: 33406 Destination Port: 33437 (TTL=3)
7 192.168.0.1 --> 192.168.1.2 ICMP Destination unreachable

 

É mostrado abaixo o primeiro pacote enviado pelo host A e descartado pelo roteador B.

Internet Protocol, Src Addr: 192.168.1.2 (192.168.1.2), Dst Addr: 192.168.0.1 (192.168.0.1)
Version: 4

Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 38
Identification: 0x827f (33407)
Flags: 0x00
Fragment offset: 0
Time to live: 1
Protocol: UDP (0x11)
Header checksum: 0xb4f4 (correct)
Source: 192.168.1.2 (192.168.1.2)
Destination: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 33406 (33406), Dst Port: 33435 (33435)
Source port: 33406 (33406)
Destination port: 33435 (33435)
Length: 18
Checksum: 0xa29f (correct)
Data (10 bytes)

Note o TTL 1 e a porta de destino. A esse pacote o roteador B responde:

Internet Protocol, Src Addr: 192.168.1.1 (192.168.1.1), Dst Addr: 192.168.1.2 (192.168.1.2)
Internet Control Message Protocol
Type: 11 (Time-to-live exceeded)
Code: 0 (Time to live exceeded in transit)
Checksum: 0x7777 (correct)
Internet Protocol, Src Addr: 192.168.1.2 (192.168.1.2), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 33406 (33406), Dst Port: 33435 (33435)
Data (10 bytes)

Podemos confirmar o ICMP Time Exceeded aqui. Após a interação seguinte, o pacote chega ao destino. Como é uma porta inválida, o host 192.168.0.1 responde com um ICMP Destination Unreachable:

Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.1.2 (192.168.1.2)
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)
Checksum: 0x48b6 (correct)
Internet Protocol, Src Addr: 192.168.1.2 (192.168.1.2), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 33406 (33406), Dst Port: 33436 (33436)

Veja que já no passo 5 há uma resposta de ICMP Destination Unreachable, como resposta ao pacote do passo 3, com TTL igual a 2. Entretanto, mesmo assim o traceroute inicia outra interação, enviando um pacote com TTL igual a 3. Isso aconteceu porque antes do ICMP Destination Unreachable ele recebeu, no passo 4, um ICMP Time Exceeded, o que gerou o envio imediato do terceiro pacote UDP.

Pode ser interessante, para quem tem habilidades de programação, olhar o código fonte de uma implementação do traceroute.

Posted in: Redes