Distinguer une panne de démarrage d'un Pi sans écran d'une panne réseau

La carte sort du boîtier avant que quiconque ait demandé laquelle des quatre choses a réellement échoué. Le Pi a cessé de répondre après un changement de VPN ou de réseau, et un reflash semble le seul geste qui reste. Il l'est rarement : le bail peut se déplacer, sshd peut s'arrêter, ou la réponse peut partir par une route que vous ne pouvez pas suivre, et chacune de ces causes a son propre correctif. Le travail utile consiste à séparer ce que vous avez observé de ce que vous avez supposé.

Quatre résultats, pas un

Démarré, adressé, à l'écoute et joignable sont quatre résultats distincts, et n'importe lequel peut échouer alors que les autres tiennent encore. Une carte peut démarrer parfaitement et ne jamais apparaître sur le réseau. Elle peut apparaître avec une adresse que personne n'attendait, ou conserver la bonne adresse avec SSH désactivé. Elle peut réussir les trois et rester injoignable parce que les réponses sortent par la mauvaise passerelle.

Le réflexe du reflash ramène ces quatre à une seule question, et c'est pourquoi il produit si souvent un Pi qui fonctionne sans aucune explication de ce qui a réellement cassé.

Où les preuves s'arrêtent réellement

Notez trois choses avant de toucher à quoi que ce soit : l'adresse et le lien montant qui fonctionnaient en dernier, ce qui a été modifié, et la première opération qui a cessé de fonctionner. Un nom d'hôte qui ne se résout plus, une connexion SSH qui expire et une connexion TCP qui est refusée sont trois observations différentes qui pointent vers trois couches différentes. Un ping échoué teste la joignabilité d'une adresse et échoue pour toutes les raisons ci-dessus, y compris une carte qui n'a jamais démarré. C'est pourquoi il ne peut pas remplacer un test de démarrage.

Si un écran local ou une console de récupération est disponible, utilisez-le, car la question à laquelle il répond est de savoir si la machine atteint son système d'exploitation. C'est la seule question qu'un reflash résoudrait. Si la carte échoue avant ce stade, suivez la documentation de récupération de la plateforme au lieu de déduire une panne matérielle d'une capture absente, et cessez de couper l'alimentation comme diagnostic.

Reconstruire le chemin d'accès sur un système en marche

Trouvez le lien montant et l'adresse actuels par l'intermédiaire de ce qui possède la configuration réseau, puis comparez cela à la liste actuelle des clients du routeur et à l'adresse qu'a utilisée le client SSH. Un nom d'hôte enregistré ou un ancien bail DHCP peuvent pointer pendant des semaines vers la destination d'hier. Confirmez ensuite que sshd est activé, qu'il écoute sur une adresse qui existe et qu'il est autorisé depuis le réseau d'administration. Les recommandations SSH de Raspberry Pi traitent l'activation du serveur et la connexion à l'adresse actuelle comme deux étapes distinctes, et une installation fraîche de Raspberry Pi OS laisse SSH désactivé par défaut.

Un nom d'hôte peut être repointé vers une autre machine, et une image de remplacement arrive avec sa propre clé, alors vérifiez l'empreinte par un chemin auquel vous faites déjà confiance au lieu de cliquer au-delà de l'avertissement. Effacer l'avertissement est la façon dont un changement d'adresse temporaire devient un problème de confiance permanent. Si l'invite de clé est le seul symptôme, vous êtes face à une question d'identité et non de joignabilité.

Remonter la route de la réponse avant d'accuser la carte

Un VPN peut changer la sélection de route alors que le lien physique reste associé, et c'est exactement le cas où le Pi est allumé, à l'écoute et pourtant injoignable. La requête arrive et la réponse sort par un tunnel que le client de l'administrateur ne peut pas traverser. Une console locale et une socket à l'écoute ne prouvent rien sur le chemin de retour, alors confirmez quelle interface porte la réponse et quelle passerelle elle choisit. Comparez cela avec le réseau sur lequel se trouve réellement l'administrateur, car cette panne est plus souvent que toute autre diagnostiquée à tort comme une carte morte.

Le contrôle le moins coûteux est de regarder la réponse partir : sur le Pi, demandez quelle route porterait l'adresse de l'administrateur et comparez-la avec l'interface par laquelle la requête est arrivée. Une divergence ici explique tout le symptôme et coûte une seule commande.

Une frontière à la fois, et quand reflasher est juste

Corrigez la configuration par l'intermédiaire de son propriétaire après avoir conservé l'état actuel. Remplacer le gestionnaire de réseau, vider le pare-feu et deviner une adresse statique sont trois changements qui rendent la prochaine observation inutile. Si les preuves pointent vers la route ou le filtrage du VPN, revenez à la routine d'arrêt ou de réparation propre à ce client, en travaillant dans le plan de récupération convenu ; une comparaison contrôlée est autre chose que couper la protection sur un hôte que vous n'avez pas expliqué.

Reflasher est un choix de récupération délibéré, pris une fois que vous comprenez les données, l'identité et l'étape qui a échoué. Ce n'est pas ce qu'une connexion absente devrait déclencher par défaut.

Conservez l'enregistrement de configuration dans un endroit lisible sans le Pi, et un moyen de revenir qui ne passe pas par le tunnel que vous allez changer. Travaillez ensuite dans l'ordre : confirmez l'étape depuis une console locale, trouvez l'adresse actuelle, vérifiez l'écouteur et sa politique, remontez la route de la réponse, et changez une seule chose. Si la carte n'a jamais atteint le système d'exploitation, la documentation de récupération est l'étape suivante, pas le réseau.