Distinguir un fallo de arranque dun Pi sen pantalla dun fallo de rede

A tarxeta sae da caixa antes de que ninguén preguntase cal das catro cousas fallou realmente. O Pi deixou de responder tras un cambio de VPN ou de rede, e volver gravar parece o único movemento que queda. Raramente o é: o arrendamento pode moverse, sshd pode deterse, ou a resposta pode saír por unha ruta que non podes seguir, e cada unha desas ten a súa propia solución. O traballo útil é separar o que observaches do que supuxeches.

Catro resultados, non un

Arrancado, con enderezo, escoitando e accesible son catro resultados separados, e calquera deles pode fallar mentres os outros aínda se manteñen. Unha placa pode arrancar perfectamente e nunca aparecer na rede. Pode aparecer cun enderezo que ninguén esperaba, ou conservar o enderezo correcto con SSH desactivado. Pode acertar as tres cousas e seguir sendo inalcanzable porque as respostas saen pola pasarela equivocada.

O instinto de volver gravar reduce eses catro a unha soa pregunta, e por iso tantas veces produce un Pi que funciona e ningunha explicación do que se rompeu de verdade.

Onde rematan realmente as probas

Anota tres cousas antes de tocar nada: o enderezo e a ligazón ascendente que funcionaron por última vez, que se cambiou e a primeira operación que deixou de funcionar. Un nome de equipo que xa non resolve, unha conexión SSH que expira e unha conexión TCP que se rexeita son tres observacións distintas que apuntan a tres capas distintas. Un ping fallido comproba o alcance dun enderezo e falla por todos os motivos anteriores, incluída unha placa que nunca arrancou. Por iso non pode substituír unha proba de arranque.

Se hai unha pantalla local ou unha consola de recuperación dispoñible, úsaa, porque a pregunta que responde é se a máquina chega ao seu sistema operativo. Esa é a única pregunta que resolvería volver gravar. Se a placa falla antes desa etapa, segue a documentación de recuperación da plataforma en lugar de deducir un fallo de hardware dunha captura ausente, e deixa de desconectar a alimentación como diagnóstico.

Reconstruír a ruta de acceso nun sistema en marcha

Atopa a ligazón ascendente e o enderezo actuais a través de quen posúe a configuración de rede, e despois compárao coa lista actual de clientes do router e co enderezo que usou o cliente SSH. Un nome de equipo gardado ou un arrendamento DHCP antigo poden apuntar durante semanas ao destino de onte. Despois confirma que sshd está activado, escoitando nun enderezo que existe e permitido desde a rede de administración. As indicacións sobre SSH de Raspberry Pi tratan a activación do servidor e a conexión ao enderezo actual como dous pasos separados, e unha instalación nova de Raspberry Pi OS deixa SSH desactivado de forma predeterminada.

Un nome de equipo pode reapuntarse a outra máquina, e unha imaxe de substitución chega coa súa propia clave, así que comproba a pegada por unha ruta na que xa confías en lugar de pasar por riba do aviso cun clic. Borrar o aviso é como un cambio temporal de enderezo se converte nun problema de confianza permanente. Se o aviso da clave é o único síntoma, estás ante unha cuestión de identidade e non de alcance.

Segue a ruta da resposta antes de culpar a placa

Unha VPN pode cambiar a selección de rutas mentres a ligazón física segue asociada, e ese é exactamente o caso no que o Pi está acendido, escoitando e aínda así é inalcanzable. A petición chega e a resposta sae por un túnel que o cliente do administrador non pode atravesar. Unha consola local e un socket que escoita non demostran nada sobre o camiño de volta, así que confirma que interface transporta a resposta e que pasarela escolle. Compárao coa rede na que está realmente o administrador, porque este fallo se diagnostica erroneamente como unha placa morta máis que ningún outro.

A comprobación máis barata é ver saír a resposta: no Pi, pregunta que ruta transportaría o enderezo do administrador e compáraa coa interface pola que chegou a petición. Unha discrepancia aí explica todo o síntoma e custa un só comando.

Unha fronteira á vez, e cando é correcto volver gravar

Corrixe a configuración a través do seu propietario despois de conservar o estado actual. Substituír o xestor de rede, baleirar a devasa e adiviñar un enderezo estático son tres cambios que fan inútil a seguinte observación. Se as probas apuntan á ruta ou ao filtrado da VPN, volve á rutina propia de parada ou reparación dese cliente, traballando dentro do plan de recuperación acordado; unha comparación controlada é algo distinto de apagar a protección nun equipo que non explicaches.

Volver gravar é unha decisión de recuperación deliberada, tomada unha vez que entendes os datos, a identidade e a etapa que fallou. Non é o que debería desencadear por defecto un inicio de sesión ausente.

Garda o rexistro de configuración nun lugar lexible sen o Pi, e unha forma de volver entrar que non pase polo túnel que estás a piques de cambiar. Despois traballa en orde: confirma a etapa desde unha consola local, atopa o enderezo actual, revisa o oínte e a súa política, segue a ruta da resposta e cambia unha soa cousa. Se a placa nunca chegou ao sistema operativo, a documentación de recuperación é o seguinte paso, non a rede.