27850, 442 en 651: een stapel, drie eerste kontroles

’n Installeerder stop met 27850, ’n verbinding weier met 442, en ’n ander profiel gee 651. Die nommers lyk soos drie onverwante foute, en die gewone reaksie is om die kliënt drie keer te herinstalleer. Hulle kom uit een substelsel: die virtuele adapter en die filterstapel daaromheen. Die foutnommer sê watter laag gefaal het, en dit bepaal die eerste kontrole. Herinstalleer voordat jy dit gelees het, reproduseer gewoonlik dieselfde fout.

Pas die nommer by die laag

Elke fout word op ’n ander punt opgewek, so die eerste kontrole verskil selfs al is die sigbare simptoom dieselfde geweierde verbinding. Drie families dek elke geval: die installeerder, die adapter en die poort daaronder. Die tabel hier onder sit elke nommer langs die kontrole wat dit impliseer.

As die fout verskyn voordat enige profiel gekies is, hoort dit by die installeerfamilie. As dit verskyn wanneer die kliënt die adapter probeer ophaal, hoort dit by die adapterfamilie. As die adapter sigbaar is en die poort gaan nooit oop nie, hoort dit by die minipoortfamilie. Skryf die nommer neer voordat jy iets verander. Die drie herstellings raak verskillende dele van die stapel, en ’n verandering vir die verkeerde familie maak die volgende poging moeiliker om te lees.

’n Vol filterstapel, of ’n suite wat die drywer blokkeer

Om die kliënt te installeer registreer ’n klein filterkomponent in die adapterketting. Windows het ’n harde plafon op hoeveel sulke komponente mag bind, en die verstek laat min ruimte oor sodra antivirus, ’n virtualiseringsbrug en ’n vasvangsdrywer teenwoordig is. Die installasie faal dan met 27850 selfs al is die VPN-pakket heeltemal reg. Die installeerder kan nie ’n vol stapel van ’n stukkende een onderskei nie.

Lees die huidige waarde, verhoog dit, en herbegin voordat jy weer probeer. ’n Nuwe filter kan nie bind voordat die stapel herbou is nie:

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

Die ander oorsaak is ’n sekuriteitsuite wat drywerinstallasie blokkeer sonder ’n sigbare aansporing. Sy selfverdedigingsfunksie kan verhoed dat die filter registreer, so die installeerder rapporteer ’n generiese komponentfout. Kyk in die suite se eie log, en as selfverdediging die blokkeerder is, skakel dit net vir die installasievenster af en herstel dit dadelik daarna. As die telling al verhoog is en geen suite blokkeer nie, soek na verweesde filterdrywers van ’n vorige VPN-produk. ’n Ou filter wat nie meer ’n passende diens het nie, beset steeds ’n slot en kan die nuwe installasie laat misluk.

Die adapter is daar en bly af

Fout 442 beteken die virtuele adapter is teenwoordig en die kliënt kry dit nie op nie. Die eerste kontrole is Toestelbestuur met verborge toestelle sigbaar: ’n gedeaktiveerde adapter, ’n adapter met ’n waarskuwingskenteken en ’n ontbrekende adapter lyk identies in die kliënt maar het verskillende herstellings nodig. Internet Connection Sharing is ’n gereelde houer. As die diens die adapter opeis, stop die diens en probeer weer voordat jy aan die register raak. ’n Oorblywende delingkonfigurasie kan dit ook ná ’n herbegin weer opeis, so let op of die regstelling ’n herbegin oorleef.

’n Herinstallasie kan ’n misvormde vertoonnaam agterlaat wat die adapter onbestuurbaar maak. Die waarde moet gewone teks wees, nie ’n onopgeloste installeerderteken nie:

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"

Gebruik die vertoonnaam wat jou kliënt verwag, en herbegin dan sodat die adapter weer geënumerateer word. Om die waarde te stel sonder ’n herbegin laat gewoonlik die ou toestand in plek en die volgende verbinding gee weer 442.

Die poort daaronder gaan nooit oop nie

Fout 651 word gerapporteer wanneer die verbindingsbestuurder die WAN-minipoort nie kan oopmaak nie. Die adapter kan gesond lyk in die kliënt terwyl die poort daaronder nooit ’n gestarte toestand bereik nie. Lys die minipoorte en hul status voordat jy enigiets herinstalleer:

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

’n Minipoort met ’n foutstatus is die direkte leidraad. Om dit uit Toestelbestuur te herinstalleer herskep die poort, en daarom werk hierdie herstelling wanneer ’n kliëntherinstallasie dit nie doen nie. Derde-party drywers wat aan die fisiese adapter gekoppel is, is die ander algemene oorsaak. ’n VirtualBox-bruggenetwerkdrywer, ’n oorblywende TAP-drywer van OpenVPN of ’n vasvangsfilter kan die poort eerste neem. Om die komponent tydens ’n installasie te deselekteer is nie genoeg wanneer die drywer al gebind is nie; dit moet uit die adapter se eienskappe verwyder of uit die drywermagasyn gedeïnstalleer word.

Om IPv6 op die VPN-verbinding te deaktiveer het hierdie fout op sommige boue opgelos, maar behandel dit as ’n toets eerder as ’n permanente ontwerp. As die verbinding net begin met IPv6 gedeaktiveer, is die onderliggende minipoort of drywer steeds die fout.

Verander een laag en hou die bewyse

Stoor die registerwaardes wat jy verander, teken die adapter- en filterlys voor en ná op, en herbegin tussen pogings. ’n Herbegin is deel van die herstelling vir elke familie hier, want die adapterstapel word by die opstart gebou en ’n diensherstarting herbou dit nie.

Herinstalleer die kliënt eers nadat die ou adapter, filters en minipoorte weg is. Om ’n nuwe kliënt oor ’n stukkende stapel te installeer, is hoe ’n herstelbare 27850 in ’n masjien met twee halfgeregistreerde adapters en geen duidelike fout ontaard. Stop en eskaleer wanneer dieselfde fout die laagspesifieke kontrole twee keer oorleef. Op daardie punt is die nuttige volgende stap ’n skoon netwerkstapel-oorsig saam met die verskaffer se installeerderlog, nie nog ’n poging met dieselfde herinstallasie nie.