RackNerd VPS sin conexión de red: qué hacer (2026): diagnóstico y reparación de fallos de SSH y Ping cuando VNC funciona

En tu computadora local, primero realiza tres comprobaciones:

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

Un Ping fallido por sí solo no puede probar que el servidor esté sin conexión; muchos VPS filtran ICMP. Lo que realmente es diagnóstico es el puerto TCP 22:

Si la misma máquina funcionaba antes y acabas de cambiar UFW, iptables, NetworkManager o netplan, prioriza revertir y revisar desde el cambio más reciente.

Inicia sesión en el VNC o Web Console de la consola del proveedor y primero revisa el kernel y las interfaces de red:

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

Normalmente, la interfaz de red principal (nombres comunes eth0, ens3 o enp1s0) debería estar en UP y tener una IPv4 pública asignada por el proveedor. La ruta predeterminada suele verse así:

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

Los siguientes resultados significan, respectivamente:

• La interfaz está en DOWN: la interfaz no está habilitada, o el servicio de gestión de red no la ha tomado;
• La interfaz está en UP pero no tiene dirección inet: hay un problema en DHCP, configuración estática o configuración de cloud-init;
• Tiene IP pero no tiene ruta default: solo puede acceder a la misma subred y no puede acceder a internet;
• IP y ruta están normales pero los nombres de dominio fallan: sigue revisando DNS, no reinicies repetidamente la interfaz.

Después de confirmar el nombre de la interfaz física, ejecuta:

ip link set dev eth0 up

Reemplaza eth0 con el nombre real que muestra ip -br link. Este comando solo habilita la interfaz; no adivinará la IP y la puerta de enlace por ti.

No ejecutes solo ping google.com. Probar en el siguiente orden localiza rápidamente en qué capa está el fallo:

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

• La puerta de enlace predeterminada no responde a Ping: primero repara la interfaz, IP, ruta o la red del lado del proveedor;
• Puerta de enlace accesible, 1.1.1.1 inaccesible: revisa la ruta predeterminada, la política de salida y el estado de red del proveedor del VPS;
• 1.1.1.1 accesible, los nombres de dominio fallan: revisa /etc/resolv.conf, systemd-resolved o las reglas de firewall de DNS;
• Todo normal pero SSH falla: el fallo se ha reducido a sshd, el firewall del puerto 22 o Fail2Ban.

Prueba temporal de DNS (solo para diagnóstico; no se recomienda sobrescribir permanentemente la gestión de DNS de la distribución):

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

Si realmente es un fallo del servicio de resolución, primero revisa la configuración actual y luego repárala según el método correspondiente a tu sistema. No conviertas directamente /etc/resolv.conf en un archivo normal para usarlo a largo plazo, porque puede ser sobrescrito por netplan, NetworkManager o systemd-resolved.

Ubuntu Server suele usar netplan junto con systemd-networkd; el escritorio o algunas imágenes también pueden usar NetworkManager. Primero confirma el estado actual:

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

Revisa la configuración de netplan para confirmar que el nombre de la interfaz, DHCP y la ruta predeterminada no se hayan roto:

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

Haz una copia de seguridad antes de modificar y usa netplan try en lugar de usar directamente apply. netplan try revierte automáticamente tras un tiempo de espera de confirmación, lo cual es adecuado para reparar la red remota mediante VNC:

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

Si confirmas que la configuración es correcta, aplícala y revisa la ruta:

sudo netplan apply
ip -br address
ip route

Ejecuta esto solo cuando confirmes que el sistema usa NetworkManager:

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

No fuerces la habilitación de NetworkManager en una imagen de Ubuntu donde systemd-networkd funciona normalmente; dos servicios tomando la misma interfaz al mismo tiempo pueden causar conflictos de ruta y dirección.

Rocky Linux, AlmaLinux y CentOS más recientes suelen gestionar la red con NetworkManager. Primero revisa el servicio y las conexiones:

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

Si NetworkManager efectivamente no está en ejecución y el sistema no tiene otro servicio de red tomando la interfaz, puedes ejecutar:

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

Igualmente, reemplaza eth0 con el nombre real de la interfaz. Si el servicio no arranca, revisa primero los registros; no reinicies repetidamente:

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

Céntrate en revisar si la configuración de conexión contiene una IP estática, puerta de enlace, máscara de subred incorrectas o una ruta predeterminada duplicada. La IP, la puerta de enlace y la máscara mostradas en la consola de RackNerd deben basarse en la información de la instancia actual; no copies parámetros de tutoriales de otros.

Si tanto la puerta de enlace como la IP pública son accesibles pero el TCP 22 externo se agota, revisa el firewall del 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

Confirma que el puerto SSH está permitido en las reglas actuales. No ejecutes comandos que borren todas las reglas solo para "restaurar rápido". Si debes permitir temporalmente el acceso, primero guarda las reglas existentes y restringe la IP de origen. Si perdiste la conectividad justo después de habilitar UFW, consulta la lista de recuperación para cuando SSH no es accesible tras habilitar UFW.

Si solo tu propia IP pública está bloqueada, revisa la lista de bloqueos de Fail2Ban y desbloquea una sola dirección:

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

No creas que el problema está resuelto después de abrir SSH permanentemente a todo el mundo. Después de restaurar el acceso, debes usar inicio de sesión con clave, restringir las fuentes de administración, deshabilitar el inicio de sesión con contraseña y mantener VNC o Rescue Mode como último punto de autorrescate.

Después de restaurar la red, continúa confirmando el servicio SSH en sí:

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

Solo cuando sshd -t no tiene salida significa que la comprobación de sintaxis pasó. Si modificaste /etc/ssh/sshd_config, corrige primero la sintaxis y luego reinicia el servicio:

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

Confirma si cambiaste el puerto a 2222 u otro puerto, y revisa en consecuencia el firewall de la nube y el firewall del host. Cuando el servicio escucha en 127.0.0.1 en lugar de 0.0.0.0, las conexiones externas también fallan.

Si la interfaz, la ruta, el firewall y sshd están todos normales pero el TCP 22 sigue agotándose:

1. En la consola de RackNerd, confirma que la instancia no esté suspendida, con pago vencido o activando límites de tráfico;
2. Revisa si la IPv4 mostrada en la consola ha cambiado y si el DNS sigue apuntando a la dirección antigua;
3. Usa VNC para revisar dmesg -T y los registros del sistema, confirmando que no haya disco lleno, errores del kernel o tareas de arranque fallidas;
4. Usa Rescue Mode para montar el disco del sistema y reparar netplan, sshd o la configuración del firewall;
5. Conserva en el ticket la hora de la prueba, la IP de origen, la IP de destino, el Traceroute y los resultados de la prueba de puertos, para facilitar al proveedor localizar problemas ascendentes.

La información de diagnóstico básica se puede recopilar así:

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

Cuando necesites tratar en profundidad Rescue Mode, chroot y comprobaciones del sistema de archivos, consulta Cómo usar el modo de rescate de VPS. No ejecutes fsck ni comandos de formateo sin conocer el dispositivo de disco.

Después de confirmar que SSH está restaurado, realiza de inmediato un endurecimiento mínimo:

• Usa un administrador normal + sudo, evitando el inicio de sesión directo con contraseña de root a largo plazo;
• Configura claves SSH para el administrador y deshabilita el inicio de sesión con contraseña solo después de probar que una nueva sesión funciona;
• Mantén un punto de entrada VNC o de rescate verificado y funcional;
• Registra los cambios de configuración de netplan / NetworkManager, puerta de enlace y firewall;
• Configura monitoreo de disco, memoria, red y estado de servicios, para que los fallos no solo los descubran los usuarios.

Cuando VNC puede iniciar sesión pero SSH y Ping fallan, generalmente no es que "el servidor esté completamente muerto", sino que alguna capa del enlace de red pública tiene un problema. El orden correcto es: confirmar la interfaz y la IP pública, luego revisar la ruta predeterminada, después distinguir DNS, firewall del host y sshd, y solo al final considerar el upstream del proveedor o Rescue Mode.

El punto más importante es no tratar systemctl enable --now NetworkManager como un comando universal. Primero identifica la distribución y el gestor de red actual, luego usa netplan try, nmcli, nftables o los registros de systemd para reparaciones específicas, de modo que se reduzca el riesgo de una segunda caída de red.