Migrando um Home Server Linux de Wi-Fi para Ethernet Sem Quebrar a Infraestrutura: Um Exercício Real de Troubleshooting

Migrando um Home Server Linux de Wi-Fi para Ethernet Sem Quebrar a Infraestrutura

Índice

Introdução
O erro de enxergar apenas um cabo de rede
Por que um servidor não deveria depender de Wi-Fi
O primeiro princípio do troubleshooting: entender antes de alterar
Descobrindo como o servidor está conectado
- Analisando as interfaces de rede
- Identificando a conexão ativa
O problema oculto: MAC Address e DHCP
Como uma simples troca de interface pode derrubar serviços
Planejando a migração antes de conectar o cabo
Criando uma reserva DHCP
Conectando a Ethernet pela primeira vez
Validando a nova conectividade
- Confirmando o endereço IP
- Confirmando a rota padrão
- Confirmando a resolução DNS
- Confirmando acesso à internet
Desabilitando o Wi-Fi de forma segura
Validando a infraestrutura após a migração
- DNS interno
- Nginx
- Grafana
- Prometheus
- Samba
- Jellyfin
- Calibre-Web
Cenários de falha e troubleshooting
Lições aprendidas
Conclusão

Quando comecei meu homelab, o servidor rodava conectado via Wi-Fi.

Naquele momento fazia sentido.

Era uma máquina simples, hospedando poucos serviços e utilizada principalmente para aprendizado.

Com o passar do tempo, entretanto, aquele mesmo servidor passou a hospedar:

Grafana
Prometheus
Loki
Alloy
Jellyfin
Calibre-Web
Samba
Nginx
DNS interno
Containers Docker diversos

Sem perceber, o ambiente deixou de ser uma máquina de laboratório e passou a se comportar como infraestrutura.

Foi então que surgiu uma pergunta aparentemente simples:

Está na hora de abandonar o Wi-Fi e migrar para Ethernet?

A resposta era sim.

Mas a migração ensinou uma lição importante:

o problema nunca foi o cabo.

O Erro de Enxergar Apenas um Cabo de Rede

Muitos administradores iniciantes pensariam da seguinte forma:

Conectar cabo
↓
Desativar Wi-Fi
↓
Fim

Mas Linux raramente funciona de forma tão simples.

Sempre que uma mudança é feita, devemos nos perguntar:

O que depende disso?

Essa pergunta muda completamente a forma de abordar problemas.

Por Que um Servidor Não Deveria Depender de Wi-Fi

Wi-Fi é excelente para dispositivos móveis.

Servidores possuem requisitos diferentes.

Um servidor precisa de:

estabilidade
previsibilidade
disponibilidade

O Wi-Fi adiciona variáveis desnecessárias:

intensidade do sinal
interferência
qualidade do chipset
problemas do roteador
oscilações de latência

Já a Ethernet entrega algo extremamente valioso:

Comportamento previsível

Em infraestrutura, previsibilidade vale mais que conveniência.

O Primeiro Princípio do Troubleshooting

Antes de alterar qualquer coisa, eu precisava entender o cenário atual.

O primeiro passo foi descobrir quais interfaces existiam.

Para isso utilizei:

ip addr

A saída exibe todas as interfaces conhecidas pelo kernel.

Um resultado simplificado seria:

lo
wlp2s0
enp1s0

Nesse momento não estamos corrigindo nada.

Estamos apenas coletando informações.

Essa diferença é fundamental.

Administradores experientes observam antes de agir.

Descobrindo a Interface Ativa

Depois eu precisava saber qual interface realmente estava sendo utilizada.

Para isso:

nmcli device

Resultado simplificado:

DEVICE      TYPE       STATE
wlp2s0      wifi       connected
enp1s0      ethernet   disconnected

Essa saída respondia duas perguntas importantes:

O Wi-Fi está ativo?
A Ethernet já é reconhecida pelo sistema?

A resposta era sim para ambas.

Isso eliminava diversos cenários de falha.

O Problema Oculto: MAC Address

Foi nesse momento que apareceu o verdadeiro risco da migração.

Cada interface possui um endereço MAC diferente.

Exemplo:

Wi-Fi
AA:AA:AA:AA:AA:AA

Ethernet
BB:BB:BB:BB:BB:BB

E o roteador utiliza exatamente esse endereço para identificar dispositivos.

Isso significa que trocar a interface pode causar:

Novo MAC
↓
Novo lease DHCP
↓
Novo IP

Foi aí que percebi que o problema não era rede.

O problema era infraestrutura.

Como uma Mudança de IP Poderia Quebrar Tudo

Meu servidor utilizava o endereço:

192.168.15.34

Esse IP estava referenciado em:

Prometheus
DNS interno
Configurações do Nginx
Compartilhamentos Samba
Dashboards Grafana
Documentação técnica

Se o servidor recebesse outro endereço, diversos serviços poderiam falhar simultaneamente.

Planejamento Antes da Migração

Em vez de conectar o cabo imediatamente, resolvi eliminar o risco principal.

A solução foi criar uma reserva DHCP no roteador.

A lógica ficou:

MAC Ethernet
↓
Reserva DHCP
↓
192.168.15.34

Agora, independentemente da interface utilizada, o servidor continuaria recebendo o mesmo IP.

Conectando a Ethernet

Somente depois de resolver o problema do DHCP veio a migração física.

Conectei o cabo de rede.

Depois verifiquei novamente:

nmcli device

Resultado esperado:

DEVICE      TYPE       STATE
enp1s0      ethernet   connected
wlp2s0      wifi       connected

A Ethernet já estava operacional.

Confirmando o Endereço IP

Agora era hora de validar a hipótese principal.

Qual endereço o servidor recebeu?

hostname -I

Resultado esperado:

192.168.15.34

Quando vi esse resultado, soube que a reserva DHCP estava funcionando corretamente.

Confirmando a Rota Padrão

Ter IP não significa ter conectividade.

A próxima pergunta foi:

Para onde o servidor está enviando o tráfego?

Verifiquei usando:

ip route

Saída simplificada:

default via 192.168.15.1

A rota padrão estava correta.

Confirmando a Resolução DNS

Depois validei a configuração DNS.

resolvectl status

Esse comando mostra:

servidores DNS
domínios configurados
interface utilizada

Somente depois dessa validação avancei para os testes externos.

Testando Conectividade

Primeiro:

ping 8.8.8.8

Pergunta respondida:

Existe conectividade IP?

Depois:

ping google.com

Pergunta respondida:

O DNS está funcionando?

Perceba que são testes diferentes.

Um verifica rede.

Outro verifica resolução de nomes.

Desabilitando o Wi-Fi

Somente após validar toda a conectividade removi o Wi-Fi da equação.

O objetivo era evitar:

rotas ambíguas
troubleshooting mais complexo
uso acidental da interface sem fio

Quanto menos variáveis um servidor possui, mais simples fica o diagnóstico.

Validando a Infraestrutura

Agora começou a etapa mais importante.

Muita gente para quando consegue navegar na internet.

Mas o trabalho ainda não havia terminado.

DNS Interno

Testei a resolução dos hosts internos:

grafana.home
jellyfin.home
books.home

Se eles resolvessem corretamente, o DNS interno continuava saudável.

Prometheus

Acessei a interface do Prometheus.

Verifiquei:

Status → Targets

Resultado esperado:

UP

Se os targets aparecessem DOWN, o primeiro suspeito seria o endereço IP.

Grafana

Validei dashboards e métricas.

A pergunta era:

O Grafana continua recebendo dados?

Samba

Testei os compartilhamentos de rede.

Antes de investigar Samba, a pergunta correta seria:

O servidor responde ping?

Somente depois faria sentido verificar:

systemctl status smb

Jellyfin

Acessei o serviço normalmente pelo navegador.

O objetivo era confirmar que:

rede funciona
proxy funciona
aplicação funciona

Troubleshooting: Ethernet Não Recebe IP

Primeira verificação:

nmcli device

A interface aparece?

Se não aparece:

cabo
driver
hardware

Se aparece mas não recebe IP:

DHCP
switch
roteador

Troubleshooting: Recebe IP Errado

Primeira pergunta:

A reserva DHCP foi criada para o MAC correto?

Verifique o MAC da interface:

ip link

Depois compare com a configuração do roteador.

Troubleshooting: DNS Interno Parou

Não comece pelo dnsmasq.

Não comece pelo Nginx.

Não comece pelo firewall.

Primeira pergunta:

O servidor recebeu o IP correto?

Esse raciocínio elimina horas de investigação desnecessária.

Troubleshooting: Prometheus Mostra Targets DOWN

Perguntas em sequência:

O IP mudou?
O serviço responde?
O Node Exporter está ativo?
Existe conectividade entre Prometheus e target?

A ordem importa.

A Principal Lição Desta Migração

Os comandos utilizados durante toda a migração são extremamente simples.

Nenhum deles é avançado.

O valor da operação não estava nos comandos.

Estava nas perguntas feitas antes de executá-los.

Linux não recompensa quem memoriza comandos.

Linux recompensa quem entende dependências.

Quando você aprende a enxergar DHCP, DNS, monitoramento, roteamento e aplicações como partes de um mesmo sistema, troubleshooting deixa de ser tentativa e erro.

Passa a ser um processo lógico.

Conclusão

A migração do meu Fedora Server de Wi-Fi para Ethernet foi concluída sem interrupções, mantendo o mesmo endereço IP, os mesmos serviços e toda a infraestrutura operacional.

Mas a verdadeira lição não foi sobre rede.

Foi sobre pensamento sistêmico.

A mudança física levou poucos minutos.

O planejamento, a análise de dependências e a validação da infraestrutura foram responsáveis pelo sucesso da operação.

E essa talvez seja a habilidade mais importante que um administrador Linux pode desenvolver: aprender a entender sistemas antes de tentar corrigí-los.