27850, 442 och 651: en stack, tre första kontroller

Installationsprogrammet stannar med 27850, en anslutning avvisas med 442 och en annan profil returnerar 651. Numren ser ut som tre oberoende fel, och den vanliga reaktionen är att installera om klienten tre gånger. Men de kommer från ett enda delsystem: den virtuella adaptern och filterstacken runt den. Felnumret talar om vilket lager som svek, och det avgör den första kontrollen. Att installera om innan numret är läst återskapar oftast samma fel.

Koppla numret till lagret

Varje fel uppstår på olika ställen, så den första kontrollen skiljer sig även när det synliga symptomet är samma avvisade anslutning. Tre familjer täcker varje fall: installationsprogrammet, adaptern och porten under den. Tabellen nedan sätter varje nummer bredvid den kontroll det kräver.

Om felet visas innan någon profil valts hör det till installationsfamiljen. Om det visas när klienten försöker resa adaptern hör det till adapterfamiljen. Om adaptern syns men porten aldrig öppnas är det miniportfamiljen. Skriv upp numret innan du ändrar något. De tre reparationerna rör olika delar av stacken, och en ändring för fel familj gör nästa försök svårare att läsa.

En full filterstack, eller en säkerhetssvit som blockerar drivrutinen

Installation av klienten registrerar en liten filterkomponent i adapterkedjan. Windows har ett hårt tak för hur många sådana komponenter som kan bindas, och standardvärdet lämnar lite utrymme när antivirus, en virtualiseringsbrygga och en inspelningsdrivrutin finns. Då misslyckas installationen med 27850 trots att VPN-paketet är i ordning. Installationsprogrammet kan inte skilja en överfull stack från en trasig.

Läs det aktuella värdet, höj det och starta om innan du försöker igen. Ett nytt filter kan inte bindas förrän stacken har byggts upp igen:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters /t REG_DWORD /d 14 /f

Den andra orsaken är en säkerhetssvit som blockerar drivrutinsinstallationen utan synlig fråga. Dess självförsvar kan hindra filtret från att registrera sig, och installationsprogrammet rapporterar då ett allmänt komponentfel. Titta i svitens egen logg och, om självförsvaret är hindret, stäng av det bara under installationen och återställ det direkt efteråt. Om värdet redan är höjt och ingen svit blockerar, leta efter övergivna filterdrivrutiner från en tidigare VPN-produkt. Ett gammalt filter utan matchande tjänst tar fortfarande en plats och kan få den nya installationen att misslyckas.

Adaptern finns och blir kvar nere

Fel 442 betyder att den virtuella adaptern finns och att klienten inte får upp den. Den första kontrollen är Enhetshanteraren med dolda enheter visade: en inaktiverad adapter, en adapter med varningstecken och en saknad adapter ser likadana ut i klienten men kräver olika reparationer. Internet Connection Sharing håller den ofta. Om tjänsten har tagit adaptern, stoppa tjänsten och försök igen innan du rör registret. En kvarvarande delningskonfiguration kan ta den igen efter en omstart, så notera om rättelsen överlever en omstart.

En ominstallation kan lämna ett felaktigt visningsnamn som gör adaptern ohanterbar. Värdet ska vara ren text, inte en olöst installationstoken:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName -Value "Cisco Systems VPN Adapter for 64-bit Windows"

Använd det visningsnamn som din klient förväntar sig och starta sedan om så att adaptern räknas upp igen. Att sätta värdet utan omstart lämnar oftast det gamla tillståndet kvar och nästa anslutning ger 442 igen.

Porten under öppnas aldrig

Fel 651 rapporteras när anslutningshanteraren inte kan öppna WAN-miniporten. Adaptern kan se frisk ut i klienten medan porten under den aldrig når ett startat tillstånd. Lista miniporterna och deras status innan du installerar om något:

Get-PnpDevice -Class Net | Where-Object { $_.FriendlyName -like "*WAN Miniport*" } | Select-Object Status, FriendlyName

En miniport med felstatus är det direkta spåret. Ominstallation från Enhetshanteraren återskapar porten, och därför fungerar den här reparationen när en klientominstallation inte gör det. Tredjepartsdrivrutiner bundna till den fysiska adaptern är den andra vanliga orsaken. En VirtualBox-bronätverksdrivrutin, en kvarvarande TAP-drivrutin från OpenVPN eller ett inspelningsfilter kan ta porten först. Att avmarkera komponenten under en installation räcker inte när drivrutinen redan är bunden; den måste tas bort från adapterns egenskaper eller avinstalleras från drivrutinslagret.

Att stänga av IPv6 på VPN-anslutningen har löst felet på vissa buildar, men behandla det som ett test och inte som en permanent lösning. Om anslutningen bara startar med IPv6 avstängt är den underliggande miniporten eller drivrutinen fortfarande orsaken.

Ändra ett lager och behåll bevisen

Spara registervärdena du ändrar, anteckna adapter- och filterlistan före och efter, och starta om mellan försöken. En omstart är en del av reparationen för varje familj här, eftersom adapterstacken byggs vid uppstart och en tjänsteomstart bygger inte upp den igen.

Installera om klienten först när den gamla adaptern, filtrera och miniporterna är borta. Att installera en ny klient ovanpå en trasig stack är sättet en reparerbar 27850 blir en maskin med två halvregistrerade adaptrar och utan tydligt fel. Stanna och eskalera när samma fel överlever den lagerspecifika kontrollen två gånger. Då är nästa användbara steg en ren genomgång av nätverksstacken med leverantörens installationslogg, inte ännu ett försök med samma ominstallation.