27850, 442 i 651: una pila, tres comprovacions inicials

L’instal·lador s’atura amb 27850, una connexió es rebutja amb 442 i un altre perfil retorna 651. Els números semblen tres avaries independents, i la reacció habitual és reinstal·lar el client tres vegades. Però vénen d’un sol subsistema: l’adaptador virtual i la pila de filtres que l’envolta. El número d’error indica quina capa ha fallat, i això decideix la primera comprovació. Reinstal·lar abans de llegir-lo sol reproduir la mateixa avaria.

Relacioneu el número amb la capa

Cada error sorgeix en un punt diferent, així que la primera comprovació canvia encara que el símptoma visible sigui la mateixa connexió rebutjada. Tres famílies cobreixen tots els casos: l’instal·lador, l’adaptador i el port que hi ha a sota. La taula següent posa cada número al costat de la comprovació que implica.

Si l’error apareix abans de triar cap perfil, pertany a la família de l’instal·lador. Si apareix quan el client intenta aixecar l’adaptador, és de la família de l’adaptador. Si l’adaptador és visible i el port no s’obre mai, és de la família del miniport. Anoteu el número abans de canviar res. Les tres reparacions toquen parts diferents de la pila, i un canvi fet per a la família equivocada fa més difícil de llegir el proper intent.

Una pila de filtres plena o un paquet de seguretat que bloqueja el controlador

Instal·lar el client registra un petit component de filtre a la cadena de l’adaptador. Windows té un sostre dur de quants components d’aquest tipus es poden enllaçar, i el valor per defecte deixa poc marge quan hi ha antivirus, un pont de virtualització i un controlador de captura. Llavors la instal·lació falla amb 27850 tot i que el paquet VPN és correcte. L’instal·lador no distingeix una pila plena d’una de trencada.

Llegiu el valor actual, apugeu-lo i reinicieu abans de tornar-ho a provar. Un filtre nou no es pot enllaçar fins que la pila s’hagi reconstruït:

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

L’altra causa és un paquet de seguretat que bloqueja la instal·lació del controlador sense cap avís visible. La seva autodefensa pot impedir que el filtre es registri, i llavors l’instal·lador informa d’una fallada genèrica de component. Reviseu el registre propi del paquet i, si l’autodefensa és l’obstacle, desactiveu-la només durant la instal·lació i restaureu-la tot seguit. Si el valor ja és més alt i cap paquet no bloqueja, busqueu controladors de filtre orfes d’un producte VPN anterior. Un filtre antic que ja no té cap servei associat encara ocupa una posició i pot fer fallar la instal·lació nova.

L’adaptador hi és i es queda avall

L’error 442 vol dir que l’adaptador virtual hi és i que el client no el pot aixecar. La primera comprovació és el Gestor de dispositius amb els dispositius ocults visibles: un adaptador desactivat, un adaptador amb senyal d’avís i un adaptador absent es veuen iguals al client però necessiten reparacions diferents. Internet Connection Sharing sovint el reté. Si el servei ha ocupat l’adaptador, atureu el servei i torneu-ho a provar abans de tocar el registre. Una configuració de compartició romanent el pot tornar a ocupar després d’un reinici, així que anoteu si la correcció sobreviu al reinici.

Una reinstal·lació pot deixar un nom de visualització malmès que fa l’adaptador ingovernable. El valor ha de ser text pla, no un testimoni d’instal·lador sense resoldre:

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"

Feu servir el nom de visualització que espera el vostre client i després reinicieu perquè l’adaptador es torni a enumerar. Fixar el valor sense reiniciar sol deixar l’estat antic al seu lloc i la connexió següent torna a donar 442.

El port de sota no s’obre mai

L’error 651 es notifica quan el gestor de connexions no pot obrir el miniport WAN. L’adaptador pot semblar sa al client mentre el port de sota no arriba mai a l’estat iniciat. Llisteu els miniports i el seu estat abans de reinstal·lar res:

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

Un miniport amb estat d’error és la pista directa. Reinstal·lar-lo des del Gestor de dispositius recrea el port, i per això aquesta reparació funciona quan la reinstal·lació del client no ho fa. Els controladors de tercers enllaçats a l’adaptador físic són l’altra causa habitual. Un controlador de xarxa en pont de VirtualBox, un controlador TAP romanent d’OpenVPN o un filtre de captura poden ocupar el port primer. Desmarcar el component durant una instal·lació no n’hi ha prou quan el controlador ja està enllaçat; cal treure’l de les propietats de l’adaptador o desinstal·lar-lo del magatzem de controladors.

Desactivar IPv6 a la connexió VPN ha resolt aquest error en algunes compilacions, però tracteu-ho com una prova i no com un disseny permanent. Si la connexió només arrenca amb IPv6 desactivat, el miniport o el controlador subjacent continua sent la causa.

Canvieu una capa i conserveu les proves

Guardeu els valors de registre que canvieu, anoteu la llista d’adaptadors i filtres abans i després, i reinicieu entre intents. El reinici forma part de la reparació per a cada família aquí, perquè la pila de l’adaptador es construeix en arrencar i reiniciar un servei no la reconstrueix.

Reinstal·leu el client només quan l’adaptador, els filtres i els miniports antics hagin desaparegut. Instal·lar un client nou sobre una pila trencada és com un 27850 reparable es converteix en una màquina amb dos adaptadors mig registrats i cap error clar. Atureu-vos i escaleu quan el mateix error sobrevisqui dues vegades a la comprovació específica de la capa. En aquest punt el següent pas útil és una revisió neta de la pila de xarxa amb el registre de l’instal·lador del proveïdor, no un altre intent de la mateixa reinstal·lació.