Introdução
Neste laboratório, você explorará a interação fundamental entre a camada de rede (Camada 3) e a camada de enlace de dados (Camada 2) em um ambiente Linux. Você usará as utilidades de linha de comando comuns ping e arp para observar o Protocolo de Resolução de Endereços (ARP - Address Resolution Protocol) em ação. O objetivo principal é entender como seu sistema resolve endereços IP para endereços MAC físicos para dispositivos na rede local e como ele lida com a comunicação com hosts remotos.
Você começará inspecionando o estado do cache ARP. Em seguida, usará o ping para se comunicar com um dispositivo local (seu gateway padrão) e um dispositivo remoto (google.com). Ao observar o cache ARP antes e depois dessas ações, você verá como seu sistema usa endereços MAC para comunicação local e confia no gateway padrão para tráfego remoto.
Visualizar o Cache ARP Inicial com arp -a
Nesta etapa, você inspecionará o estado inicial do cache do Protocolo de Resolução de Endereços (ARP) do seu sistema. O cache ARP é um componente de rede crucial que armazena os mapeamentos entre endereços de Camada 3 (IP) e seus endereços de Camada 2 (MAC) correspondentes para dispositivos na mesma rede local.
Primeiro, vamos verificar o estado atual do cache ARP usando o comando arp. A flag -a instrui o comando a exibir todas as entradas atuais.
No seu terminal, que já está no caminho ~/project, execute o seguinte comando:
arp -a
Você provavelmente verá uma ou mais entradas. É comum que o gateway padrão já esteja presente no cache. Sua saída pode ser semelhante a esta:
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
É importante notar que, devido à natureza virtualizada do ambiente LabEx, nem sempre é possível limpar completamente o cache ARP. Portanto, você provavelmente verá um cache pré-preenchido desde o início. Em uma configuração típica não virtualizada, você veria com mais frequência uma entrada vazia ou
<incomplete>para o gateway antes da primeira comunicação.
Esta saída mostra o estado inicial do nosso cache ARP. Ele serve como uma linha de base para nossas próximas etapas, onde acionaremos atividade de rede e observaremos como esta tabela é usada.
Pingar um Dispositivo Local para Disparar uma Requisição ARP
Nesta etapa, você usará o comando ping para iniciar a comunicação com outro dispositivo em sua rede local. Esta ação usará o mapeamento do Protocolo de Resolução de Endereços (ARP) se um for necessário. Quando seu sistema tenta enviar um pacote para um endereço IP local, ele primeiro verifica seu cache ARP. Se não encontrar um endereço MAC correspondente, ele enviará uma solicitação ARP de broadcast. Se a entrada já existir, ele usará o endereço MAC em cache.
Para realizar isso, primeiro precisamos identificar o endereço IP de um dispositivo na rede local. O alvo mais confiável neste ambiente é o seu gateway padrão (o roteador virtual). Você pode encontrar o endereço IP dele inspecionando a tabela de roteamento.
No seu terminal, execute o seguinte comando para exibir a tabela de roteamento:
ip route show
A saída mostrará a rota padrão. Procure pela linha que começa com default via. O endereço IP listado lá é o seu gateway.
default via 172.16.50.253 dev eth0 ...
...
Da saída de exemplo acima, o endereço IP do gateway é 172.16.50.253. Agora, use este endereço IP para enviar alguns pacotes ping. A opção -c 4 diz ao ping para enviar exatamente 4 pacotes e depois parar. Substitua 172.16.50.253 pelo IP real do gateway que você encontrou.
ping -c 4 172.16.50.253
Você deverá ver uma resposta bem-sucedida para cada pacote, confirmando que seu sistema conseguiu se comunicar com o gateway.
PING 172.16.50.253 (172.16.50.253) 56(84) bytes of data.
64 bytes from 172.16.50.253: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.16.50.253: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.16.50.253: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 172.16.50.253: icmp_seq=4 ttl=64 time=0.045 ms
--- 172.16.50.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.045/0.056/0.066/0.007 ms
Esta ação simples forçou seu sistema a realizar uma consulta ARP. Na próxima etapa, inspecionaremos o cache ARP novamente para ver o resultado.
Verificar a Resolução Local de IP para MAC no Cache ARP
Nesta etapa, você reexaminará o cache ARP para ver o resultado direto do comando ping que você executou anteriormente. Como seu sistema se comunicou com sucesso com o gateway local, ele deve ter tido um mapeamento válido de endereço IP para MAC. Vamos ver se a tabela mudou.
Vamos inspecionar o cache ARP novamente. No seu terminal, execute o mesmo comando da primeira etapa:
arp -a
Desta vez, a saída será diferente apenas se a entrada não estava completa. No nosso caso, como a entrada já foi resolvida na Etapa 1, a saída será idêntica.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Compare esta saída com a da Etapa 1. É idêntica. Isso ocorre porque a entrada ARP para o gateway já estava completa antes de enviarmos o ping. Seu sistema não precisou realizar uma nova solicitação ARP; ele simplesmente confiou nas informações já presentes no cache.
Isso demonstra um princípio fundamental: o cache ARP evita solicitações ARP redundantes. Se a entrada estivesse <incomplete> (incompleta) ou ausente, este comando ping a teria preenchido, e você teria visto uma mudança na saída.
Pingar um Host Externo para Envolver o Gateway Padrão
Nesta etapa, você mudará de comunicar com um dispositivo local para comunicar com um host na internet. Isso demonstra um conceito fundamental de rede: como seu computador usa seu gateway padrão para alcançar destinos fora de sua própria rede local.
Quando o endereço IP de destino não está na mesma sub-rede que o seu computador, seu sistema sabe que não pode enviar o pacote diretamente. Em vez disso, ele deve enviar o pacote para seu gateway padrão designado. O gateway (um roteador) é responsável por encaminhar o pacote em direção ao seu destino final pela internet.
Para ver isso em ação, você pingará um host externo conhecido, google.com.
No seu terminal, execute o seguinte comando:
ping -c 4 google.com
Você verá o domínio google.com ser resolvido para um endereço IP e, em seguida, receberá respostas desse endereço.
PING google.com (142.250.189.174) 56(84) bytes of data.
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=1 ttl=118 time=4.38 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=2 ttl=118 time=4.40 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=3 ttl=118 time=4.35 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=4 ttl=118 time=4.39 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.353/4.380/4.401/0.017 ms
Mesmo que você tenha se comunicado com sucesso com google.com, seu computador não realizou uma solicitação ARP para o endereço IP do Google. Ele só precisou do endereço MAC de seu gateway local, que já encontrou nas etapas anteriores. Na próxima etapa, você analisará o cache ARP para confirmar esse comportamento.
Analisar o Cache ARP para Comunicação Remota
Nesta etapa final, você analisará o cache ARP mais uma vez para confirmar como seu sistema lida com a comunicação com hosts remotos. Isso solidificará a distinção entre comunicação de rede local e remota e destacará o papel do gateway padrão.
Agora que você pingou com sucesso google.com, vamos verificar o cache ARP novamente. No seu terminal, execute o comando arp -a:
arp -a
Examine cuidadosamente a saída. Ela deve ser idêntica ao estado do cache das etapas anteriores.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Você notará que não há entrada para google.com ou seu endereço IP (por exemplo, 142.250.189.174). A única entrada significativa presente ainda é a do seu gateway padrão.
Este é o principal aprendizado deste laboratório. O ARP opera na Camada 2 e é usado apenas para encontrar endereços MAC no segmento de rede local. Quando seu computador envia um pacote para um destino remoto, ele sabe que o destino não é local, portanto, envia o pacote para o endereço MAC do próximo salto — seu gateway padrão. O roteador, então, assume a responsabilidade de encaminhar o pacote IP em direção ao seu destino final. Seu computador não precisa saber o endereço MAC do google.com; ele só precisa saber o endereço MAC do dispositivo que pode encaminhar o pacote para ele.
Resumo
Neste laboratório, você explorou a interação fundamental entre as camadas de rede Camada 3 (IP) e Camada 2 (MAC) usando os comandos ping e arp no Linux. Você começou inspecionando o estado do cache do Protocolo de Resolução de Endereços (ARP) com arp -a, observando que ele pode já conter entradas para dispositivos críticos como o gateway padrão. Ao pingar o gateway local, você confirmou que o sistema usa essas informações em cache para comunicação local, evitando pesquisas de endereço redundantes.
Além disso, você investigou como a comunicação com um host remoto difere. Ao pingar um endereço IP externo, você observou que o sistema não realiza uma solicitação ARP para o destino final. Em vez disso, ele envia o pacote para o gateway padrão para ser roteado para fora da rede local. A análise final do cache ARP reforçou esse conceito, mostrando que nenhuma entrada foi adicionada para o host remoto. A única entrada relevante permaneceu a do gateway padrão, destacando seu papel crucial como intermediário para todo o tráfego destinado a redes externas.
