VPN avstängt men fortfarande långsamt: kontrollera adapterbindningarna

Klienten säger frånkopplad, tunnelgränssnittet är borta och den dagliga trafiken är fortfarande långsammare än före VPN-installationen. En förklaring är en filterkomponent som blev kvar bunden till den fysiska adaptern efter att tunneln stängdes. Det är ett spår värt att kontrollera, inte en dom: samma långsamhet kan komma från en drivrutinsversion, en offload-inställning eller komponenten från en andra klient. Inventera vad som faktiskt är anslutet innan du ändrar något.

Namnge komponenten, registrera dess tillstånd och ändra sedan en sak.

Separera tunneln från bindningen

Ett VPN-gränssnitt och en filterdrivrutin är olika objekt. Gränssnittet försvinner när tunneln stängs; ett filter kopplat till den fysiska adaptern installeras i nätverksstacken och kan förbli aktiverat oavsett tunnelns tillstånd. Användarna ser ett symtom och operativsystemet håller två orelaterade delar av tillstånd.

Den skillnaden är anledningen till att frånkoppling av klienten eller borttagning av VPN-profilen ofta inte ändrar något. Gränssnittet är det synliga objektet. Bindningen sitter längre ned i stacken och överlever den.

Inventera den exakta komponenten

Lista bindningarna på adaptern som bär den långsamma trafiken, med dess riktiga namn i stället för en allmän gissning. Registrera komponent-ID och aktiverat tillstånd och jämför sedan den fysiska adaptern med VPN-gränssnittet och eventuella andra virtuella adaptrar i listan.

Versionsinformation hör till samma post, eftersom två maskiner med ett liknande visningsnamn kan köra olika drivrutiner. En leverantör kan också leverera en ny filterkomponent under ett gammalt visningsnamn. Jämför identifierare i stället för etiketter.

Get-NetAdapterBinding -Name 'Ethernet' -AllBindings | Select-Object DisplayName,ComponentID,Enabled
Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverVersion,Status
Get-NetAdapterStatistics -Name 'Ethernet'
pnputil /enum-drivers | Select-String -Pattern 'vpn|filter|ndis' -Context 0,2
driverquery /v | Select-String -Pattern 'vpn|filter'

Skriv ned adapternamnet, komponent-ID, drivrutinsversionen och VPN-klientversionen. Utan dessa fyra värden är nästa jämförelse en gissning. Bifoga dem till ärendet så att en senare körning kan jämföras med denna.

Ändra en godkänd sak och upprepa

Bygg en baslinje med samma arbetsbelastning, destination och åtkomstnätverk. Notera om VPN är frånkopplat, om den misstänkta bindningen är aktiverad och om en andra VPN-klient är installerad, eftersom två klienter kan lämna komponenter efter sig.

Om leverantören stöder att slå den bindningen av och på för diagnostik, inaktivera bara den komponenten på den adaptern, upprepa den identiska arbetsbelastningen och återställ det ursprungliga tillståndet. Ett före-och-efter-par från en variabel är värt mer än en ny installation av allt. Om resultatet är tvetydigt, återställ det ursprungliga tillståndet innan du provar nästa hypotes. Två ändringar samtidigt ger ett tal som ingen kan tillskriva.

Anslut sedan igen och kontrollera att VPN fortfarande fungerar, inklusive eventuella principer som klienten ska tillämpa. En ändring som förbättrar surfandet men bryter tunnelns egen tillämpning har bytt ett fel mot ett annat, och den regressionen hör hemma i posten.

Håll dig på leverantörens supportade väg

Filtreringsimplementationer ändras mellan produktgenerationer. Vissa leverantörer dokumenterar nu en Windows Filtering Platform-väg där tidigare versioner använde en annan drivrutinsfamilj, så ett registerrecept från en gammal forumtråd kan vara helt fel för den installerade versionen.

Kontrollera det installerade inventariet och den aktiva vägen separat, eftersom valet av ett nyare läge inte bevisar att den äldre komponenten är borta. När rensning behövs, kör leverantörens supportade borttagnings- eller uppdateringsprocess och upprepa sedan bindningsinventeringen.

Håll bevisningen snäv: adapter, komponent, versioner, den kontrollerade jämförelsen och VPN-regressionsresultatet. Det stöder en slutsats om drivrutin eller kompatibilitet utan att göra varje långsam anslutning till ett MTU-experiment eller hävda att alla VPN-klienter beter sig likadant.