Å skille en oppstartsfeil på en hodeløs Pi fra en nettverksfeil

Kortet kommer ut av kabinettet før noen har spurt hvilken av de fire tingene som faktisk sviktet. Pi-en sluttet å svare etter en VPN- eller nettverksendring, og en ny flashing føles som det eneste trekket som er igjen. Det er det sjelden: leasen kan flytte seg, sshd kan stoppe, eller svaret kan gå ut over en rute du ikke kan følge, og hver av disse har sin egen løsning. Det nyttige arbeidet er å skille det du observerte fra det du antok.

Fire resultater, ikke ett

Startet, adressert, lyttende og tilgjengelig er fire separate utfall, og hvilket som helst av dem kan svikte mens de andre fortsatt holder. Et kort kan starte perfekt og aldri dukke opp på nettverket. Det kan dukke opp med en adresse ingen forventet, eller holde den riktige adressen med SSH slått av. Det kan få alle tre riktig og likevel være utilgjengelig fordi svar går ut gjennom feil gateway.

Flashing-instinktet samler de fire til ett spørsmål, og derfor gir det så ofte en fungerende Pi og ingen forklaring på hva som faktisk gikk i stykker.

Hvor bevisene faktisk slutter

Skriv ned tre ting før du rører noe: adressen og oppkoblingen som sist virket, hva som ble endret, og den første operasjonen som sluttet å virke. Et vertsnavn som ikke lenger slår opp, en SSH-forbindelse som timer ut, og en TCP-forbindelse som avvises er tre forskjellige observasjoner som peker på tre forskjellige lag. En mislykket ping tester tilgjengeligheten til én adresse og feiler av alle grunnene ovenfor, inkludert et kort som aldri startet. Derfor kan den ikke erstatte en oppstartstest.

Hvis det finnes en lokal skjerm eller en gjenopprettingskonsoll, bruk den, fordi spørsmålet den besvarer er om maskinen når operativsystemet sitt. Det er det eneste spørsmålet en ny flashing ville løse. Hvis kortet svikter før det stadiet, følg plattformens gjenopprettingsdokumentasjon i stedet for å slutte deg til en maskinvarefeil fra et manglende skjermbilde, og slutt å trekke strømmen som diagnostikk.

Bygg tilgangsveien på nytt på et kjørende system

Finn den gjeldende oppkoblingen og adressen gjennom det som eier nettverkskonfigurasjonen, og sammenlign det med ruterenes nåværende klientliste og med adressen SSH-klienten brukte. Et lagret vertsnavn eller en gammel DHCP-lease kan peke på gårsdagens mål i ukevis. Bekreft deretter at sshd er aktivert, lytter på en adresse som finnes, og er tillatt fra administrasjonsnettet. SSH-veiledningen til Raspberry Pi behandler aktivering av serveren og tilkobling til gjeldende adresse som to separate trinn, og en fersk Raspberry Pi OS-installasjon lar SSH stå av som standard.

Et vertsnavn kan pekes om til en annen maskin, og et erstatningsbilde kommer med sin egen nøkkel, så sjekk fingeravtrykket via en vei du allerede stoler på i stedet for å klikke bort advarselen. Å slette advarselen er måten en midlertidig adresseendring blir et permanent tillitsproblem. Hvis nøkkelforespørselen er det eneste symptomet, ser du på et identitetsspørsmål og ikke et tilgjengelighetsspørsmål.

Følg svarets rute før du klandrer kortet

En VPN kan endre rutevalget mens den fysiske lenken forblir tilkoblet, og det er nettopp tilfellet der Pi-en er oppe, lytter og likevel er utilgjengelig. Forespørselen kommer inn, og svaret går ut gjennom en tunnel som administratorens klient ikke kan krysse. En lokal konsoll og en lyttende socket beviser ingenting om returveien, så bekreft hvilket grensesnitt som bærer svaret og hvilken gateway det velger. Sammenlign det med nettverket administratoren faktisk er på, for denne feilen feildiagnostiseres som et dødt kort oftere enn noen annen.

Den billigste kontrollen er å se svaret gå ut: på Pi-en, spør hvilken rute som ville bære administratorens adresse og sammenlign den med grensesnittet forespørselen kom inn på. Et avvik der forklarer hele symptomet og koster én kommando.

Én grense om gangen, og når ny flashing er riktig

Rett konfigurasjonen gjennom eieren etter å ha bevart dagens tilstand. Å bytte nettverksbehandler, tømme brannmuren og gjette en statisk adresse er tre endringer som gjør neste observasjon ubrukelig. Hvis bevisene peker på VPN-ens rute eller filtrering, fall tilbake til den klientens egen stopp- eller reparasjonsrutine, og arbeid innenfor den avtalte gjenopprettingsplanen; en kontrollert sammenligning er noe annet enn å slå av beskyttelse på en vert du ikke har forklart.

Ny flashing er et bevisst gjenopprettingsvalg, tatt når du forstår dataene, identiteten og stadiet som sviktet. Det er ikke det en manglende innlogging skal utløse som standard.

Oppbevar konfigurasjonsposten på et sted som kan leses uten Pi-en, og en vei tilbake som ikke går gjennom tunnelen du er i ferd med å endre. Arbeid deretter i rekkefølge: bekreft stadiet fra en lokal konsoll, finn gjeldende adresse, sjekk lyttteren og policyen dens, følg svarets rute, og endre én ting. Hvis kortet aldri nådde operativsystemet, er gjenopprettingsdokumentasjonen neste steg og ikke nettverket.