Um dos problemas mais comuns que encontramos quando estamos resolvendo problemas em uma rede é perda de conectividade. Por enquanto, vamos ignorar os motivos para a perda de conectividade e olhar para o que realmente ocasionou a perda a nível de pacote, e assim poderemos identificar esse tipo de problema.
O problema começa no pacote 5, onde vemos a primeira retransmissão TCP pacotes (figura abaixo).
Por desenho, quando o TCP envia um pacote para um destino e não tem resposta, ele espera um determinado período de tempo e depois retransmite o pacote original. Se não receber a resposta, a fonte (origem) do computador duplica a quantidade de tempo e aguarda por uma resposta antes de enviar outra retransmissão. O conceito de retransmissão TCP é ilustrado na figura abaixo.
Conforme mostrado na figura abaixo, o processo se repete até que as cinco tentativas de retransmissão TCP sejam concluídas, o que sempre leva aproximadamente 9,6 segundo em sua aplicação Windows. Depois de cinco tentativas de retransmissão falhar, a conexão falha completamente e transmissão de dados é perdida.
Se você definir o formato de exibição de tempo do Wireshark para mostrar o tempo que tem decorrido desde o pacote capturado anteriormente (View > Time Display Format > Seconds Since Beginning of Capture), você poderá visualizar o incremento do tempo entre os pacotes (figura abaixo).
Agora, dê uma olhada nos pacotes retransmitidos na figura abaixo. Observe que o número de seqüência (Seq = 5.840) corresponde ao número de ACK do pacote cinco mostrado na parte inferior da figura acima (ACK = 5,840).
Como você aprendeu no capítulo 6, o TCP usa estes números SEQ e ACK para manter um fluxo TCP em ordem. Como o número SEQ mostrado na retransmissão corresponde ao número ACK do pacote, você sabe que é o pacote 5 que foi perdido e agora está sendo retransmitido. A capacidade de localizar o
�������� � ������� ���� ��� �����������
Ao testar a conectividade da rede, uma das ferramentas mais utilizadas é o utilitário ICMP ping. Se você tiver sorte, o destino que você está pingando vai responder, dizendo que seu ping foi bem sucedido. Infelizmente, muitas vezes você não vai receber uma resposta de ping para trás quando você estiver resolvendo um problema, você receberá uma mensagem Destination unreachable (destino inacessível). Usando um farejado de pacotes (sniffer) em conjunto com um utilitário ICMP poderá obter um pouco mais de informação que apenas o ICMP sozinho faria. Vamos ver se não podemos usar essa mensagem de erro ICMP para isolar o problema.
������� ����������� (����������� �����������)
Quando você abrir o arquivo destunreachable.pcap, você notará que o primeiro pacote no arquivo de captura é o seu padrão Echo (ping) pacote de solicitação (também conhecido como um pacote ICMP tipo 8) de 10.2.10.2 para 10.4.88.88, como mostrado na figura abaixo.
Para verificar isso, olhe para a seção ICMP do painel Packet Details, você deve ver este pacote
identificado como tal. Normalmente, porém, que você iria querer receber um Echo (ping) pacote de resposta (também conhecido como um pacote ICMP tipo 0) em resposta ao seu ping.
Examinando o pacote 2 na figura abaixo, você pode ver que ele também não é um pacote tipo 0, mas sim um pacote tipo 3, que é retornado quando um destino que você estão tentando ping está inacessível.
Nota:
Se o ICMP apenas identifica o tipo de pacote, não temos então muita informação útil. Mas felizmente, ele nos dá um número de código também, como o Código: 1 (host unreachable). (Vários tipos de pacotes ICMP oferecem códigos com um pouco de informação mais específica sobre o pacote.) Observe que o endereço IP de origem no pacote 2 não é o computador que está sendo pingado. Este é um sinal certo de que sua solicitação de eco não veio do seu destino.
O código de ICMP listado (1) nos diz que a solicitação de ping chegou ao roteador ou switch, mas não ao host de destino. Quando um host está inacessível, você também vai ver muitas vezes um broadcast ARP enviado a partir do roteador ou switch. A falta de resposta a este broadcast ARP significa que o dispositivo de envio não pode encontrar o dispositivo de destino, então ele envia um pacote de volta para o computador de origem com um ICMP tipo 0, código 1.
����� ��� ���������� (����������� ����)
Outra tarefa comum quando estamos resolvendo um problema pingando um dispositivo em uma determinada porta. Isso geralmente é feito para garantir que as portas que são necessárias para a execução de determinados serviços estão abertas e aceitam a comunicação de entrada.
Por exemplo, você pode garantir que o FTP é acessível pingando um computador remoto na porta 21. Se por algum motivo o computador remoto não está aceitando a comunicação de entrada na porta 21, ele irá retornar um pacote ICMP tipo 0, o código 2, o que significa que a porta de destino está inacessível.
Desde que você utilize o ICMP com freqüência em sua rede no dia-a-dia em sua rotina de manutenção, você deve se familiarizar com ele e alguns dos seus tipos e códigos mais comuns.
������� ������������
O Internet Protocol é utilizado para uma volumosa transferência de dados através de uma rede, mas nós muitas vezes ignoramos o fato de que é somente assim que uma grande quantidade de dados pode caber no fio de uma vez. Com o intuito de solucionar as limitações das camadas inferiores, O IP possui uma tecnologia chamada de fragmentação. A fragmentação permite que o protocolo IP possa quebrar grandes quantidades de dados em blocos que podem ser enviados através da camada física e remontados no sistema destino.
Nesta seção, vamos dar uma olhada neste fluxo de dados que tem sido fragmentado pelo IP.
O arquivo de traçado ipfragments.pcap consiste em 24 pacotes que mostram um solicitação ping e sua resposta. De nossa experiência anterior, sabemos que uma típica Seqüência ICMP (ping) solicitação-e- resposta só têm oito pacotes. Então por que nós temos muitos mais aqui? Porque neste caso cada pedido e cada resposta exigem três pacotes em vez de apenas um, por isso há três vezes mais pacotes do que o usual, como você pode ver na figura abaixo.
Estes são os pacotes que você veria se capturasse um ping cujo tamanho dos dados fosse maior do que o padrão. Por padrão, um ping envia apenas 32 bytes de dados para o seu destino no Windows. No entanto, como você pode ver, o ping neste traçado está transmitindo 3072 bytes de dados para o cliente. Isso representa um problema, porque o padrão Ethernet só é projetado para lidar com 1.500 bytes em um único pacote. Portanto, O IP deve fragmentar os pacotes em um fluxo de dados, que é o que vemos neste arquivo de rastreamento.
������������ ������ �� ������ � �����������
Como podemos dizer se um pacote foi fragmentado? Felizmente, tudo o que precisamos fazer é olhar para o painelPacket Details no ipfragments.pcap. Aqui está como fazê-lo:
1. No arquivo de captura, selecione o pacote 1, expanda a seçãoInternet Protocolna parte inferior
do painelPacket Details.
2. Você deverá ver uma seção chamada Flags. Expanda esta seção e você deverá ver três campos de dados, como mostrado na figura abaixo. O que é mais nos interessa é a seção More Fragments.
Observe que para este pacote, esta secção tem um valor de 1, isso significa que existe mais fragmentos na seqüência.
pacote é o fim do fluxo de dados e que não há mais fragmentos na seqüência. Os possíveis valores para esse campo e só 1 e 0.
�������� �� ������ �� �����
A próxima pergunta que surge é como estes pacotes fragmentados mantêm a ordem. Uma vez que um dispositivo pode receber múltiplos fluxos de dados de uma só vez, o IP atribui um valor de seqüência para que os sistemas receptores possam saber a ordem dos pacotes fragmentados.
Para ver o valor da seqüência de um pacote fragmentado, olhe na seçãoIP do painelPacket Details.
Por exemplo, se olhar a seção IP do pacote 1 um no arquivo de exemplo, você verá um valor de seqüência 0.
Isto diz que este é o primeiro pacote de uma série de pacotes fragmentados.
Se for para o segundo pacote, você vai ver uma mudança dramática neste número (figura abaixo): ele sobe para 1.480. A razão para esta mudança é que o valor de seqüência de todos os fragmentos do pacote seguinte é determinado pelo tamanho (dados) do pacote anterior (menos o tamanho do cabeçalho IP, que é de 20 bytes). No caso do pacote 2, esse pacote terá o número da seqüência anterior, que é 0, e é adicionado o tamanho (em bytes) do mesmo, que é 1480.
Como o pacote de 2, o pacote 3 tem a seqüência de 1480 acrescentado do tamanho do pacote anterior que é 1480, resultando em uma nova seqüência de 2960. Este conceito é ilustrado na figura abaixo.
Dê uma olhada em alguns exemplos de tráfego IP fragmentado para ver se você pode seguir um fluxo de dados até o fim e manter esse fluxo em ordem usando a seqüência de cada pacote. (Isto pode vir a ser um desafio maior do que você pensa em um arquivo de captura desordenada.)