Distinguir un fallo de arranque de un Pi sin pantalla de un fallo de red

La tarjeta sale del soporte antes de que nadie haya preguntado cuál de las cuatro cosas falló realmente. El Pi dejó de responder tras un cambio de VPN o de red, y volver a grabar parece el único movimiento que queda. Rara vez lo es: el alquiler puede moverse, sshd puede detenerse, o la respuesta puede salir por una ruta que no puedes seguir, y cada una de esas cosas tiene su propia solución. El trabajo útil es separar lo que observaste de lo que supusiste.

Cuatro resultados, no uno

Arrancado, con dirección, escuchando y accesible son cuatro resultados separados, y cualquiera de ellos puede fallar mientras los otros todavía se sostienen. Una placa puede arrancar a la perfección y no aparecer nunca en la red. Puede aparecer con una dirección que nadie esperaba, o conservar la dirección correcta con SSH desactivado. Puede acertar las tres y seguir siendo inalcanzable porque las respuestas salen por la puerta de enlace equivocada.

El instinto de volver a grabar reduce esos cuatro a una sola pregunta, y por eso tantas veces produce un Pi que funciona y ninguna explicación de qué se rompió en realidad.

Dónde acaban realmente las pruebas

Apunta tres cosas antes de tocar nada: la dirección y el enlace ascendente que funcionaron por última vez, qué se cambió y la primera operación que dejó de funcionar. Un nombre de equipo que ya no resuelve, una conexión SSH que expira y una conexión TCP que se rechaza son tres observaciones distintas que apuntan a tres capas distintas. Un ping fallido comprueba el alcance de una dirección y falla por todos los motivos anteriores, incluida una placa que nunca arrancó. Por eso no puede sustituir a una prueba de arranque.

Si hay una pantalla local o una consola de recuperación disponible, úsala, porque la pregunta que responde es si la máquina llega a su sistema operativo. Esa es la única pregunta que resolvería volver a grabar. Si la placa falla antes de esa etapa, sigue la documentación de recuperación de la plataforma en lugar de deducir un fallo de hardware de una captura ausente, y deja de desconectar la alimentación como diagnóstico.

Reconstruye la ruta de acceso en un sistema en marcha

Encuentra el enlace ascendente y la dirección actuales a través de quien posee la configuración de red, y luego compáralo con la lista actual de clientes del router y con la dirección que usó el cliente SSH. Un nombre de equipo guardado o un alquiler DHCP antiguo pueden apuntar durante semanas al destino de ayer. Después confirma que sshd está activado, escuchando en una dirección que existe y permitido desde la red de administración. Las indicaciones sobre SSH de Raspberry Pi tratan la activación del servidor y la conexión a la dirección actual como dos pasos separados, y una instalación nueva de Raspberry Pi OS deja SSH desactivado de forma predeterminada.

Un nombre de equipo puede reapuntarse a otra máquina, y una imagen de sustitución llega con su propia clave, así que comprueba la huella por una ruta en la que ya confías en lugar de pasar de largo el aviso con un clic. Borrar el aviso es como un cambio temporal de dirección se convierte en un problema de confianza permanente. Si el aviso de la clave es el único síntoma, estás ante una cuestión de identidad y no de alcance.

Sigue la ruta de la respuesta antes de culpar a la placa

Una VPN puede cambiar la selección de rutas mientras el enlace físico sigue asociado, y ese es exactamente el caso en el que el Pi está encendido, escuchando y aun así es inalcanzable. La petición llega y la respuesta sale por un túnel que el cliente del administrador no puede atravesar. Una consola local y un socket que escucha no demuestran nada sobre el camino de vuelta, así que confirma qué interfaz transporta la respuesta y qué puerta de enlace elige. Compáralo con la red en la que está realmente el administrador, porque este fallo se diagnostica erróneamente como una placa muerta más que ningún otro.

La comprobación más barata es ver salir la respuesta: en el Pi, pregunta qué ruta transportaría la dirección del administrador y compárala con la interfaz por la que llegó la petición. Una discrepancia ahí explica todo el síntoma y cuesta un solo comando.

Una frontera a la vez, y cuándo es correcto volver a grabar

Corrige la configuración a través de su propietario después de conservar el estado actual. Sustituir el gestor de red, vaciar el cortafuegos y adivinar una dirección estática son tres cambios que hacen inútil la siguiente observación. Si las pruebas apuntan a la ruta o al filtrado de la VPN, vuelve a la rutina propia de parada o reparación de ese cliente, trabajando dentro del plan de recuperación acordado; una comparación controlada es algo distinto de apagar la protección en un equipo que no has explicado.

Volver a grabar es una decisión de recuperación deliberada, tomada una vez que entiendes los datos, la identidad y la etapa que falló. No es lo que debería desencadenar por defecto un inicio de sesión ausente.

Guarda el registro de configuración en un lugar legible sin el Pi, y una forma de volver a entrar que no pase por el túnel que estás a punto de cambiar. Luego trabaja en orden: confirma la etapa desde una consola local, encuentra la dirección actual, revisa el oyente y su política, sigue la ruta de la respuesta y cambia una sola cosa. Si la placa nunca llegó al sistema operativo, la documentación de recuperación es el siguiente paso, no la red.