WSL2_NETWORK_FAILURE

WSL2_NETWORK_FAILURE to błąd wskazujący na uszkodzoną wirtualną sieć WSL2, wymagającą jej resetu lub restartu usługi LxssManager.

WSL2_NETWORK_FAILURE – czym jest ten problem w środowisku Windows

WSL2_NETWORK_FAILURE oznacza sytuację, w której dystrybucja uruchomiona w Windows Subsystem for Linux 2 traci prawidłową komunikację sieciową. Sam system Linux może nadal startować, otwierać powłokę i wykonywać część poleceń lokalnych, ale połączenia z internetem, siecią lokalną albo usługami działającymi po stronie Windows przestają działać zgodnie z oczekiwaniem. Problem dotyczy zwykle warstwy wirtualnej odpowiedzialnej za przekazywanie pakietów pomiędzy środowiskiem WSL2, systemem Windows i zewnętrzną siecią.

WSL2 korzysta z własnego mechanizmu sieciowego powiązanego z wirtualizacją. Z punktu widzenia użytkownika dystrybucja zachowuje się podobnie do osobnego systemu, jednak jej interfejs sieciowy, adres, trasa domyślna oraz mechanizm translacji adresów są tworzone i kontrolowane przez Windows. Gdy któryś z tych elementów nie zostanie poprawnie odtworzony po uśpieniu komputera, zmianie sieci Wi-Fi, aktualizacji systemu albo restarcie usług, pojawia się błąd WSL2_NETWORK_FAILURE.

Nie zawsze oznacza to uszkodzenie plików dystrybucji. Często problem znajduje się wyłącznie w tymczasowym stanie sieci WSL2. Dlatego przed usunięciem dystrybucji, ponowną instalacją narzędzi albo modyfikacją ważnych plików warto rozdzielić awarię połączenia od awarii samego środowiska Linux.

WSL2_NETWORK_FAILURE a typowa sieć Windows i inne tryby pracy

W zwykłym programie uruchomionym w Windows połączenie sieciowe korzysta bezpośrednio z konfiguracji systemu: aktywnego adaptera, serwerów DNS, tablicy routingu oraz reguł zapory. WSL2 działa przez dodatkową warstwę. Tworzony jest wirtualny interfejs, przydzielany jest adres dla środowiska Linux, a ruch jest przekazywany przez mechanizmy systemowe. Oznacza to, że sprawna przeglądarka w Windows nie musi oznaczać sprawnej sieci wewnątrz WSL2.

Warto odróżnić kilka podobnych objawów. Jeżeli polecenie ping do adresu liczbowego działa, ale nazwa domenowa nie jest rozpoznawana, bardziej prawdopodobny jest problem z DNS niż całkowity brak sieci. Jeżeli nie działa ani adres liczbowy, ani domena, należy sprawdzić interfejs, trasę domyślną i wirtualną warstwę sieciową. Jeżeli dostęp do internetu działa, lecz nie można połączyć się z aplikacją uruchomioną w Windows, przyczyną może być adres nasłuchiwania programu, zapora lub sposób przekazywania portów.

Istotne jest także rozróżnienie między trybem WSL1 a WSL2. WSL1 korzysta z innego modelu komunikacji i nie tworzy identycznej wirtualnej warstwy sieciowej. Instrukcja skuteczna dla WSL1 może więc nie rozwiązać problemu w WSL2. W przypadku WSL2 trzeba uwzględnić stan dystrybucji, usługę odpowiedzialną za obsługę podsystemu, wirtualny adapter oraz ustawienia Windows związane z udostępnianiem i filtrowaniem ruchu.

Na wynik mogą wpływać również programy ochronne, tunele VPN, dodatkowe zapory, profile sieciowe oraz przełączanie pomiędzy siecią przewodową i bezprzewodową. Każda z tych zmian może spowodować, że WSL2 zachowa nieaktualny adres albo trasę. Z tego powodu pojedynczy restart aplikacji nie zawsze wystarcza, a pełny reset środowiska powinien być wykonywany stopniowo i z zachowaniem danych użytkownika.

WSL2_NETWORK_FAILURE – typowe przyczyny i objawy

Jedną z najczęstszych przyczyn jest niepełne odtworzenie wirtualnej sieci po wybudzeniu komputera. System Windows odzyskuje połączenie z routerem, lecz uruchomione wcześniej środowisko WSL2 nadal korzysta ze starego stanu. W rezultacie interfejs może mieć nieaktualny adres, brakować mu trasy domyślnej albo kierować pakiety do nieistniejącego już punktu pośredniego.

Drugą grupę przyczyn stanowią aktualizacje Windows, WSL2 lub sterowników sieciowych. Zmiana komponentów systemowych może zrestartować część usług, ale nie zawsze odtworzyć wszystkie zależności w odpowiedniej kolejności. Objawem bywa działający system Windows przy jednoczesnym braku dostępu z terminala Linux. Czasami problem ujawnia się dopiero przy użyciu menedżera pakietów, narzędzia Git, klienta SSH albo aplikacji pobierającej dane z internetu.

Znaczenie może mieć także konfiguracja DNS tworzona automatycznie dla dystrybucji. WSL2 zwykle otrzymuje plik z ustawieniami resolvera, lecz po zmianie sieci jego zawartość może przestać odpowiadać aktualnym warunkom. Wtedy polecenia odwołujące się do adresów liczbowych mogą działać, natomiast pobieranie pakietów z nazwą domenową zakończy się błędem rozpoznawania hosta.

Do częstych symptomów należą:

• brak odpowiedzi na próby połączenia z internetem wewnątrz WSL2,
• komunikaty o nierozpoznanym hoście podczas korzystania z narzędzi programistycznych,
• brak dostępu do zasobów Windows mimo poprawnego działania połączenia poza WSL2,
• zmienianie się adresu środowiska po każdym uruchomieniu dystrybucji,
• działanie połączenia do czasu uśpienia, zmiany sieci albo ponownego uruchomienia systemu,
• nieudane połączenia z portami aplikacji uruchomionych po stronie Windows.

Sam komunikat WSL2_NETWORK_FAILURE nie wskazuje jeszcze konkretnego komponentu do wymiany. Jest sygnałem, że należy przeprowadzić diagnostykę warstwową: najpierw sprawdzić, czy problem występuje tylko w jednej dystrybucji, następnie porównać dostęp do adresu liczbowego i nazwy domenowej, a dopiero później resetować usługi i ustawienia.

WSL2_NETWORK_FAILURE – praktyczne czynności diagnostyczne i naprawcze

Na początku warto zapisać moment wystąpienia problemu oraz ostatnią zmianę w systemie. Pomocne mogą być informacje o przejściu z Wi-Fi na kabel, powrocie z uśpienia, instalacji aktualizacji, uruchomieniu VPN albo zmianie reguł zapory. Takie dane ułatwiają odróżnienie błędu stałego od problemu pojawiającego się tylko po określonej operacji.

Następnie można sprawdzić stan środowiska poleceniami dostępnymi w Windows i w dystrybucji Linux. Należy zweryfikować, czy dystrybucja działa w wersji 2, czy posiada interfejs sieciowy, jaki otrzymała adres oraz czy istnieje trasa domyślna. Warto również porównać wynik zapytania do adresu liczbowego z wynikiem zapytania do nazwy domenowej. Takie porównanie pozwala ustalić, czy problem leży w przekazywaniu pakietów, czy w rozwiązywaniu nazw.

Jeżeli awaria pojawiła się po zmianie sieci albo po wybudzeniu komputera, często pomaga kontrolowany restart dystrybucji i całego środowiska WSL2. Należy najpierw zamknąć pracujące procesy, zapisać otwarte pliki i upewnić się, że nie trwa instalacja pakietów. Potem można zatrzymać wszystkie dystrybucje, odczekać chwilę i uruchomić potrzebną dystrybucję ponownie. Gdy to nie wystarcza, sprawdza się stan usługi LxssManager oraz powiązanych elementów odpowiedzialnych za wirtualną sieć.

Reset powinien być wykonywany w kolejności od najmniej inwazyjnej do bardziej zaawansowanej. Najpierw sprawdza się aktywny adapter Windows i połączenie poza WSL2. Później kontroluje się konfigurację DNS, trasę i zaporę. Dopiero następnie warto restartować usługi, usuwać tymczasowy stan interfejsu lub odtwarzać ustawienia sieciowe. Nie należy pochopnie kasować dystrybucji, ponieważ może to usunąć środowisko pracy, konfiguracje oraz dane przechowywane w jej systemie plików.

Przydatne bywa także porównanie zachowania kilku dystrybucji. Jeżeli wszystkie mają identyczny problem, bardziej prawdopodobna jest usterka wspólnej warstwy WSL2 albo Windows. Jeżeli tylko jedna dystrybucja traci sieć, należy sprawdzić jej pliki konfiguracyjne, niestandardowe ustawienia resolvera i lokalne reguły zapory. W przypadku połączeń z usługami działającymi w Windows trzeba dodatkowo ustalić, czy aplikacja nasłuchuje wyłącznie na adresie lokalnym, czy pozwala na komunikację z interfejsu wirtualnego.

WSL2_NETWORK_FAILURE – kiedy potrzebna jest pomoc serwisu

Samodzielna diagnostyka jest rozsądna, gdy problem pojawił się jednorazowo po uśpieniu lub zmianie sieci i nie obejmuje innych funkcji komputera. Pomoc techniczna staje się wskazana, gdy błąd powraca po każdym uruchomieniu, reset usługi nie przynosi trwałego skutku, a modyfikacja ustawień może zagrozić danym albo konfiguracji używanej do pracy. Szczególnej ostrożności wymaga sytuacja, w której WSL2 jest wykorzystywany do testowania aplikacji, pracy z repozytoriami lub obsługi lokalnych usług.

Do zgłoszenia warto przygotować opis objawów, informację o wersji Windows i WSL2, nazwę używanej dystrybucji oraz moment, od którego występuje problem. Pomocne są także wyniki podstawowych testów, informacja o działaniu internetu w Windows oraz wiadomość, czy błąd pojawia się po restarcie, zmianie sieci lub wyłączeniu VPN. Takie dane ograniczają liczbę prób i pozwalają bezpieczniej dobrać zakres ingerencji.

W Warszawie diagnostykę problemów z komputerem, w tym usterek wpływających na środowisko WSL2, można zgłosić do Warszawskiego Pogotowia Komputerowego 24/7. Naprawy z reguły zamykają się w ciągu 3 dni roboczych, zależnie od zakresu czynności i dostępności komputera. Podczas obsługi można sprawdzić zarówno konfigurację Windows, jak i zależności pomiędzy usługami, adapterami oraz środowiskiem Linux, z zachowaniem ostrożności wobec danych użytkownika.

Nie należy ignorować powtarzającego się WSL2_NETWORK_FAILURE, jeżeli błąd utrudnia pobieranie aktualizacji, pracę z repozytoriami, dostęp do lokalnych aplikacji albo wykonywanie zadań wymagających stabilnej sieci. Prawidłowo przeprowadzona diagnostyka powinna wskazać, czy wystarczy restart usługi i odtworzenie konfiguracji, czy też konieczne jest szersze sprawdzenie systemu Windows, sterowników, zapory i wirtualnych komponentów sieciowych.