Windows instalēts VPN, Linux startē bez tīkla: ko pārbaudīt

Jūs instalējat VPN Windows vidē, pārstartējat uz Linux, un vadu savienojums ir miris. Acīmredzamais stāsts rakstās pats: VPN kaut ko atstāja aiz sevis. Stāsts ir nepareizs, jo abas palaišanas izmanto atsevišķus kodolus ar atsevišķiem draiveriem, atsevišķām maršrutēšanas tabulām un atsevišķiem risinātājiem. Windows tīkla filtrs netiek izpildīts Linux iekšienē, tāpēc kļūda ir vai nu Linux stekā, vai kaut kā, ko abas palaišanas patiešām dala, piemēram, aparatūrā, firmware vai maršrutētājā.

Simptoms un nepareizais secinājums

Noderīgā novērojuma daļa ir laiks: kļūda parādījās pēc izmaiņām. Nenoderīgā daļa ir cēloņsakarības lēciens uz Windows VPN, kas nevar darboties otrā operētājsistēmā. Abu atdalīšana ir viss darbs. Pierakstiet laika līniju, pirms pieskaraties kabelim.

Tas, ko abas palaišanas patiešām dala, ir fiziskais adapteris, kabelis, komutatora ports un viss, kas atrodas augšpusē. Tie ir īsti kopīgi mainīgie, un tie ir pelnījuši pārbaudi pēc tam, kad Linux steks ir izpētīts.

Uzņemiet Linux steka momentuzņēmumu ar četrām komandām

Sāciet tikai lasīšanas režīmā un fiksējiet stāvokli pirms kaut kā maiņas: ip -br link saskarņu esamībai, ip -br address adresēm, ip route IPv4 maršrutiem un ip -6 route tur, kur IPv6 ir svarīgs. ip rīka dokumentācija šos objektus nošķir, un saskarnes parādīšanās sarakstā nav pierādījums, ka tai ir strādājoša adrese vai lietojams maršruts.

Saglabājiet izvadi failā, lai vēlāk to salīdzinātu ar strādājošu palaišanu. Momentuzņēmums, ko nevarat reproducēt, ir tikai stāvokļa atmiņa.

Vai tas ir savienojums, adrese, maršruts vai nosaukums?

Četras dažādas kļūdas pārlūkā izskatās vienādi. Ierīce var pilnībā trūkt, būt bez nesēja, būt savienota, bet bez gaidītās adreses, vai tai var būt adrese bez maršruta uz galamērķi. Nosaukumu izšķiršanas neizdošanās, kamēr neapstrādātas adreses strādā, ir piektais gadījums, un tas pieder risinātājam, nevis draiverim.

Katrs gadījums norāda uz citu darbu: draiveris vai firmware trūkstošai ierīcei, kabeļi vai komutators, kad nav nesēja, DHCP vai statiska konfigurācija trūkstošai adresei, un maršrutēšana vai politika trūkstošam ceļam. Risinātāja problēma norāda uz systemd-resolved, NetworkManager vai vietēju DNS konfigurāciju.

Pārbaudiet, vai Linux instalācijai ir savs VPN vai pastāvīga ugunsmūra konfigurācija. Vietējais tunelis vai nftables noteikumu kopa ir Linux puses cēlonis, un daudz ticamāk izskaidro kļūdu nekā nedarbojoša Windows programma.

Pēc tam salīdziniet palaišanas pāreju

Windows Fast Startup ir hibrīda izslēgšana, kas saglabā kodola sesijas stāvokli, nevis veic pilnu palaišanu. Microsoft dokumentācija par barošanas stāvokļiem to nošķir no pārstartēšanas un no pilnas izslēgšanas, tāpēc viena un tā pati aparatūra abās pārejās var uzvesties atšķirīgi.

Ja kļūda ir atkarīga no pārejas no vienas operētājsistēmas uz otru, pēc darba saglabāšanas salīdziniet dokumentētu pārstartēšanu vai pilnu izslēgšanu ar parasto ceļu. Rezultāts, kas seko pārejai, attaisno draivera, ierīces vai firmware stāvokļa pārbaudi, un pats par sevi nepierāda, ka Fast Startup izraisīja konkrētu adaptera kļūdu.

Pierakstiet, kura operētājsistēma pēdējā izmantoja adapteri, pārejas veidu, saites stāvokli Linux vidē un pirmo neizdevušos darbību. Atkārtojama atšķirība starp aukstu startu un siltu pāreju ir daudz vērtīgāka par VPN programmatūras noņemšanu no abām instalācijām, nezinot, kura steka sabruka.

Ko nemainīt

Neatiestatiet abas tīkla stekas kā pirmo soli. Tas iznīcina salīdzinājumu un bieži neko nelabo, jo īstais cēlonis tā arī netika noteikts. Nepārinstalējiet Windows VPN, lai salabotu Linux, un nemainiet firmware iestatījumus nejauši tāpēc, ka palaišanas pāreja korelēja ar kļūdu.

ip rīka dokumentācija apraksta iepriekš izmantotos saites, adreses un maršruta objektus. Vispirms lasiet Linux pusi, saglabājiet momentuzņēmumu un tikai pēc tam izlemiet, vai kopīgais aparatūras slānis ir pētīšanas vērts.