Introdução
A solução de problemas de rede fica mais fácil quando você verifica uma camada de cada vez. Comece pela identidade do host. Em seguida, confirme as interfaces e os endereços, a seleção de rotas, a acessibilidade básica, a resolução de nomes, os sockets em escuta, a resposta da aplicação e, por fim, a política do firewall local.
Neste laboratório, você seguirá essa sequência em um host Ubuntu. Um serviço HTTP preparado fica em escuta somente na porta de loopback 8088, oferecendo um alvo seguro para praticar ss, curl e regras do UFW. Você não alterará a configuração das interfaces do host, a rota padrão, as configurações de DNS nem o serviço SSH. Antes de ativar o UFW, você preservará explicitamente o acesso SSH.
Identifique o host
Nesta etapa, você verificará o nome do host e os registros de nomes locais que ajudam os programas a identificar esta máquina.
Entre no diretório de trabalho do laboratório:
cd /home/labex/project/network-lab
Exiba o nome atual do host:
hostname
Exiba a identidade estática, transitória e do sistema operacional conhecida pelo systemd:
hostnamectl
Static hostname é o nome configurado. Em máquinas de treinamento na nuvem, o nome transitório pode ser atribuído durante a inicialização.
Inspecione os mapeamentos locais de hosts:
cat /etc/hosts
Os nomes de loopback localhost, 127.0.0.1 e ::1 identificam este mesmo host sem usar uma rede externa. Exiba os endereços IP atribuídos ao host em formato compacto:
hostname -I
Salve o nome do host e a lista de endereços:
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
Inspecione as interfaces e os endereços IP
Nesta etapa, você identificará as interfaces de rede, o estado do link, os endereços IPv4, os prefixos e o escopo dos endereços.
Use a visualização resumida dos links:
ip -brief link
lo é a interface de loopback. Outra interface, geralmente chamada eth0 ou ens..., conecta a VM à rede. UP significa que a interface está habilitada administrativamente.
Exiba os endereços em formato compacto:
ip -brief address
Um endereço como 192.0.2.10/24 combina um endereço IPv4 e o comprimento do prefixo. O prefixo descreve quais bits iniciais identificam a rede local.
Inspecione a interface de loopback em detalhes:
ip address show dev lo
O endereço IPv4 127.0.0.1/8 tem scope host, portanto é válido somente dentro deste host. Descubra qual interface é usada pela rota padrão:
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
O comando ifconfig é uma ferramenta mais antiga para interfaces, mas ainda aparece em procedimentos operacionais e instruções de solução de problemas existentes. Compare a saída dele com a saída moderna do ip que você acabou de analisar:
ifconfig
Salve também a visualização legada:
ifconfig > ifconfig-addresses.txt
Salve um instantâneo resumido das interfaces:
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
Leia a tabela de roteamento
Nesta etapa, você identificará o gateway padrão e perguntará ao Linux qual rota ele usaria para um destino.
Exiba a tabela de roteamento principal:
ip route
As rotas conectadas descrevem redes diretamente anexadas. Uma linha que começa com default via é usada quando nenhuma rota mais específica corresponde ao destino.
Pergunte ao kernel como ele chegaria a um destino público. Esse comando informa o gateway, a interface e o endereço de origem selecionados sem enviar um pacote:
ip route get 1.1.1.1
Extraia o gateway padrão e a interface:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
Salve o resumo da rota:
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
Teste a acessibilidade da rede
Nesta etapa, você usará ping para testar limites cada vez mais distantes, lembrando que algumas redes bloqueiam pacotes de diagnóstico.
Comece pelo loopback. As opções -c 2 enviam duas solicitações, e -W 2 espera no máximo dois segundos por cada resposta:
ping -c 2 -W 2 127.0.0.1
Um teste de loopback bem-sucedido comprova que a pilha IP local responde. Em seguida, obtenha e teste o gateway padrão:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
A mensagem alternativa é importante porque um roteador pode encaminhar o tráfego e, ao mesmo tempo, recusar solicitações de ping. Teste um endereço IP público sem depender do DNS:
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
Salve um resultado estável da conectividade local, sem depender de políticas externas:
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
Teste a resolução de nomes de host
Nesta etapa, você inspecionará a configuração do resolvedor e converterá nomes de host em endereços.
Veja o arquivo do resolvedor usado pelos aplicativos Linux padrão:
cat /etc/resolv.conf
Esse arquivo geralmente contém uma ou mais linhas nameserver. Em hosts que usam systemd-resolved, o endereço pode identificar um resolvedor stub local, em vez de identificar diretamente um servidor DNS externo.
Resolva um nome local usando a configuração completa de serviços de nomes do sistema:
getent hosts localhost
getent segue /etc/nsswitch.conf, portanto pode combinar /etc/hosts, DNS e outras fontes configuradas. Resolva um nome externo e solicite endereços de socket IPv4:
getent ahostsv4 example.com
Se o ping para um IP funcionar, mas essa consulta falhar, concentre a investigação na configuração do resolvedor ou na acessibilidade do DNS. Salve o primeiro registro IPv4 resolvido:
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
Inspecione uma porta em escuta e uma resposta HTTP
Nesta etapa, você associará um socket TCP em escuta ao processo responsável por ele e testará o protocolo da aplicação.
O serviço de demonstração preparado fica em escuta na porta de loopback 8088. Use ss para inspecionar sockets TCP em escuta. As opções -l, -t, -n e -p significam escuta, TCP, endereços numéricos e informações do processo:
sudo ss -ltnp | grep ':8088'
Procure 127.0.0.1:8088. A associação ao loopback significa que o serviço só pode ser acessado a partir deste host.
Verifique o processo do serviço associado ao socket:
systemctl status labex-network-demo.service --no-pager
Use curl -i para exibir os cabeçalhos e o corpo da resposta HTTP:
curl -i http://127.0.0.1:8088/
O status HTTP 200 OK comprova mais do que uma porta aberta: a aplicação aceitou uma solicitação HTTP e retornou conteúdo. Salve somente o corpo da resposta usando o modo silencioso -s:
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
Preserve o acesso e ative o UFW
Nesta etapa, você verificará o estado do UFW, preservará o acesso à administração remota, permitirá a porta do serviço de prática e ativará o firewall.
O UFW é uma interface para as regras de filtragem de pacotes do Linux. Inspecione o estado atual:
sudo ufw status verbose
A configuração inicial mantém o UFW inativo e com um conjunto de regras limpo. Antes de ativar remotamente qualquer firewall do host, permita o caminho de administração do qual você depende. Esta VM usa a porta TCP 22 para SSH:
sudo ufw allow 22/tcp
Agora permita o tráfego TCP de entrada para a porta do serviço de prática:
sudo ufw allow 8088/tcp
Revise as alterações preparadas antes da ativação:
sudo ufw show added
Ative o UFW sem um prompt de confirmação interativo:
sudo ufw --force enable
Confirme que o firewall está ativo e que as duas permissões estão presentes:
sudo ufw status verbose
O serviço está associado ao loopback, portanto teste-o localmente após a alteração do firewall:
curl -fsS http://127.0.0.1:8088/
Salve o estado ativo como um resultado observável:
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
A ordem é importante: preserve o caminho de administração, adicione as regras necessárias para o serviço, ative o firewall e verifique imediatamente a política e a acessibilidade da aplicação. Hosts de produção podem usar uma porta SSH diferente; por isso, confirme o caminho real de administração em vez de presumir que a porta é 22.
Resumo
Você seguiu uma cadeia estruturada de diagnóstico de rede no Linux: identidade do host, interfaces e endereços IP, seleção de rotas, acessibilidade, resolução de nomes, sockets em escuta e resposta HTTP. Você aprendeu que cada camada responde a uma pergunta diferente e que uma falha em determinado limite restringe o foco da próxima investigação.
Você também preservou o acesso SSH, permitiu a porta de um serviço de prática, ativou o UFW e verificou tanto a política ativa quanto a resposta da aplicação. Esses hábitos ajudam você a diagnosticar e proteger um serviço de rede sem fazer alterações amplas e disruptivas.
