Windows aplinkoje įdiegtas VPN, Linux kraunasi be tinklo: ką tikrinti

Įdiegiate VPN Windows aplinkoje, persikraunate į Linux, ir laidinis ryšys miręs. Akivaizdi istorija rašosi pati: VPN kažką paliko. Istorija neteisinga, nes abu paleidimai naudoja atskirus branduolius su atskirais tvarkyklėmis, atskiromis maršrutų lentelėmis ir atskirais resolveriais. Windows tinklo filtras nevykdomas Linux viduje, tad gedimas yra arba Linux steke, arba tame, ką abu paleidimai tikrai dalijasi, pavyzdžiui, aparatinėje įrangoje, firmware arba maršrutizatoriuje.

Simptomas ir neteisinga išvada

Naudingoji stebėjimo dalis yra laikas: gedimas pasirodė po pakeitimo. Nenaudingoji dalis yra priežastinis šuolis į Windows VPN, kuris negali veikti kitoje operacinėje sistemoje. Atskyrus abu dalykus ir yra visas darbas. Užsirašykite laiko juostą, prieš liesdami laidą.

Tai, ką abu paleidimai tikrai dalijasi, yra fizinis adapteris, laidas, komutatoriaus prievadas ir viskas, kas yra aukščiau. Tai tikri bendri kintamieji, ir jie verti patikros po to, kai ištirtas Linux stekas.

Užfiksuokite Linux steką keturiomis komandomis

Pradėkite tik skaitymo režimu ir užfiksuokite būseną prieš ką nors keisdami: ip -br link sąsajų buvimui, ip -br address adresams, ip route IPv4 maršrutams ir ip -6 route ten, kur IPv6 svarbus. ip įrankio dokumentacija skiria šiuos objektus, o sąsajos pasirodymas sąraše neįrodo, kad ji turi veikiantį adresą ar naudojamą maršrutą.

Išsaugokite išvestį faile, kad vėliau palygintumėte su veikiančiu paleidimu. Momentinė kopija, kurios negalite atkurti, tėra būsenos prisiminimas.

Ar tai sąsaja, adresas, maršrutas ar vardas?

Keturi skirtingi gedimai naršyklėje atrodo vienodai. Įrenginio gali visai nebūti, jis gali būti be nešiklio, būti prijungtas bet be laukiamo adreso, arba turėti adresą be maršruto iki paskirties. Vardų skyrimo nepavykimas, kai neapdoroti adresai veikia, yra penktas atvejis, ir jis priklauso resolveriui, o ne tvarkyklei.

Kiekvienas atvejis rodo skirtingą darbą: tvarkyklė arba firmware trūkstamam įrenginiui, kabeliai arba komutatorius, kai nėra nešiklio, DHCP arba statinė konfigūracija trūkstamam adresui, ir maršrutizavimas arba politika trūkstamam keliui. Resolverio problema rodo į systemd-resolved, NetworkManager arba vietinę DNS konfigūraciją.

Patikrinkite, ar Linux diegimas turi savo VPN arba nuolatinę užkardos konfigūraciją. Vietinis tunelis arba nftables taisyklių rinkinys yra Linux pusės priežastis, ir daug labiau tikėtina, kad jis paaiškins gedimą nei neveikianti Windows programa.

Tada palyginkite paleidimo perėjimą

Windows Fast Startup yra hibridinis išjungimas, kuris išsaugo branduolio sesijos būseną vietoj visiško paleidimo. Microsoft dokumentacija apie maitinimo būsenas skiria jį nuo perkrovimo ir nuo visiško išjungimo, todėl ta pati aparatinė įranga gali elgtis skirtingai abiejuose perėjimuose.

Jei gedimas priklauso nuo perėjimo iš vienos operacinės sistemos į kitą, išsaugoję darbą palyginkite dokumentuotą perkrovimą arba visišką išjungimą su įprastu keliu. Rezultatas, kuris seka perėjimą, pateisina tvarkyklės, įrenginio arba firmware būsenos tyrimą, ir pats savaime neįrodo, kad Fast Startup sukėlė konkretų adapterio gedimą.

Užfiksuokite, kuri operacinė sistema paskutinį kartą naudojo adapterį, perėjimo tipą, sąsajos būseną Linux aplinkoje ir pirmą nepavykusią operaciją. Pakartojamas skirtumas tarp šalto paleidimo ir šilto perėjimo vertas daug daugiau nei VPN programinės įrangos pašalinimas iš abiejų diegimų nežinant, kuris stekas sugedo.

Ko nekeisti

Neatstatykite abiejų tinklo stekų kaip pirmo žingsnio. Tai sugriauna palyginimą ir dažnai nieko nepataiso, nes tikroji priežastis taip ir nebuvo nustatyta. Nepersistenkite Windows VPN, kad sutvarkytumėte Linux, ir nekeiskite firmware nustatymų atsitiktinai vien todėl, kad paleidimo perėjimas koreliavo su gedimu.

ip įrankio dokumentacija aprašo aukščiau naudotus sąsajos, adreso ir maršruto objektus. Pirmiausia perskaitykite Linux pusę, išsaugokite momentinę kopiją ir tik tada nuspręskite, ar bendras aparatinės įrangos sluoksnis vertas tyrimo.