27850, 442 și 651: un singur stack, trei verificări inițiale

Programul de instalare se oprește la 27850, o conexiune este refuzată cu 442, iar alt profil returnează 651. Numerele par trei defecte independente, iar reacția obișnuită este reinstalarea clientului de trei ori. Însă provin dintr-un singur subsistem: adaptorul virtual și stackul de filtre din jurul lui. Numărul erorii spune care strat a eșuat, iar asta decide prima verificare. Reinstalarea înainte de a citi numărul reproduce de obicei același defect.

Asociați numărul cu stratul

Fiecare eroare apare într-un punct diferit, deci prima verificare diferă chiar și când simptomul vizibil este aceeași conexiune refuzată. Trei familii acoperă fiecare caz: programul de instalare, adaptorul și portul de sub el. Tabelul de mai jos pune fiecare număr lângă verificarea pe care o implică.

Dacă eroarea apare înainte de alegerea oricărui profil, aparține familiei programului de instalare. Dacă apare când clientul încearcă să ridice adaptorul, aparține familiei adaptorului. Dacă adaptorul este vizibil, iar portul nu se deschide niciodată, este familia miniportului. Notați numărul înainte de a schimba ceva. Cele trei reparații ating părți diferite ale stackului, iar o modificare făcută pentru familia greșită face următoarea încercare mai greu de citit.

Un stack de filtre plin sau un pachet de securitate care blochează driverul

Instalarea clientului înregistrează o componentă mică de filtrare în lanțul adaptorului. Windows are un plafon dur pentru câte astfel de componente se pot lega, iar valoarea implicită lasă puțin loc când există antivirus, o punte de virtualizare și un driver de captură. Atunci instalarea eșuează cu 27850, deși pachetul VPN este în regulă. Programul de instalare nu distinge un stack plin de unul stricat.

Citiți valoarea curentă, măriți-o și reporniți înainte de a mai încerca. Un filtru nou nu se poate lega până când stackul nu este reconstruit:

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

Cealaltă cauză este un pachet de securitate care blochează instalarea driverului fără un mesaj vizibil. Funcția lui de autoapărare poate împiedica înregistrarea filtrului, iar programul de instalare raportează atunci o eroare generică de componentă. Verificați jurnalul propriu al pachetului și, dacă autoapărarea este obstacolul, dezactivați-o doar pe durata instalării și restabiliți-o imediat după. Dacă valoarea este deja mărită și niciun pachet nu blochează, căutați drivere de filtru orfane de la un produs VPN anterior. Un filtru vechi fără serviciu corespunzător ocupă în continuare un loc și poate face să eșueze instalarea nouă.

Adaptorul este acolo și rămâne jos

Eroarea 442 înseamnă că adaptorul virtual este prezent, iar clientul nu îl poate ridica. Prima verificare este Managerul de dispozitive cu dispozitivele ascunse afișate: un adaptor dezactivat, un adaptor cu semn de avertizare și un adaptor lipsă arată la fel în client, dar necesită reparații diferite. Internet Connection Sharing îl ține des. Dacă serviciul a ocupat adaptorul, opriți serviciul și reîncercați înainte de a atinge registrul. O configurație de partajare rămasă îl poate ocupa din nou după o repornire, așa că notați dacă remedierea supraviețuiește repornirii.

O reinstalare poate lăsa un nume de afișare malformat care face adaptorul de necontrolat. Valoarea trebuie să fie text simplu, nu un token de instalare nerezolvat:

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"

Folosiți numele de afișare pe care îl așteaptă clientul dvs., apoi reporniți pentru ca adaptorul să fie enumerat din nou. Setarea valorii fără repornire lasă de obicei starea veche pe loc, iar următoarea conexiune dă din nou 442.

Portul de dedesubt nu se deschide niciodată

Eroarea 651 este raportată când managerul de conexiuni nu poate deschide miniportul WAN. Adaptorul poate părea sănătos în client, în timp ce portul de dedesubt nu atinge niciodată o stare pornită. Enumerați miniporturile și starea lor înainte de a reinstala ceva:

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

Un miniport cu stare de eroare este indiciul direct. Reinstalarea lui din Managerul de dispozitive recreează portul și de aceea această reparație funcționează când reinstalarea clientului nu reușește. Driverele terțe legate de adaptorul fizic sunt cealaltă cauză frecventă. Un driver de rețea în punte VirtualBox, un driver TAP rămas de la OpenVPN sau un filtru de captură pot ocupa portul primele. Debifarea componentei în timpul unei instalări nu este suficientă când driverul este deja legat; el trebuie scos din proprietățile adaptorului sau dezinstalat din depozitul de drivere.

Dezactivarea IPv6 pe conexiunea VPN a rezolvat această eroare pe unele builduri, dar tratați asta ca test, nu ca proiect permanent. Dacă conexiunea pornește doar cu IPv6 dezactivat, miniportul sau driverul de dedesubt rămâne cauza.

Schimbați un singur strat și păstrați dovezile

Salvați valorile de registru pe care le modificați, notați lista de adaptoare și filtre înainte și după, și reporniți între încercări. Repornirea face parte din reparație pentru fiecare familie aici, pentru că stackul adaptorului este construit la pornire, iar repornirea unui serviciu nu îl reconstruiește.

Reinstalați clientul doar după ce adaptorul, filtrele și miniporturile vechi au dispărut. Instalarea unui client nou peste un stack stricat este felul în care un 27850 reparabil devine o mașină cu două adaptoare pe jumătate înregistrate și fără o eroare clară. Opriți-vă și escaladați când aceeași eroare supraviețuiește de două ori verificării specifice stratului. În acel moment pasul următor util este o revizuire curată a stackului de rețea împreună cu jurnalul instalării de la furnizor, nu o altă încercare a aceleiași reinstalări.