Com distingir un error d'arrencada d'un Pi sense pantalla d'un error de xarxa

La targeta surt del carcassa abans que ningú hagi preguntat quina de les quatre coses ha fallat realment. El Pi ha deixat de respondre després d'un canvi de VPN o de xarxa, i tornar a gravar sembla l'únic moviment que queda. Poques vegades ho és: el contracte d'arrendament pot moure's, l'sshd pot aturar-se, o la resposta pot sortir per una ruta que no podeu seguir, i cadascuna d'aquestes té la seva solució. La feina útil és separar el que heu observat del que heu suposat.

Quatre resultats, no un

Arrencat, adreçat, escoltant i accessible són quatre resultats separats, i qualsevol d'ells pot fallar mentre els altres encara es mantenen. Una placa pot arrencar perfectament i no aparèixer mai a la xarxa. Pot aparèixer amb una adreça que ningú esperava, o mantenir l'adreça correcta amb l'SSH desactivat. Pot encertar les tres coses i continuar sent inabastable perquè les respostes surten per la porta d'enllaç equivocada.

L'instint de tornar a gravar ajunta aquests quatre en una sola pregunta, i per això tantes vegades produeix un Pi que funciona i cap explicació del que s'ha trencat de veritat.

On acaben realment les proves

Anoteu tres coses abans de tocar res: l'adreça i l'enllaç ascendent que van funcionar per últim cop, què es va canviar i la primera operació que va deixar de funcionar. Un nom d'amfitrió que ja no es resol, una connexió SSH que expira i una connexió TCP que es rebutja són tres observacions diferents que apunten a tres capes diferents. Un ping fallit comprova l'abast d'una adreça i falla per tots els motius anteriors, inclosa una placa que mai no va arrencar. Per això no pot substituir una prova d'arrencada.

Si teniu una pantalla local o una consola de recuperació, feu-la servir, perquè la pregunta que respon és si la màquina arriba al seu sistema operatiu. Aquesta és l'única pregunta que resoldria tornar a gravar. Si la placa falla abans d'aquesta etapa, seguiu la documentació de recuperació de la plataforma en lloc de deduir una fallada de maquinari a partir d'una captura absent, i deixeu de desendollar l'alimentació com a diagnòstic.

Reconstruïu el camí d'accés en un sistema en marxa

Trobeu l'enllaç ascendent i l'adreça actuals a través de qui posseeix la configuració de xarxa, i compareu-ho amb la llista actual de clients del router i amb l'adreça que va fer servir el client SSH. Un nom d'amfitrió desat o un arrendament DHCP antic poden apuntar durant setmanes a la destinació d'ahir. Després confirmeu que l'sshd està activat, que escolta en una adreça existent i que està permès des de la xarxa d'administració. Les indicacions sobre SSH del Raspberry Pi tracten l'activació del servidor i la connexió a l'adreça actual com dues passes separades, i una instal·lació nova de Raspberry Pi OS deixa l'SSH desactivat per defecte.

Un nom d'amfitrió es pot redirigir a una altra màquina, i la imatge de substitució arriba amb la seva pròpia clau, així que comproveu l'empremta per un camí en què ja confieu en lloc de fer clic per superar l'avís. Esborrar l'avís és com un canvi temporal d'adreça es converteix en un problema de confiança permanent. Si l'avís de la clau és l'únic símptoma, esteu davant d'una qüestió d'identitat i no d'abast.

Resseguiu la ruta de la resposta abans de culpar la placa

Una VPN pot canviar la selecció de rutes mentre l'enllaç físic continua associat, i aquest és exactament el cas en què el Pi està engegat, escolta i continua sent inabastable. La petició arriba i la resposta surt per un túnel que el client de l'administrador no pot travessar. Una consola local i un sòcol que escolta no proven res sobre el camí de tornada, així que confirmeu quina interfície porta la resposta i quina porta d'enllaç tria. Compareu-ho amb la xarxa on és realment l'administrador, perquè aquesta fallada es diagnostica erròniament com una placa morta més que cap altra.

La comprovació més barata és veure com surt la resposta: al Pi, pregunteu quina ruta portaria l'adreça de l'administrador i compareu-la amb la interfície per on ha arribat la petició. Una discrepància aquí explica tot el símptoma i costa una ordre.

Una frontera alhora, i quan tornar a gravar és correcte

Corregiu la configuració a través del seu propietari després de conservar l'estat actual. Substituir el gestor de xarxa, buidar el tallafoc i endevinar una adreça estàtica són tres canvis que fan inútil la propera observació. Si les proves apunten a la ruta o al filtratge de la VPN, torneu a la rutina pròpia d'aturada o reparació d'aquell client, treballant dins del pla de recuperació acordat; una comparació controlada és una cosa diferent d'apagar la protecció en un amfitrió que no heu explicat.

Tornar a gravar és una decisió de recuperació deliberada, presa un cop enteneu les dades, la identitat i l'etapa que ha fallat. No és el que hauria de desencadenar per defecte un inici de sessió que falta.

Guardeu el registre de configuració en un lloc llegible sense el Pi, i una manera de tornar-hi que no passi pel túnel que esteu a punt de canviar. Després treballeu en ordre: confirmeu l'etapa des d'una consola local, trobeu l'adreça actual, comproveu l'oient i la seva política, resseguiu la ruta de la resposta i canvieu una cosa. Si la placa no va arribar mai al sistema operatiu, la documentació de recuperació és el pas següent, no la xarxa.