Odróżnić awarię rozruchu bezgłowego Pi od awarii sieci

Karta wychodzi z obudowy, zanim ktokolwiek zapytał, która z czterech rzeczy naprawdę zawiodła. Pi przestał odpowiadać po zmianie VPN lub sieci, a ponowne wgranie wydaje się jedynym pozostałym krokiem. Rzadko nim jest: dzierżawa może się przesunąć, sshd może się zatrzymać, albo odpowiedź może wyjść trasą, której nie potrafisz prześledzić, i każde z tego ma własne rozwiązanie. Pożyteczna praca polega na oddzieleniu tego, co zaobserwowałeś, od tego, co założyłeś.

Cztery wyniki, nie jeden

Uruchomiony, z adresem, nasłuchujący i osiągalny to cztery odrębne wyniki, a każdy z nich może zawieść, gdy pozostałe wciąż się utrzymują. Płytka może uruchomić się bezbłędnie i nigdy nie pojawić się w sieci. Może pojawić się z adresem, którego nikt się nie spodziewał, albo zachować właściwy adres z wyłączonym SSH. Może zrobić poprawnie wszystkie trzy i nadal być nieosiągalna, bo odpowiedzi wychodzą przez niewłaściwą bramę.

Odruch ponownego wgrania sprowadza te cztery do jednego pytania, i dlatego tak często daje działające Pi i żadnego wyjaśnienia, co naprawdę się zepsuło.

Gdzie naprawdę kończą się dowody

Zapisz trzy rzeczy, zanim czegokolwiek dotkniesz: adres i łącze, które ostatnio działały, co zostało zmienione, i pierwszą operację, która przestała działać. Nazwa hosta, która już się nie rozwiązuje, połączenie SSH, które kończy się przekroczeniem czasu, i połączenie TCP, które jest odrzucane, to trzy różne obserwacje wskazujące na trzy różne warstwy. Nieudany ping sprawdza osiągalność jednego adresu i zawodzi z każdego z powyższych powodów, łącznie z płytką, która nigdy nie wystartowała. Dlatego nie może zastąpić testu rozruchu.

Jeśli dostępny jest lokalny ekran lub konsola odzyskiwania, użyj jej, bo odpowiada ona na pytanie, czy maszyna dociera do swojego systemu operacyjnego. To jedyne pytanie, które rozwiązałoby ponowne wgranie. Jeśli płytka zawodzi przed tym etapem, postępuj według dokumentacji odzyskiwania platformy, zamiast wnioskować o usterce sprzętowej z brakującego zrzutu ekranu, i przestań odłączać zasilanie jako diagnostykę.

Odbuduj ścieżkę dostępu na działającym systemie

Znajdź bieżące łącze i adres przez to, co zarządza konfiguracją sieci, a następnie porównaj to z bieżącą listą klientów routera i z adresem, którego użył klient SSH. Zapisana nazwa hosta lub stara dzierżawa DHCP mogą przez tygodnie wskazywać na wczorajszy cel. Potem potwierdź, że sshd jest włączony, nasłuchuje na istniejącym adresie i jest dozwolony z sieci administracyjnej. Wskazówki SSH Raspberry Pi traktują włączenie serwera i połączenie z bieżącym adresem jako dwa osobne kroki, a świeża instalacja Raspberry Pi OS pozostawia SSH wyłączony domyślnie.

Nazwę hosta można przekierować na inną maszynę, a obraz zapasowy przychodzi z własnym kluczem, więc sprawdź odcisk palca ścieżką, której już ufasz, zamiast klikać ostrzeżenie. Usunięcie ostrzeżenia to sposób, w jaki tymczasowa zmiana adresu staje się trwałym problemem z zaufaniem. Jeśli monit o klucz jest jedynym objawem, patrzysz na kwestię tożsamości, a nie osiągalności.

Prześledź trasę odpowiedzi, zanim obwinisz płytkę

VPN może zmienić wybór trasy, podczas gdy łącze fizyczne pozostaje przypisane, i dokładnie wtedy Pi jest włączony, nasłuchuje, a mimo to jest nieosiągalny. Żądanie dociera, a odpowiedź wychodzi przez tunel, którego klient administratora nie może pokonać. Lokalna konsola i nasłuchujące gniazdo niczego nie dowodzą co do trasy powrotnej, więc potwierdź, który interfejs niesie odpowiedź i którą bramę wybiera. Porównaj to z siecią, w której administrator naprawdę się znajduje, bo ta usterka jest częściej niż każda inna błędnie diagnozowana jako martwa płytka.

Najtańszym sprawdzeniem jest patrzenie, jak odpowiedź wychodzi: na Pi zapytaj, która trasa niosłaby adres administratora, i porównaj ją z interfejsem, na którym przyszło żądanie. Niezgodność tam wyjaśnia cały objaw i kosztuje jedno polecenie.

Jedna granica naraz, i kiedy ponowne wgranie jest właściwe

Popraw konfigurację przez jej właściciela po zachowaniu bieżącego stanu. Wymiana menedżera sieci, opróżnienie zapory i zgadywanie adresu statycznego to trzy zmiany, które czynią następną obserwację bezużyteczną. Jeśli dowody wskazują na trasę lub filtrowanie VPN, wróć do własnej procedury zatrzymania lub naprawy tego klienta, pracując w ramach uzgodnionego planu odzyskiwania; kontrolowane porównanie to coś innego niż wyłączenie ochrony na hoście, którego nie wyjaśniłeś.

Ponowne wgranie to świadomy wybór odzyskiwania, podejmowany, gdy rozumiesz dane, tożsamość i etap, który zawiódł. To nie jest coś, co brak logowania powinien wywoływać domyślnie.

Trzymaj zapis konfiguracji w miejscu czytelnym bez Pi, i drogę powrotną, która nie prowadzi przez tunel, który zamierzasz zmienić. Potem pracuj po kolei: potwierdź etap z lokalnej konsoli, znajdź bieżący adres, sprawdź nasłuchiwacz i jego politykę, prześledź trasę odpowiedzi i zmień jedną rzecz. Jeśli płytka nigdy nie dotarła do systemu operacyjnego, następnym krokiem jest dokumentacja odzyskiwania, a nie sieć.