VPN zainstalowany w Windows, Linux startuje bez sieci: co sprawdzić

Instalujesz VPN w Windows, uruchamiasz ponownie w Linuksie, a połączenie przewodowe nie działa. Oczywista historia pisze się sama: VPN coś zostawił. Historia jest błędna, bo oba starty uruchamiają osobne jądra z osobnymi sterownikami, osobnymi tablicami routingu i osobnymi resolverami. Filtr sieciowy Windows nie jest wykonywany wewnątrz Linuksa, więc usterka leży albo w stosie Linuksa, albo w czymś, co oba starty naprawdę dzielą, na przykład sprzęcie, firmware lub routerze.

Objaw i błędny wniosek

Użyteczna część obserwacji to czas: usterka pojawiła się po zmianie. Bezużyteczna część to skok przyczynowy do VPN w Windows, który nie może działać w innym systemie operacyjnym. Oddzielenie tych dwóch rzeczy to cała praca. Zapisz os czasu, zanim dotkniesz kabla.

To, co oba starty naprawdę dzielą, to fizyczny adapter, kabel, port przełącznika i wszystko powyżej. To prawdziwe wspólne zmienne i zasługują na sprawdzenie po zbadaniu stosu Linuksa.

Zrób migawkę stosu Linuksa czterema poleceniami

Zacznij w trybie tylko do odczytu i zapisz stan, zanim cokolwiek zmienisz: ip -br link dla obecności interfejsów, ip -br address dla adresów, ip route dla tras IPv4 i ip -6 route tam, gdzie IPv6 ma znaczenie. Dokumentacja narzędzia ip rozróżnia te obiekty, a interfejs na liście nie jest dowodem, że ma działający adres lub użyteczną trasę.

Zapisz wyjście do pliku, aby później porównać je z działającym startem. Migawka, której nie możesz odtworzyć, jest tylko wspomnieniem stanu.

Czy to łącze, adres, trasa czy nazwa?

Cztery różne usterki wyglądają w przeglądarce tak samo. Urządzenia może w ogóle nie być, może istnieć bez nośnika, być podłączone, ale bez oczekiwanego adresu, albo mieć adres bez trasy do celu. Niepowodzenie rozwiązywania nazw, gdy surowe adresy działają, to piąty przypadek i należy do resolvera, a nie do sterownika.

Każdy przypadek wskazuje na inną pracę: sterownik lub firmware dla brakującego urządzenia, okablowanie lub przełącznik przy braku nośnika, DHCP lub konfiguracja statyczna dla brakującego adresu oraz routing lub polityka dla brakującej ścieżki. Problem resolvera wskazuje na systemd-resolved, NetworkManager lub lokalną konfigurację DNS.

Sprawdź, czy instalacja Linuksa ma własny VPN albo trwałą konfigurację zapory. Lokalny tunel lub zestaw reguł nftables jest przyczyną po stronie Linuksa i znacznie częściej tłumaczy usterkę niż program Windows, który nie działa.

Następnie porównaj przejście startowe

Windows Fast Startup to hybrydowe wyłączenie, które zachowuje stan sesji jądra zamiast pełnego startu. Dokumentacja Microsoftu dotycząca stanów zasilania odróżnia je od ponownego uruchomienia i od pełnego wyłączenia, dlatego ten sam sprzęt może zachowywać się różnie w obu przejściach.

Jeśli usterka zależy od przejścia z jednego systemu operacyjnego do drugiego, porównaj udokumentowane ponowne uruchomienie lub pełne wyłączenie ze zwykłą ścieżką, po zapisaniu pracy. Wynik, który podąża za przejściem, uzasadnia zbadanie stanu sterownika, urządzenia lub firmware, i sam nie dowodzi, że Fast Startup spowodował konkretną usterkę adaptera.

Zapisz, który system operacyjny ostatnio używał adaptera, typ przejścia, stan łącza w Linuksie i pierwszą nieudaną operację. Powtarzalna różnica między zimnym startem a ciepłym przejściem jest warta znacznie więcej niż usunięcie oprogramowania VPN z obu instalacji bez wiedzy, który stos się zepsuł.

Czego nie zmieniać

Nie resetuj obu stosów sieciowych jako pierwszego kroku. To niszczy porównanie i często niczego nie naprawia, bo prawdziwa przyczyna nigdy nie została zidentyfikowana. Nie reinstaluj VPN w Windows, aby naprawić Linuksa, i nie zmieniaj ustawień firmware przypadkowo tylko dlatego, że przejście startowe korelowało z usterką.

Dokumentacja narzędzia ip opisuje użyte powyżej obiekty łącza, adresu i trasy. Najpierw przeczytaj stronę Linuksa, zachowaj migawkę i dopiero potem zdecyduj, czy wspólna warstwa sprzętowa jest warta zbadania.