VPN installerat i Windows, Linux startar utan nätverk: vad du bör kontrollera

Du installerar en VPN i Windows, startar om in i Linux, och den kabelanslutna förbindelsen är död. Den uppenbara historien skriver sig själv: VPN:en lämnade något efter sig. Historien är fel, eftersom de två starterna kör separata kärnor med separata drivrutiner, separata routingtabeller och separata resolvers. Ett Windows-nätverksfilter körs inte inuti Linux, så felet ligger antingen i Linux-stacken eller i något som båda starterna verkligen delar, som hårdvara, firmware eller routern.

Symtomet och den felaktiga slutsatsen

Den användbara delen av observationen är tidpunkten: felet uppstod efter en ändring. Den oanvändbara delen är det kausala språnget till Windows-VPN:en, som inte kan köras i det andra operativsystemet. Att skilja de två är hela arbetet. Skriv ned tidslinjen innan du rör en kabel.

Det båda starterna delar är den fysiska adaptern, kabeln, switchporten och allt som sitter uppströms. Det är verkliga gemensamma variabler, och de förtjänar en kontroll efter att Linux-stacken har undersökts.

Ta en ögonblicksbild av Linux-stacken med fyra kommandon

Börja skrivskyddat och fånga tillståndet innan du ändrar något: ip -br link för gränssnitt, ip -br address för adresser, ip route för IPv4-rutter och ip -6 route där IPv6 spelar roll. Referensen för ip-verktyget skiljer mellan dessa objekt, och ett gränssnitt i listan är inte bevis för att det har en fungerande adress eller en användbar rutt.

Spara utdata i en fil så att du senare kan jämföra den med en start som fungerar. En ögonblicksbild du inte kan återskapa är bara ett minne av ett tillstånd.

Är det länk, adress, rutt eller namn?

Fyra olika fel ser likadana ut från en webbläsare. Enheten kan saknas helt, vara närvarande utan bärare, vara ansluten men utan den förväntade adressen, eller ha adress utan rutt till målet. Namnuppslagning som misslyckas medan råa adresser fungerar är ett femte fall, och det hör till resolvern och inte till drivrutinen.

Varje fall pekar på olika arbete: drivrutin eller firmware för en saknad enhet, kablage eller switch när det inte finns bärare, DHCP eller statisk konfiguration för en saknad adress, och routning eller policy för en saknad väg. Ett resolverproblem pekar på systemd-resolved, NetworkManager eller en lokal DNS-konfiguration.

Kontrollera om Linux-installationen har en egen VPN eller en beständig brandväggskonfiguration. En lokal tunnel eller en nftables-regeluppsättning är en orsak på Linux-sidan, och det förklarar felet mycket oftare än ett Windows-program som inte körs.

Jämför sedan startövergången

Windows Fast Startup är en hybrid avstängning som behåller kärnans sessionsläge i stället för att göra en fullständig start. Microsofts dokumentation om strömtillstånd skiljer den från en omstart och från en fullständig avstängning, vilket är varför samma hårdvara kan bete sig olika i de två övergångarna.

Om felet beror på att man byter från ett operativsystem till det andra, jämför en dokumenterad omstart eller fullständig avstängning med den normala vägen, efter att du sparat arbete. Ett resultat som följer övergången motiverar att undersöka drivrutinens, enhetens eller firmwarens tillstånd, och det bevisar inte i sig att Fast Startup orsakade ett visst adapterfel.

Notera vilket operativsystem som använde adaptern senast, övergångstypen, länkstatusen i Linux och den första operation som misslyckades. En upprepbar skillnad mellan kall start och varm övergång är värd mycket mer än att ta bort VPN-programvara från båda installationerna utan att veta vilken stack som gick sönder.

Vad du inte bör ändra

Återställ inte båda nätverksstackarna som första steg. Det förstör jämförelsen och lagar ofta ingenting, eftersom den verkliga orsaken aldrig identifierades. Installera inte om Windows-VPN:en för att reparera Linux, och ändra inte firmware-inställningar på måfå bara för att en startövergång korrelerade med ett fel.

Referensen för ip-verktyget dokumenterar de länk-, adress- och ruttobjekt som används ovan. Läs Linux-sidan först, behåll ögonblicksbilden och avgör först då om det gemensamma hårdvarulagret är värt att undersöka.