Megkülönböztetni a fejetlen Pi indítási hibáját a hálózati hibától

A kártya kikerül a tokból, mielőtt bárki megkérdezné, melyik a négy dolog közül az, amelyik valóban meghibásodott. A Pi egy VPN- vagy hálózati változás után abbahagyta a válaszadást, és az újraflashelés tűnik az egyetlen hátralévő lépésnek. Ritkán az: a bérlet elmozdulhat, az sshd leállhat, vagy a válasz olyan útvonalon távozhat, amelyet nem tudsz követni, és mindegyiknek megvan a maga javítása. A hasznos munka az, hogy elválaszd azt, amit megfigyeltél, attól, amit feltételeztél.

Négy eredmény, nem egy

Elindult, címet kapott, figyel és elérhető – ez négy különálló eredmény, és bármelyikük meghiúsulhat, miközben a többi még áll. Egy lap tökéletesen elindulhat, és soha nem jelenik meg a hálózaton. Megjelenhet olyan címmel, amelyre senki nem számított, vagy megtarthatja a helyes címet kikapcsolt SSH-val. Mindhármat jól csinálhatja, és mégis elérhetetlen lehet, mert a válaszok a rossz átjárón keresztül távoznak.

Az újraflashelés ösztöne egyetlen kérdésbe sűríti ezt a négyet, és ezért olyan gyakran ad működő Pi-t, és semmilyen magyarázatot arra, mi is tört el valójában.

Hol végződnek valójában a bizonyítékok

Írj fel három dolgot, mielőtt bármihez nyúlsz: a címet és a felső kapcsolatot, amelyek utoljára működtek, hogy mi változott, és az első műveletet, amely leállt. Egy hosztnév, amely már nem oldódik fel, egy SSH-kapcsolat, amely lejár, és egy TCP-kapcsolat, amelyet elutasítanak, három különböző megfigyelés, amelyek három különböző rétegre mutatnak. Egy sikertelen ping egyetlen cím elérhetőségét teszteli, és a fenti okok mindegyike miatt meghiúsul, beleértve azt a lapot is, amely soha nem indult el. Ezért nem helyettesítheti az indítási tesztet.

Ha van helyi kijelző vagy helyreállítási konzol, használd, mert az a kérdés, amelyre válaszol, hogy a gép eléri-e a saját operációs rendszerét. Ez az egyetlen kérdés, amelyet az újraflashelés megoldana. Ha a lap e szakasz előtt hibázik, kövesd a platform helyreállítási dokumentációját, ahelyett hogy egy hiányzó képernyőképről hardverhibára következtetnél, és hagyd abba a tápellátás diagnosztikai célú kihúzását.

Építsd újra a hozzáférési útvonalat egy futó rendszeren

Keresd meg az aktuális felső kapcsolatot és címet azon keresztül, aki a hálózati konfigurációt birtokolja, majd hasonlítsd össze a router jelenlegi ügyféllistájával és azzal a címmel, amelyet az SSH-ügyfél használt. Egy mentett hosztnév vagy egy régi DHCP-bérlet hetekig a tegnapi célra mutathat. Ezután erősítsd meg, hogy az sshd engedélyezve van, létező címen figyel, és az adminisztrációs hálózatból engedélyezett. A Raspberry Pi SSH-útmutatója a kiszolgáló engedélyezését és az aktuális címhez való csatlakozást két külön lépésként kezeli, és egy friss Raspberry Pi OS telepítés alapértelmezés szerint kikapcsolva hagyja az SSH-t.

Egy hosztnév átirányítható egy másik gépre, és egy cserelemez a saját kulcsával érkezik, ezért ellenőrizd az ujjlenyomatot egy olyan útvonalon, amelyben már megbízol, ahelyett hogy átkattintanál a figyelmeztetésen. A figyelmeztetés törlése az az út, amelyen egy ideiglenes címváltozás állandó bizalmi problémává válik. Ha csak a kulcskérdés a tünet, akkor identitáskérdéssel nézel szembe, nem elérhetőségivel.

Kövesd a válasz útvonalát, mielőtt a lapot hibáztatod

A VPN megváltoztathatja az útvonalválasztást, miközben a fizikai kapcsolat társítva marad, és pontosan ez az az eset, amikor a Pi fut, figyel, és mégis elérhetetlen. A kérés megérkezik, és a válasz egy olyan alagúton távozik, amelyen az adminisztrátor ügyfele nem tud átjutni. Egy helyi konzol és egy figyelő socket semmit nem bizonyít a visszaútról, ezért erősítsd meg, melyik interfész viszi a választ, és melyik átjárót választja. Hasonlítsd össze azzal a hálózattal, amelyen az adminisztrátor valójában van, mert ezt a hibát a többihez képest gyakrabban diagnosztizálják tévesen halott lapként.

A legolcsóbb ellenőrzés a válasz távozását figyelni: kérdezd meg a Pi-n, melyik útvonal vinné az adminisztrátor címét, és hasonlítsd össze azzal az interfésszel, amelyen a kérés érkezett. Az ottani eltérés az egész tünetet megmagyarázza, és egyetlen parancsba kerül.

Egy határ egyszerre, és mikor helyes az újraflashelés

Javítsd a konfigurációt a tulajdonosán keresztül, miután megőrizted a jelenlegi állapotot. A hálózatkezelő lecserélése, a tűzfal kiürítése és egy statikus cím kitalálása három olyan változtatás, amely hasznavehetetlenné teszi a következő megfigyelést. Ha a bizonyítékok a VPN útvonalára vagy szűrésére mutatnak, térj vissza annak az ügyfélnek a saját leállítási vagy javítási rutinjához, a megbeszélt helyreállítási terven belül dolgozva; az ellenőrzött összehasonlítás más, mint a védelem kikapcsolása egy olyan hoszton, amelyet nem magyaráztál meg.

Az újraflashelés tudatos helyreállítási döntés, amelyet akkor hozunk, amikor értjük az adatokat, az identitást és a meghibásodott szakaszt. Nem ez az, amit egy hiányzó bejelentkezésnek alapértelmezés szerint kiváltania kellene.

Tartsd a konfigurációs nyilvántartást a Pi nélkül is olvasható helyen, és egy olyan visszautat, amely nem a módosítani kívánt alagúton keresztül vezet. Aztán dolgozz sorrendben: erősítsd meg a szakaszt egy helyi konzolról, keresd meg az aktuális címet, ellenőrizd a figyelőt és a szabályzatát, kövesd a válasz útvonalát, és változtass egy dolgot. Ha a lap soha nem érte el az operációs rendszert, a következő lépés a helyreállítási dokumentáció, nem a hálózat.