27850, 442 og 651: én stak, tre første kontroller

Installationsprogrammet stopper med 27850, en forbindelse afvises med 442, og en anden profil returnerer 651. Tallene ser ud som tre uafhængige fejl, og den sædvanlige reaktion er at geninstallere klienten tre gange. Men de kommer fra ét delsystem: den virtuelle adapter og filterstakken omkring den. Fejlnummeret fortæller, hvilket lag der fejlede, og det afgør den første kontrol. Geninstallation, før du har læst nummeret, genskaber normalt den samme fejl.

Match nummeret til laget

Hver fejl opstår på et forskelligt punkt, så den første kontrol er forskellig, selv når det synlige symptom er den samme afviste forbindelse. Tre familier dækker hvert tilfælde: installationsprogrammet, adapteren og porten under den. Tabellen nedenfor sætter hvert nummer ved siden af den kontrol, det medfører.

Hvis fejlen vises, før nogen profil er valgt, hører den til installationsfamilien. Hvis den vises, når klienten forsøger at rejse adapteren, hører den til adapterfamilien. Hvis adapteren er synlig, og porten aldrig åbner, er det miniportfamilien. Skriv nummeret ned, før du ændrer noget. De tre reparationer rører forskellige dele af stakken, og en ændring for den forkerte familie gør det næste forsøg sværere at læse.

En fuld filterstak, eller en sikkerhedspakke der blokerer driveren

Installation af klienten registrerer en lille filterkomponent i adapterkæden. Windows har et hårdt loft for, hvor mange sådanne komponenter der kan bindes, og standardværdien efterlader lidt plads, når antivirus, en virtualiseringsbro og en optagelsesdriver er til stede. Så fejler installationen med 27850, selv om VPN-pakken er i orden. Installationsprogrammet kan ikke skelne en overfyldt stak fra en beskadiget.

Læs den aktuelle værdi, hæv den, og genstart før nyt forsøg. Et nyt filter kan ikke bindes, før stakken er genopbygget:

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 anden årsag er en sikkerhedspakke, der blokerer driverinstallation uden en synlig prompt. Dens selvforsvar kan forhindre filteret i at registrere sig, og installationsprogrammet rapporterer derfor en generisk komponentfejl. Se pakkens egen log, og hvis selvforsvaret er blokeringen, så slå det kun fra i installationsvinduet og gendan det straks efter. Er værdien allerede hævet, og blokerer ingen pakke, så se efter forældreløse filterdrivere fra et tidligere VPN-produkt. Et gammelt filter uden tilhørende tjeneste optager stadig en plads og kan få den nye installation til at fejle.

Adapteren er der og bliver nede

Fejl 442 betyder, at den virtuelle adapter er til stede, og at klienten ikke kan rejse den. Den første kontrol er Enhedshåndtering med skjulte enheder vist: en deaktiveret adapter, en adapter med advarselstegn og en manglende adapter ser ens ud i klienten, men kræver forskellige reparationer. Internet Connection Sharing holder den ofte. Hvis tjenesten har overtaget adapteren, stop tjenesten og prøv igen, før du rører registreringsdatabasen. En resterende delingskonfiguration kan overtage den igen efter en genstart, så noter, om rettelsen overlever en genstart.

En geninstallation kan efterlade et forkert visningsnavn, som gør adapteren umulig at styre. Værdien skal være almindelig tekst, ikke et uoplø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"

Brug det visningsnavn, din klient forventer, og genstart derefter, så adapteren tælles op igen. At sætte værdien uden genstart efterlader normalt den gamle tilstand, og den næste forbindelse returnerer 442 igen.

Porten under åbner aldrig

Fejl 651 rapporteres, når forbindelsesstyringen ikke kan åbne WAN-miniporten. Adapteren kan se sund ud i klienten, mens porten under den aldrig når en startet tilstand. List miniporterne og deres status, før du geninstallerer noget:

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

En miniport med fejlstatus er det direkte spor. Geninstallation fra Enhedshåndtering genskaber porten, og det er derfor, denne reparation virker, når en klientgeninstallation ikke gør. Tredjepartsdrivere bundet til den fysiske adapter er den anden almindelige årsag. En VirtualBox-bro-netværksdriver, en resterende TAP-driver fra OpenVPN eller et optagelsesfilter kan tage porten først. At fjerne markeringen af komponenten under en installation er ikke nok, når driveren allerede er bundet; den skal fjernes fra adapterens egenskaber eller afinstalleres fra driverlageret.

At slå IPv6 fra på VPN-forbindelsen har løst denne fejl på nogle builds, men behandl det som en test og ikke som en permanent løsning. Hvis forbindelsen kun starter med IPv6 slået fra, er den underliggende miniport eller driver stadig årsagen.

Ændr ét lag og behold beviserne

Gem de registerværdier, du ændrer, noter adapter- og filterlisten før og efter, og genstart mellem forsøg. En genstart er en del af reparationen for hver familie her, fordi adapterstakken bygges ved opstart, og en tjenestegenstart genopbygger den ikke.

Geninstaller først klienten, når den gamle adapter, filtre og miniporter er væk. At installere en ny klient oven på en beskadiget stak er måden, hvorpå en reparabel 27850 bliver til en maskine med to halvregistrerede adaptere og ingen klar fejl. Stop og eskaler, når den samme fejl overlever den lagbestemte kontrol to gange. På det punkt er det nyttige næste skridt en ren gennemgang af netværksstakken med leverandørens installationslog, ikke endnu et forsøg med den samme geninstallation.