Distinguir uma falha de arranque de um Pi sem ecrã de uma falha de rede

O cartão sai da caixa antes de alguém ter perguntado qual das quatro coisas falhou realmente. O Pi deixou de responder após uma alteração de VPN ou de rede, e voltar a gravar parece o único movimento que resta. Raramente é: a concessão pode mudar de sítio, o sshd pode parar, ou a resposta pode sair por uma rota que não consegue seguir, e cada uma dessas tem a sua própria correção. O trabalho útil é separar o que observou do que assumiu.

Quatro resultados, não um

Arrancado, com endereço, à escuta e alcançável são quatro resultados distintos, e qualquer um deles pode falhar enquanto os outros ainda se mantêm. Uma placa pode arrancar perfeitamente e nunca aparecer na rede. Pode aparecer com um endereço que ninguém esperava, ou manter o endereço correto com o SSH desativado. Pode acertar nos três e continuar inalcançável porque as respostas saem pelo gateway errado.

O instinto de voltar a gravar reduz esses quatro a uma única pergunta, e é por isso que tantas vezes produz um Pi funcional e nenhuma explicação do que se partiu de facto.

Onde as provas realmente terminam

Anote três coisas antes de tocar em qualquer coisa: o endereço e o uplink que funcionaram pela última vez, o que foi alterado e a primeira operação que deixou de funcionar. Um nome de anfitrião que já não resolve, uma ligação SSH que expira e uma ligação TCP que é recusada são três observações diferentes que apontam para três camadas diferentes. Um ping falhado testa o alcance de um endereço e falha por todas as razões acima, incluindo uma placa que nunca arrancou. É por isso que não pode substituir um teste de arranque.

Se houver um ecrã local ou uma consola de recuperação disponível, use-a, porque a pergunta a que responde é se a máquina chega ao seu sistema operativo. Essa é a única pergunta que voltar a gravar resolveria. Se a placa falhar antes dessa fase, siga a documentação de recuperação da plataforma em vez de deduzir uma falha de hardware de uma captura ausente, e deixe de desligar a alimentação como diagnóstico.

Reconstruir o caminho de acesso num sistema em funcionamento

Encontre o uplink e o endereço atuais através de quem possui a configuração de rede, e compare isso com a lista atual de clientes do router e com o endereço que o cliente SSH usou. Um nome de anfitrião guardado ou uma concessão DHCP antiga podem apontar durante semanas para o destino de ontem. Depois confirme que o sshd está ativo, à escuta num endereço que existe e autorizado a partir da rede de administração. As indicações sobre SSH do Raspberry Pi tratam a ativação do servidor e a ligação ao endereço atual como dois passos separados, e uma instalação nova do Raspberry Pi OS deixa o SSH desativado por predefinição.

Um nome de anfitrião pode ser reapontado para outra máquina, e uma imagem de substituição chega com a sua própria chave, por isso verifique a impressão digital por um caminho em que já confia em vez de clicar para ultrapassar o aviso. Apagar o aviso é a forma como uma mudança temporária de endereço se torna um problema de confiança permanente. Se o pedido da chave for o único sintoma, está perante uma questão de identidade e não de alcance.

Seguir a rota da resposta antes de culpar a placa

Uma VPN pode mudar a seleção de rotas enquanto a ligação física permanece associada, e é exatamente o caso em que o Pi está ligado, à escuta e continua inalcançável. O pedido chega e a resposta sai por um túnel que o cliente do administrador não consegue atravessar. Uma consola local e um socket à escuta não provam nada sobre o caminho de volta, por isso confirme qual interface transporta a resposta e qual gateway escolhe. Compare isso com a rede em que o administrador está de facto, porque esta falha é diagnosticada erradamente como placa morta mais do que qualquer outra.

A verificação mais barata é ver a resposta sair: no Pi, pergunte qual rota transportaria o endereço do administrador e compare-a com a interface por onde o pedido chegou. Uma discrepância aí explica todo o sintoma e custa um único comando.

Uma fronteira de cada vez, e quando voltar a gravar é correto

Corrija a configuração através do seu proprietário depois de preservar o estado atual. Substituir o gestor de rede, esvaziar a firewall e adivinhar um endereço estático são três alterações que tornam inútil a observação seguinte. Se as provas apontarem para a rota ou a filtragem da VPN, volte à rotina de paragem ou reparação desse cliente, trabalhando dentro do plano de recuperação acordado; uma comparação controlada é algo diferente de desligar a proteção num anfitrião que não explicou.

Voltar a gravar é uma decisão de recuperação deliberada, tomada depois de compreender os dados, a identidade e a fase que falhou. Não é o que uma sessão ausente deve desencadear por predefinição.

Guarde o registo de configuração num local legível sem o Pi, e uma forma de voltar a entrar que não passe pelo túnel que está prestes a alterar. Depois trabalhe por ordem: confirme a fase a partir de uma consola local, encontre o endereço atual, verifique o ouvinte e a sua política, siga a rota da resposta e altere uma só coisa. Se a placa nunca chegou ao sistema operativo, a documentação de recuperação é o passo seguinte e não a rede.