Paigaldate Windowsis VPN-i, buudite Linuxisse ja juhtmega ühendus on surnud. Ilmselge lugu kirjutab end ise: VPN jättis midagi maha. Lugu on vale, sest kaks buuti käivitavad eraldi kerneli, eraldi draiverid, eraldi marsruutimistabelid ja eraldi resolverid. Windowsi võrgufilter ei käivitu Linuxi sees, seega on viga kas Linuxi pinus või milleski, mida mõlemad buudid tõesti jagavad, näiteks riistvara, püsivara või ruuter.

Sümptom ja vale järeldus

Vaatluse kasulik osa on ajastus: viga ilmus pärast muudatust. Kasutu osa on põhjuslik hüpe Windowsi VPN-i, mis ei saa teises operatsioonisüsteemis töötada. Nende kahe eraldamine on kogu töö. Kirjutage ajajoon üles enne, kui puudutate kaablit.

Mida mõlemad buudid jagavad, on füüsiline adapter, kaabel, lüliti port ja kõik ülalpool. Need on tõelised ühised muutujad ja väärivad kontrolli pärast Linuxi pinu uurimist.

Tehke Linuxi pinust nelja käsuga hetktõmmis

Alustage ainult lugemise režiimis ja jäädvustage olek enne millegi muutmist: ip -br link liideste olemasolu jaoks, ip -br address aadresside jaoks, ip route IPv4-marsruutide jaoks ja ip -6 route seal, kus IPv6 loeb. ip-tööriista viide eristab neid objekte ning loendis olev liides ei tõesta, et sellel on töötav aadress või kasutatav marsruut.

Salvestage väljund faili, et saaksite seda hiljem töötava buudiga võrrelda. Hetktõmmis, mida te ei suuda korrata, on vaid mälestus olekust.

Kas see on link, aadress, marsruut või nimi?

Neli erinevat riket näevad brauserist ühesugused välja. Seade võib täiesti puududa, olla olemas kandjata, olla ühendatud, kuid ilma oodatud aadressita, või olla adresseeritud ilma marsruudita sihtkohta. Nimelahenduse nurjumine, kui toorid aadressid töötavad, on viies juhtum ja kuulub resolverile, mitte draiverile.

Iga juhtum osutab erinevale tööle: puuduva seadme puhul draiver või püsivara, kandja puudumisel kaablid või lüliti, puuduva aadressi puhul DHCP või staatiline konfiguratsioon ning puuduva tee puhul marsruutimine või poliitika. Resolveri probleem osutab systemd-resolvedile, NetworkManagerile või kohalikule DNS-konfiguratsioonile.

Kontrollige, kas Linuxi paigaldusel on oma VPN või püsiv tulemüüri konfiguratsioon. Kohalik tunnel või nftablesi reeglistik on Linuxi-poolne põhjus ja selgitab riket palju tõenäolisemalt kui Windowsi programm, mis ei tööta.

Seejärel võrrelge buudi üleminekut

Windows Fast Startup on hübriidne väljalülitus, mis säilitab kerneli sessiooni oleku, selle asemel et teha täielik buut. Microsofti dokumentatsioon toiteolekute kohta eristab seda taaskäivitusest ja täielikust väljalülitusest, mistõttu sama riistvara võib kahe ülemineku jooksul käituda erinevalt.

Kui rike sõltub ühest operatsioonisüsteemist teise liikumisest, võrrelge dokumenteeritud taaskäivitust või täielikku väljalülitust tavalise teega, olles töö salvestanud. Üleminekut järgiv tulemus õigustab draiveri, seadme või püsivara oleku uurimist ja ei tõesta iseenesest, et Fast Startup põhjustas konkreetse adapteririkke.

Kirjutage üles, milline OS kasutas adapterit viimasena, ülemineku tüüp, Linuxi lingi olek ja esimene nurjunud toiming. Korratav erinevus külma käivituse ja sooja ülemineku vahel on palju väärtuslikum kui VPN-tarkvara eemaldamine mõlemast paigaldusest ilma teadmata, milline pinu katki läks.

Mida mitte muuta

Ärge lähtestage mõlemat võrgupinu esimese sammuna. See hävitab võrdluse ega paranda sageli midagi, sest tegelikku põhjust ei tuvastatud kunagi. Ärge paigaldage Windowsi VPN-i uuesti Linuxi parandamiseks ja ärge muutke püsivara seadeid juhuslikult, sest buudi üleminek korreleerus rikkega.

ip-tööriista viide dokumenteerib ülal kasutatud lingi, aadressi ja marsruudi objektid. Lugege esmalt Linuxi poolt, hoidke hetktõmmis alles ja alles siis otsustage, kas ühist riistvarakihti tasub uurida.

Seotud artiklid