U installeert een VPN in Windows, start opnieuw op in Linux, en de bekabelde verbinding is dood. Het voor de hand liggende verhaal schrijft zichzelf: de VPN heeft iets achtergelaten. Het verhaal is onjuist, want de twee starts draaien afzonderlijke kernels met afzonderlijke stuurprogramma's, afzonderlijke routetabellen en afzonderlijke resolvers. Een Windows-netwerkfilter wordt niet binnen Linux uitgevoerd, dus de fout zit in de Linux-stack of in iets dat beide starts echt delen, zoals hardware, firmware of de router.

Het symptoom en de verkeerde conclusie

Het nuttige deel van de observatie is de timing: de fout verscheen na een wijziging. Het nutteloze deel is de causale sprong naar de Windows-VPN, die niet in het andere besturingssysteem kan draaien. Die twee scheiden is het hele werk. Schrijf de tijdlijn op voordat u een kabel aanraakt.

Wat beide starts wel delen, is de fysieke adapter, de kabel, de switchpoort en alles stroomopwaarts. Dat zijn echte gedeelde variabelen, en ze verdienen een controle nadat de Linux-stack is onderzocht.

Maak een snapshot van de Linux-stack in vier opdrachten

Begin alleen-lezen en leg de toestand vast voordat u iets wijzigt: ip -br link voor aanwezige interfaces, ip -br address voor adressen, ip route voor IPv4-routes en ip -6 route waar IPv6 telt. De referentie van de ip-tool onderscheidt deze objecten, en een interface in de lijst is geen bewijs dat die een werkend adres of een bruikbare route heeft.

Sla de uitvoer op in een bestand zodat u die later met een werkende start kunt vergelijken. Een snapshot die u niet kunt reproduceren is alleen een herinnering aan een toestand.

Is het link, adres, route of naam?

Vier verschillende fouten zien er in een browser hetzelfde uit. Het apparaat kan helemaal ontbreken, aanwezig zijn zonder drager, verbonden zijn maar zonder het verwachte adres, of geadresseerd zijn zonder route naar de bestemming. Naamresolutie die faalt terwijl ruwe adressen werken, is een vijfde geval, en dat hoort bij de resolver en niet bij het stuurprogramma.

Elk geval wijst op ander werk: stuurprogramma of firmware voor een ontbrekend apparaat, bekabeling of switch zonder drager, DHCP of statische configuratie voor een ontbrekend adres, en routing of beleid voor een ontbrekende route. Een resolverprobleem wijst op systemd-resolved, NetworkManager of een lokale DNS-configuratie.

Controleer of de Linux-installatie een eigen VPN of een blijvende firewallconfiguratie heeft. Een lokale tunnel of een nftables-regelset is een oorzaak aan de Linux-kant, en dat verklaart de fout veel waarschijnlijker dan een Windows-programma dat niet draait.

Vergelijk daarna de startovergang

Windows Fast Startup is een hybride afsluiting die de kernelsessiestatus bewaart in plaats van een volledige start uit te voeren. De Microsoft-documentatie over energiestatussen onderscheidt het van een herstart en van een volledige afsluiting, waardoor dezelfde hardware zich in de twee overgangen anders kan gedragen.

Als de fout afhangt van het wisselen van het ene besturingssysteem naar het andere, vergelijk dan een gedocumenteerde herstart of volledige afsluiting met het normale pad, nadat u werk heeft opgeslagen. Een resultaat dat de overgang volgt, rechtvaardigt onderzoek naar de status van stuurprogramma, apparaat of firmware, en het bewijst op zichzelf niet dat Fast Startup een bepaalde adapterfout heeft veroorzaakt.

Noteer welk besturingssysteem de adapter het laatst gebruikte, het type overgang, de linkstatus in Linux en de eerste mislukte handeling. Een herhaalbaar verschil tussen koude start en warme overgang is veel meer waard dan het verwijderen van VPN-software uit beide installaties zonder te weten welke stack brak.

Wat u niet moet veranderen

Reset niet beide netwerkstacks als eerste stap. Dat vernietigt de vergelijking en lost vaak niets op, omdat de werkelijke oorzaak nooit is geïdentificeerd. Installeer de Windows-VPN niet opnieuw om Linux te repareren, en wijzig firmware-instellingen niet willekeurig omdat een startovergang met een fout correleerde.

De referentie van de ip-tool documenteert de link-, adres- en routeobjecten die hierboven zijn gebruikt. Lees eerst de Linux-kant, bewaar de snapshot en beslis pas daarna of de gedeelde hardwarelaag onderzoek waard is.

Gerelateerde artikelen