Introdução
A solução de problemas de rede fica mais simples quando você verifica uma camada de cada vez. Comece pela identidade do host e, em seguida, confirme suas interfaces e endereços, a escolha de rotas, a conectividade 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 escuta apenas na porta de loopback 8088, oferecendo um alvo seguro para praticar ss, curl e regras do UFW. Você não modificará a configuração das interfaces do host, a rota padrão, as configurações de DNS nem o acesso SSH.
Identificar o host
Nesta etapa, você examinará 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
Mostre as identidades estática, transitória e do sistema operacional conhecidas 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.
Examine 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 a 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
Inspecionar interfaces e endereços IP
Nesta etapa, você identificará as interfaces de rede, o estado do enlace, os endereços IPv4, os prefixos e o escopo dos endereços.
Use a visualização resumida dos enlaces:
ip -brief link
lo é a interface de loopback. Outra interface, geralmente chamada eth0 ou ens..., conecta a máquina virtual à 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"
ifconfig é uma ferramenta de interface mais antiga que ainda aparece em runbooks e instruções de solução de problemas existentes. Compare sua saída com a saída moderna de ip que você acabou de examinar:
ifconfig
Salve também essa visualização antiga:
ifconfig > ifconfig-addresses.txt
Salve um resumo das interfaces:
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
Ler a tabela de roteamento
Nesta etapa, você identificará o gateway padrão e perguntará ao Linux qual rota ele usaria para alcançar 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 alcançaria um destino público. Este 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 e a interface padrão:
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
Testar a conectividade de rede
Nesta etapa, você usará ping para testar limites progressivamente 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 aguardam no máximo dois segundos por cada resposta:
ping -c 2 -W 2 127.0.0.1
Um teste de loopback bem-sucedido prova que a pilha IP local está respondendo. 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 tráfego e, ainda assim, 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 de 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
Testar a resolução de nomes de host
Nesta etapa, você examinará 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
Ele geralmente contém uma ou mais linhas nameserver. Em hosts que usam systemd-resolved, o endereço pode identificar um resolvedor local intermediário, em vez de apontar diretamente para 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 o /etc/nsswitch.conf, podendo 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 conectividade DNS. Salve o primeiro registro IPv4 resolvido:
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
Inspecionar uma porta em escuta e a 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 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 por 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/
Um status HTTP 200 OK comprova mais do que uma porta aberta: a aplicação aceitou uma solicitação HTTP e retornou conteúdo. Salve apenas 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
Preservar o acesso e ativar o UFW
Neste passo, você inspecionará o estado do UFW, preservará o acesso de 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 preparação deixa 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 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 uma solicitação de confirmação interativa:
sudo ufw --force enable
Confirme que o firewall está ativo e que ambas as permissões estão presentes:
sudo ufw status verbose
O serviço está vinculado ao endereço de 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 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 de serviço necessárias, ative o firewall e verifique imediatamente a política e a acessibilidade da aplicação. Hosts de produção podem usar outra porta SSH; confirme o caminho de administração real em vez de presumir a porta 22.
Resumo
Você seguiu uma sequência estruturada de diagnóstico de rede no Linux: identidade do host, interfaces e endereços IP, seleção de rotas, conectividade, resolução de nomes, sockets em escuta e resposta HTTP. Aprendeu que cada camada responde a uma pergunta diferente e que uma falha em determinado limite ajuda a direcionar a investigação seguinte.
Você também inspecionou o estado do UFW e gerenciou com segurança uma regra restrita de loopback sem colocar o acesso remoto em risco. Esses hábitos ajudam a diagnosticar e proteger um serviço de rede sem realizar alterações amplas ou potencialmente disruptivas.
