Introdução
Neste laboratório, você explorará os princípios fundamentais da conectividade da camada de rede em um ambiente Linux. Usando contêineres Docker para simular dois nós separados, você aprenderá como atribuir manualmente endereços IP estáticos com o comando ip. Em seguida, você usará a utilidade ping para testar o caminho de comunicação direta entre esses nós em uma rede virtual compartilhada.
Ao configurar primeiro os nós na mesma sub-rede, você observará conectividade bem-sucedida. Em seguida, você reconfigurará um nó para uma sub-rede diferente para testemunhar uma falha de comunicação previsível – o erro 'Destination Host Unreachable'. Este exercício prático fornece uma demonstração clara e prática de como as sub-redes IP governam a comunicação direta e por que dispositivos em redes lógicas diferentes não podem se conectar sem um roteador.
Preparar o Ambiente de Laboratório com Dois Nós
Nesta etapa, você configurará o ambiente fundamental para o nosso laboratório. Em vez de usar máquinas virtuais completas, utilizaremos contêineres Docker leves e isolados para simular dois nós de rede separados. Para permitir a comunicação entre eles, primeiro criaremos uma rede Docker personalizada. Esta rede virtual funciona como um switch de rede físico, colocando ambos os nossos nós no mesmo segmento de comunicação compartilhado.
Vamos baixar a imagem Docker do Ubuntu 22.04 para os nós.
docker pull ubuntu:22.04
Primeiro, vamos criar a rede virtual que nossos dois nós usarão. Vamos chamá-la de lab_net e atribuir a ela um intervalo de endereços IP específico, que será importante em etapas posteriores.
Execute o seguinte comando no seu terminal:
docker network create --subnet=192.168.56.0/24 lab_net
Este comando instrui o Docker a criar uma nova rede bridge chamada lab_net e a configura para usar a sub-rede 192.168.56.0/24. Você verá um ID único longo para a rede como saída, confirmando sua criação.
e8c1c2a3b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1
Em seguida, iniciaremos nosso primeiro nó, um contêiner chamado node1, e o conectaremos à rede lab_net.
docker run -d --name node1 --network lab_net --cap-add=NET_ADMIN ubuntu:22.04 sleep infinity
Vamos detalhar este comando:
docker run: O comando padrão para criar e iniciar um novo contêiner.-d: Executa o contêiner em modo "detached" (desanexado), o que significa que ele roda em segundo plano.--name node1: Atribui um nome simples e memorável ao nosso contêiner.--network lab_net: Conecta o contêiner à rede virtual que criamos anteriormente.--cap-add=NET_ADMIN: Concede ao contêiner a capacidadeNET_ADMIN, que é necessária para modificar configurações de rede, como adicionar endereços IP.ubuntu:22.04: A imagem Docker que estamos usando, que fornece um ambiente Ubuntu padrão.sleep infinity: Um comando simples que roda indefinidamente para manter o contêiner ativo.
Agora, inicie o segundo nó, node2, usando um comando semelhante:
docker run -d --name node2 --network lab_net --cap-add=NET_ADMIN ubuntu:22.04 sleep infinity
Finalmente, vamos verificar se ambos os nossos nós estão rodando corretamente. O comando docker ps lista todos os contêineres em execução no momento.
docker ps
Você deverá ver uma saída semelhante à seguinte, confirmando que node1 e node2 estão ambos ativos e em execução.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 ubuntu:22.04 "sleep infinity" 5 seconds ago Up 4 seconds node2
g7h8i9j0k1l2 ubuntu:22.04 "sleep infinity" 15 seconds ago Up 14 seconds node1
Com ambos os nós rodando na mesma rede virtual, nosso ambiente de laboratório está agora preparado. Nas próximas etapas, configuraremos seus endereços IP e testaremos sua conectividade.
Configurar um IP Estático no Primeiro Nó usando ip addr
Nesta etapa, você atribuirá um endereço IP estático ao nosso primeiro contêiner, node1. Um IP estático é um endereço que é configurado manualmente e não muda, ao contrário de um IP dinâmico que é frequentemente atribuído automaticamente por um servidor DHCP. Para nossa simulação, o uso de IPs estáticos nos dá controle preciso sobre a configuração de rede.
Realizaremos todas as ações a partir do seu terminal principal na máquina host, usando o comando docker exec para executar comandos dentro do contêiner node1.
Primeiro, a imagem base ubuntu:22.04 é muito minimalista. Precisamos instalar as ferramentas de rede necessárias. Vamos começar atualizando a lista de pacotes dentro do contêiner node1:
docker exec node1 apt-get update
Você verá a saída enquanto o contêiner busca as informações mais recentes dos pacotes.
Em seguida, instale o pacote iproute2 (que fornece o comando ip) e iputils-ping (que fornece o comando ping que usaremos mais tarde).
docker exec node1 apt-get install -y iproute2 iputils-ping
Agora que as ferramentas estão instaladas, vamos inspecionar a configuração de rede atual do node1. A interface de rede dentro de um contêiner Docker padrão é tipicamente nomeada eth0.
docker exec node1 ip addr show eth0
A saída mostrará os detalhes da interface eth0. Você pode ver um endereço IP já atribuído pelo servidor DHCP interno do Docker (por exemplo, 192.168.56.2). Vamos adicionar nosso próprio IP estático.
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.2/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
Agora, vamos atribuir o endereço IP estático 192.168.56.10 ao node1. O /24 é a notação CIDR para a máscara de rede 255.255.255.0, definindo o tamanho da rede.
docker exec node1 ip addr add 192.168.56.10/24 dev eth0
Este comando não deve produzir nenhuma saída se for bem-sucedido. Para confirmar a alteração, execute o comando ip addr show eth0 novamente:
docker exec node1 ip addr show eth0
Você deverá agora ver o seu novo endereço IP estático listado ao lado do original, marcado como secondary. Isso confirma que o node1 está agora configurado com o endereço 192.168.56.10.
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.2/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.56.10/24 scope global secondary eth0
valid_lft forever preferred_lft forever
Configurar um IP Estático no Segundo Nó na Mesma Sub-rede
Nesta etapa, configuraremos nosso segundo nó, node2, com um endereço IP estático. Para que dois dispositivos se comuniquem diretamente sem um roteador, eles devem residir na mesma sub-rede lógica. Atribuiremos ao node2 um endereço IP da mesma sub-rede 192.168.56.0/24 que usamos para o node1. Esta configuração imita logicamente dois PCs conectados com um cabo crossover, onde ambos fazem parte da mesma rede local.
Primeiro, assim como fizemos para o node1, precisamos instalar as ferramentas de rede necessárias dentro do contêiner node2. Comece atualizando a lista de pacotes:
docker exec node2 apt-get update
Em seguida, instale os pacotes iproute2 e iputils-ping no node2:
docker exec node2 apt-get install -y iproute2 iputils-ping
Com as ferramentas instaladas, podemos agora atribuir um endereço IP estático ao node2. Usaremos 192.168.56.11, que está na mesma sub-rede do node1 (192.168.56.10), mas é um endereço único.
docker exec node2 ip addr add 192.168.56.11/24 dev eth0
Este comando adiciona o endereço IP 192.168.56.11 com uma máscara de rede /24 à interface de rede eth0 do contêiner node2. Se o comando for bem-sucedido, ele não produzirá nenhuma saída.
Para verificar se o endereço IP foi atribuído corretamente, vamos inspecionar a configuração de rede do node2:
docker exec node2 ip addr show eth0
A saída deverá agora exibir o endereço IP estático recém-adicionado, marcado como secondary. Isso confirma que o node2 está configurado corretamente e pronto para a próxima etapa, onde testaremos a conectividade.
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.3/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.56.11/24 scope global secondary eth0
valid_lft forever preferred_lft forever
Verificar Conectividade Direta Entre Nós com ping
Nesta etapa, você testará a conectividade de rede entre node1 e node2. Agora que ambos os nós possuem endereços IP na mesma sub-rede, eles devem ser capazes de se comunicar diretamente. Usaremos o comando ping, uma utilidade de rede fundamental que envia um pequeno pacote de dados (um ICMP Echo Request) para um host de destino e aguarda uma resposta. Uma resposta bem-sucedida confirma que existe um caminho de rede entre os dois dispositivos.
Este teste bem-sucedido é análogo a conectar dois PCs com um cabo crossover, onde ambos os dispositivos estão na mesma rede local e podem se ver diretamente.
Primeiro, vamos tentar pingar o node2 a partir do node1. Executaremos o comando ping dentro do contêiner node1, tendo como alvo o endereço IP do node2, 192.168.56.11.
docker exec node1 ping -c 4 192.168.56.11
Vamos detalhar este comando:
docker exec node1: Executa o comando seguinte dentro do contêinernode1.ping: A utilidade para testar a conectividade.-c 4: Um flag que instrui opinga enviar exatamente 4 pacotes e depois parar. Sem isso, opingrodaria indefinidamente.192.168.56.11: O endereço IP de destino donode2.
Você deverá ver uma saída bem-sucedida, com respostas recebidas do node2.
PING 192.168.56.11 (192.168.56.11) 56(84) bytes of data.
64 bytes from 192.168.56.11: icmp_seq=1 ttl=64 time=0.123 ms
64 bytes from 192.168.56.11: icmp_seq=2 ttl=64 time=0.087 ms
64 bytes from 192.168.56.11: icmp_seq=3 ttl=64 time=0.091 ms
64 bytes from 192.168.56.11: icmp_seq=4 ttl=64 time=0.085 ms
--- 192.168.56.11 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.085/0.096/0.123/0.015 ms
A linha "4 received, 0% packet loss" confirma que a conexão está funcionando. Agora, vamos verificar a conexão na outra direção, pingando o node1 a partir do node2.
docker exec node2 ping -c 4 192.168.56.10
Novamente, você deverá ver uma série bem-sucedida de respostas, confirmando que a comunicação é bidirecional.
PING 192.168.56.10 (192.168.56.10) 56(84) bytes of data.
64 bytes from 192.168.56.10: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from 192.168.56.10: icmp_seq=2 ttl=64 time=0.088 ms
64 bytes from 192.168.56.10: icmp_seq=3 ttl=64 time=0.092 ms
64 bytes from 192.168.56.10: icmp_seq=4 ttl=64 time=0.089 ms
--- 192.168.56.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3081ms
rtt min/avg/max/mdev = 0.088/0.092/0.099/0.004 ms
Sucesso! Ambos os nós podem se comunicar entre si, como se fossem dois computadores no mesmo segmento de rede local.
Reconfigurar o Segundo Nó para uma Sub-rede Diferente
Nesta etapa, vamos intencionalmente quebrar a conectividade direta entre nossos dois nós. Faremos isso reconfigurando o node2 para estar em uma sub-rede IP completamente diferente da do node1. Isso simula um cenário onde dois dispositivos estão fisicamente conectados, mas logicamente separados em redes diferentes.
Atualmente, o node1 está na sub-rede 192.168.56.0/24. Agora moveremos o node2 para a sub-rede 192.168.58.0/24. Como o terceiro número (octeto) é diferente (56 vs. 58), estas são consideradas sub-redes separadas.
Para garantir que o node2 esteja completamente isolado na nova rede, devemos primeiro remover todos os endereços IP existentes de sua interface eth0. Isso inclui tanto o IP estático que adicionamos anteriormente quanto o IP original que o Docker atribuiu automaticamente. O comando ip addr flush é a ferramenta correta para esta tarefa.
docker exec node2 ip addr flush dev eth0
Este comando remove todas as configurações de IP da eth0, garantindo uma base limpa. Ele não deve produzir nenhuma saída se for bem-sucedido.
Agora, vamos adicionar o novo endereço IP, 192.168.58.11, que pertence à nova sub-rede.
docker exec node2 ip addr add 192.168.58.11/24 dev eth0
Para confirmar as alterações, vamos inspecionar a configuração de rede do node2 novamente.
docker exec node2 ip addr show eth0
Você verá que todos os IPs antigos desapareceram, e apenas o novo (192.168.58.11) existe. Isso confirma que o node2 não está mais na sub-rede 192.168.56.0/24.
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.58.11/24 scope global eth0
valid_lft forever preferred_lft forever
Com o node1 na sub-rede 192.168.56.0/24 e o node2 na sub-rede 192.168.58.0/24, eles agora estão logicamente isolados.
Testar Conectividade e Observar Falha
Nesta etapa final, tentaremos pingar entre os nós novamente. Com o node2 agora verdadeiramente isolado em uma nova sub-rede, esperamos que a comunicação falhe, mas de duas maneiras diferentes e importantes que revelam como as camadas de rede operam.
Primeiro, vamos tentar pingar o novo endereço IP do node2 (192.168.58.11) a partir do node1.
docker exec node1 ping -c 4 192.168.58.11
Observe a saída. O comando atingirá o tempo limite (timeout), resultando em 100% de perda de pacotes.
PING 192.168.58.11 (192.168.58.11) 56(84) bytes of data.
--- 192.168.58.11 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3076ms
Este timeout ocorre porque o node1 ainda tem uma rota para a rede Docker, então ele envia o pacote ping. A rede o encaminha para o node2. No entanto, como o node2 não está mais nessa rede e não tem rota de volta, ele não pode enviar uma resposta. O ping do node1 nunca recebe uma resposta.
Em seguida, vamos testar a outra direção. Tente pingar o node1 a partir do node2.
docker exec node2 ping -c 4 192.168.56.10
Desta vez, você verá uma mensagem de erro diferente quase imediatamente.
ping: connect: Network is unreachable
A mensagem ping: connect: Network is unreachable é significativa. É uma resposta imediata do sistema operacional no node2. Isso significa que o SO verificou sua tabela de roteamento, viu que o destino 192.168.56.10 está em uma rede para a qual não tem caminho, e se recusou a sequer tentar enviar o pacote. Este é um resultado direto do uso de ip addr flush, que limpou todas as rotas, isolando completamente o contêiner de outras redes.
Este laboratório demonstrou com sucesso o papel crítico do sub-redes IP e do roteamento. Quando os dispositivos estão na mesma sub-rede, eles podem se comunicar diretamente. Quando estão em sub-redes diferentes, um dispositivo de Camada 3 como um roteador com rotas apropriadas é necessário para encaminhar o tráfego entre eles.
Resumo
Neste laboratório, você aprendeu a simular um ambiente de rede com dois nós usando contêineres Docker conectados a uma rede bridge personalizada. Você praticou a habilidade essencial do Linux de configurar endereços IP estáticos em interfaces de rede usando o comando ip addr. Ao atribuir endereços IP da mesma sub-rede a ambos os nós, você verificou com sucesso a conectividade direta de Camada 3 entre eles com a utilidade ping, demonstrando o requisito fundamental para comunicação em um segmento de rede local.
O laboratório ilustrou ainda mais um conceito crítico de rede, reconfigurando um nó com um endereço IP de uma sub-rede diferente após limpar completamente sua configuração de rede original. As tentativas subsequentes de comunicação via ping falharam com dois resultados distintos: um timeout em uma direção e um erro 'Destination Host Unreachable' na outra. Este resultado mostrou efetivamente que nós em sub-redes lógicas diferentes não podem se comunicar diretamente sem um roteador, e destacou como as tabelas de roteamento e a configuração da interface afetam a conectividade de rede.
