VPS RackNerd sem rede: o que fazer (2026): diagnóstico e correção de falhas de SSH e Ping quando o VNC funciona

No seu computador local, primeiro faça três verificações:

ping -c 4 你的VPS公网IP
nc -vz 你的VPS公网IP 22
ssh -vvv root@你的VPS公网IP

Um Ping que falha sozinho não prova que o servidor está offline; muitos VPS filtram ICMP. O que realmente é diagnóstico é a porta TCP 22:

Se a mesma máquina funcionava antes e você acabou de alterar UFW, iptables, NetworkManager ou netplan, priorize reverter e verificar a partir da alteração mais recente.

Entre no VNC ou Web Console do console do provedor e primeiro verifique o kernel e as interfaces de rede:

uname -a
ip -br link
ip -br address
ip route

Normalmente, a interface de rede principal (nomes comuns eth0, ens3 ou enp1s0) deve estar em UP e ter um IPv4 público atribuído pelo provedor. A rota padrão geralmente se parece com:

default via 203.0.113.1 dev eth0
203.0.113.0/24 dev eth0 proto kernel scope link src 203.0.113.10

Os seguintes resultados significam, respectivamente:

• A interface está em DOWN: a interface não está habilitada, ou o serviço de gerenciamento de rede não a assumiu;
• A interface está em UP mas não tem endereço inet: há um problema no DHCP, na configuração estática ou na configuração do cloud-init;
• Tem IP mas não tem rota default: só consegue acessar a mesma sub-rede e não consegue acessar a internet;
• IP e rota estão normais mas os nomes de domínio falham: continue verificando o DNS, não reinicie repetidamente a interface.

Após confirmar o nome da interface física, execute:

ip link set dev eth0 up

Substitua eth0 pelo nome real exibido por ip -br link. Este comando apenas habilita a interface; ele não adivinha o IP e o gateway por você.

Não execute apenas ping google.com. Testar na seguinte ordem localiza rapidamente em qual camada está a falha:

ip route get 1.1.1.1
ping -c 4 你的默认网关
ping -c 4 1.1.1.1
getent hosts google.com
resolvectl status 2>/dev/null || cat /etc/resolv.conf

• O gateway padrão não responde ao Ping: primeiro corrija a interface, o IP, a rota ou a rede do lado do provedor;
• Gateway acessível, 1.1.1.1 inacessível: verifique a rota padrão, a política de saída e o status da rede do provedor do VPS;
• 1.1.1.1 acessível, nomes de domínio falham: verifique /etc/resolv.conf, o systemd-resolved ou as regras de firewall de DNS;
• Tudo normal mas o SSH falha: a falha já se restringiu ao sshd, ao firewall da porta 22 ou ao Fail2Ban.

Teste temporário de DNS (apenas para diagnóstico; não é recomendado sobrescrever permanentemente o gerenciamento de DNS da distribuição):

resolvectl query google.com 2>/dev/null || nslookup google.com

Se realmente for uma falha do serviço de resolução, primeiro verifique a configuração atual e depois corrija conforme o método correspondente ao seu sistema. Não transforme diretamente o /etc/resolv.conf em um arquivo comum para uso a longo prazo, porque ele pode ser sobrescrito pelo netplan, pelo NetworkManager ou pelo systemd-resolved.

O Ubuntu Server costuma usar netplan junto com systemd-networkd; o desktop ou algumas imagens também podem usar NetworkManager. Primeiro confirme o status atual:

systemctl is-active systemd-networkd
systemctl is-active NetworkManager
networkctl status 2>/dev/null | head -n 30
ls -l /etc/netplan/

Verifique a configuração do netplan para confirmar que o nome da interface, o DHCP e a rota padrão não foram quebrados:

sudo sed -n '1,200p' /etc/netplan/*.yaml

Faça backup antes de modificar e use netplan try em vez de usar diretamente apply. O netplan try reverte automaticamente após um tempo limite de confirmação, o que é adequado para corrigir a rede remota via VNC:

sudo cp -a /etc/netplan /etc/netplan.backup-$(date +%F-%H%M)
sudo netplan try

Se confirmar que a configuração está correta, aplique-a e verifique a rota:

sudo netplan apply
ip -br address
ip route

Execute isto apenas quando confirmar que o sistema usa NetworkManager:

sudo systemctl enable --now NetworkManager
nmcli device status
nmcli connection show

Não force a habilitação do NetworkManager em uma imagem Ubuntu onde o systemd-networkd funciona normalmente; dois serviços assumindo a mesma interface ao mesmo tempo podem causar conflitos de rota e endereço.

Rocky Linux, AlmaLinux e CentOS mais recentes costumam gerenciar a rede com o NetworkManager. Primeiro verifique o serviço e as conexões:

systemctl status NetworkManager --no-pager
nmcli device status
nmcli connection show --active

Se o NetworkManager realmente não estiver em execução e o sistema não tiver outro serviço de rede assumindo a interface, você pode executar:

sudo systemctl enable --now NetworkManager
nmcli device connect eth0
ip -br address
ip route

Da mesma forma, substitua eth0 pelo nome real da interface. Se o serviço falhar ao iniciar, verifique primeiro os logs; não reinicie repetidamente:

sudo journalctl -u NetworkManager -b --no-pager -n 150

Concentre-se em verificar se a configuração de conexão contém IP estático, gateway, máscara de sub-rede incorretos ou rota padrão duplicada. O IP, o gateway e a máscara exibidos no console do RackNerd devem ser baseados nas informações da instância atual; não copie parâmetros de tutoriais de outras pessoas.

Se tanto o gateway quanto o IP público estão acessíveis mas o TCP 22 externo expira, verifique o firewall do host:

sudo ufw status verbose 2>/dev/null || true
sudo nft list ruleset
sudo iptables -S 2>/dev/null
sudo fail2ban-client status sshd 2>/dev/null || true

Confirme que a porta SSH está permitida nas regras atuais. Não execute comandos que limpem todas as regras apenas para "restaurar rápido". Se precisar liberar temporariamente o acesso, primeiro salve as regras existentes e restrinja o IP de origem. Se você perdeu a conectividade logo após habilitar o UFW, consulte a lista de recuperação para quando o SSH fica inacessível após habilitar o UFW.

Se apenas o seu próprio IP público estiver bloqueado, verifique a lista de bloqueios do Fail2Ban e desbloqueie um único endereço:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 你的公网IP

Não pense que o problema está resolvido depois de abrir o SSH permanentemente para o mundo todo. Após restaurar o acesso, você deve usar login por chave, restringir as origens de administração, desabilitar o login por senha e manter o VNC ou o Rescue Mode como último ponto de autorresgate.

Após restaurar a rede, continue confirmando o próprio serviço SSH:

sudo systemctl status ssh 2>/dev/null || sudo systemctl status sshd
sudo ss -lntp | grep -E ':(22|2222)'
sudo sshd -t

Somente quando sshd -t não tem saída é que a verificação de sintaxe passou. Se você modificou /etc/ssh/sshd_config, corrija primeiro a sintaxe e depois reinicie o serviço:

sudo systemctl restart ssh 2>/dev/null || sudo systemctl restart sshd
sudo journalctl -u ssh -u sshd -b --no-pager -n 100

Confirme se você alterou a porta para 2222 ou outra porta, e verifique de acordo o firewall da nuvem e o firewall do host. Quando o serviço escuta em 127.0.0.1 em vez de 0.0.0.0, as conexões externas também falham.

Se a interface, a rota, o firewall e o sshd estão todos normais mas o TCP 22 ainda expira:

1. No console do RackNerd, confirme que a instância não está suspensa, com pagamento atrasado ou acionando limites de tráfego;
2. Verifique se o IPv4 exibido no console mudou e se o DNS ainda aponta para o endereço antigo;
3. Use o VNC para verificar dmesg -T e os logs do sistema, confirmando que não há disco cheio, erro de kernel ou tarefa de inicialização com falha;
4. Use o Rescue Mode para montar o disco do sistema e corrigir o netplan, o sshd ou a configuração do firewall;
5. Mantenha no ticket o horário do teste, o IP de origem, o IP de destino, o Traceroute e os resultados do teste de portas, para facilitar ao provedor localizar problemas upstream.

As informações básicas de diagnóstico podem ser coletadas assim:

date -Is
ip -br address
ip route
ss -lntp
sudo journalctl -b --no-pager -p warning..alert | tail -n 100

Quando precisar tratar a fundo o Rescue Mode, o chroot e as verificações do sistema de arquivos, consulte Como usar o modo de resgate do VPS. Não execute fsck nem comandos de formatação sem saber qual é o dispositivo de disco.

Após confirmar que o SSH foi restaurado, faça imediatamente um endurecimento mínimo:

• Use um administrador normal + sudo, evitando o login direto com senha de root a longo prazo;
• Configure chaves SSH para o administrador e desabilite o login por senha somente após testar que uma nova sessão funciona;
• Mantenha um ponto de entrada VNC ou de resgate verificado e funcional;
• Registre as alterações de configuração do netplan / NetworkManager, do gateway e do firewall;
• Configure monitoramento de disco, memória, rede e status dos serviços, para que as falhas não sejam descobertas apenas pelos usuários.

Quando o VNC consegue entrar mas o SSH e o Ping falham, geralmente não é que "o servidor está completamente morto", mas sim que alguma camada do link de rede pública tem um problema. A ordem correta é: confirmar a interface e o IP público, depois verificar a rota padrão, em seguida distinguir DNS, firewall do host e sshd, e só por último considerar o upstream do provedor ou o Rescue Mode.

O ponto mais importante é não tratar o systemctl enable --now NetworkManager como um comando universal. Primeiro identifique a distribuição e o gerenciador de rede atual, depois use netplan try, nmcli, nftables ou os logs do systemd para reparos direcionados, de modo a reduzir o risco de uma segunda queda de rede.