Du installerer en VPN i Windows, genstarter ind i Linux, og den kablede forbindelse er død. Den oplagte historie skriver sig selv: VPN'en efterlod noget. Historien er forkert, fordi de to opstarter kører separate kerner med separate drivere, separate routingtabeller og separate resolvere. Et Windows-netværksfilter kører ikke inde i Linux, så fejlen ligger enten i Linux-stakken eller i noget, som begge opstarter virkelig deler, som hardware, firmware eller routeren.

Symtomet og den forkerte konklusion

Den nyttige del af observationen er timingen: fejlen dukkede op efter en ændring. Den ubrugelige del er det kausale spring til Windows-VPN'en, som ikke kan køre i det andet styresystem. At skille de to ad er hele arbejdet. Skriv tidslinjen ned, før du rører en kabel.

Det, begge opstarter deler, er den fysiske adapter, kablet, switchporten og alt deroppe. Det er rigtige fælles variable, og de fortjener et tjek, efter at Linux-stakken er undersøgt.

Tag et snapshot af Linux-stakken med fire kommandoer

Begynd skrivebeskyttet og fang tilstanden, før du ændrer noget: ip -br link for interfacetilstedeværelse, ip -br address for adresser, ip route for IPv4-ruter og ip -6 route, hvor IPv6 betyder noget. Referencen for ip-værktøjet skelner mellem disse objekter, og et interface på listen er ikke bevis for, at det har en fungerende adresse eller en brugbar rute.

Gem outputtet i en fil, så du senere kan sammenligne det med en opstart, der virker. Et snapshot, du ikke kan genskabe, er kun en erindring om en tilstand.

Er det link, adresse, rute eller navn?

Fire forskellige fejl ser ens ud fra en browser. Enheden kan mangle helt, være til stede uden bærer, være forbundet men uden sin forventede adresse, eller have en adresse uden rute til destinationen. Navneopløsning, der fejler, mens rå adresser virker, er et femte tilfælde, og det hører til resolversiden frem for driveren.

Hvert tilfælde peger på forskelligt arbejde: driver eller firmware til en manglende enhed, kabler eller switch når der ikke er bærer, DHCP eller statisk konfiguration til en manglende adresse, og routing eller politik til en manglende vej. Et resolverproblem peger på systemd-resolved, NetworkManager eller en lokal DNS-konfiguration.

Tjek, om Linux-installationen har sin egen VPN eller en vedvarende firewallkonfiguration. En lokal tunnel eller et nftables-regelsæt er en årsag på Linux-siden, og det forklarer langt oftere fejlen end et Windows-program, der ikke kører.

Sammenlign derefter opstartsovergangen

Windows Fast Startup er en hybrid nedlukning, der beholder kernesessionens tilstand i stedet for at udføre en fuld opstart. Microsofts dokumentation om strømtilstande skelner den fra en genstart og fra en fuld nedlukning, og derfor kan den samme hardware opføre sig forskelligt i de to overgange.

Hvis fejlen afhænger af at skifte fra ét styresystem til det andet, så sammenlign en dokumenteret genstart eller fuld nedlukning med den normale vej, efter at du har gemt arbejde. Et resultat, der følger overgangen, berettiger at undersøge driver-, enheds- eller firmwaretilstand, og det beviser ikke i sig selv, at Fast Startup forårsagede en bestemt adapterfejl.

Notér, hvilket styresystem der sidst brugte adapteren, overgangstypen, Linux-linktilstanden og den første handling, der fejlede. En gentagelig forskel mellem kold start og varm overgang er langt mere værd end at fjerne VPN-software fra begge installationer uden at vide, hvilken stak der gik i stykker.

Hvad du ikke skal ændre

Nulstil ikke begge netværksstakke som første skridt. Det ødelægger sammenligningen og retter ofte ingenting, fordi den egentlige årsag aldrig blev identificeret. Geninstaller ikke Windows-VPN'en for at reparere Linux, og ændr ikke firmwareindstillinger tilfældigt, fordi en opstartsovergang korrelerede med en fejl.

Referencen for ip-værktøjet dokumenterer de link-, adresse- og ruteobjekter, der bruges ovenfor. Læs Linux-siden først, gem snapshotet, og beslut først derefter, om det fælles hardwarelag er værd at undersøge.

Relaterede artikler