27850, 442 e 651: unha pila, tres comprobacións iniciais

O instalador detense con 27850, unha conexión rexéitase con 442 e outro perfil devolve 651. Os números semellan tres avarías independentes, e a reacción habitual é reinstalar o cliente tres veces. Pero veñen dun só subsistema: o adaptador virtual e a pila de filtros que o rodea. O número de erro indica que capa fallou, e iso decide a primeira comprobación. Reinstalar antes de lelo adoita reproducir a mesma avaría.

Relacione o número coa capa

Cada erro xorde nun punto distinto, así que a primeira comprobación cambia aínda que o síntoma visible sexa a mesma conexión rexeitada. Tres familias cobren todos os casos: o instalador, o adaptador e o porto que hai debaixo. A táboa seguinte pon cada número xunto á comprobación que implica.

Se o erro aparece antes de escoller calquera perfil, pertence á familia do instalador. Se aparece cando o cliente tenta levantar o adaptador, é da familia do adaptador. Se o adaptador é visible e o porto non se abre nunca, é da familia do miniporto. Anote o número antes de cambiar nada. As tres reparacións tocan partes distintas da pila, e un cambio feito para a familia equivocada fai máis difícil ler o seguinte intento.

Unha pila de filtros chea ou un paquete de seguridade que bloquea o controlador

Instalar o cliente rexistra un pequeno compoñente de filtro na cadea do adaptador. Windows ten un teito duro de cantos compoñentes dese tipo poden enlazarse, e o valor predeterminado deixa pouco marxe cando hai antivirus, unha ponte de virtualización e un controlador de captura. Entón a instalación falla con 27850 aínda que o paquete VPN estea correcto. O instalador non distingue unha pila chea dunha rota.

Lea o valor actual, sóbeo e reinicie antes de tentalo de novo. Un filtro novo non pode enlazarse ata que a pila se reconstruíse:

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

A outra causa é un paquete de seguridade que bloquea a instalación do controlador sen ningún aviso visible. A súa autodefensa pode impedir que o filtro se rexistre, e entón o instalador informa dun fallo xenérico de compoñente. Revise o rexistro propio do paquete e, se a autodefensa é o obstáculo, desactívea só durante a instalación e restaúrea de inmediato. Se o valor xa está subido e ningún paquete bloquea, busque controladores de filtro orfos dun produto VPN anterior. Un filtro antigo que xa non ten un servizo asociado segue ocupando unha ranura e pode facer fallar a instalación nova.

O adaptador está e queda abaixo

O erro 442 significa que o adaptador virtual está presente e que o cliente non pode levantalo. A primeira comprobación é o Administrador de dispositivos cos dispositivos ocultos visibles: un adaptador desactivado, un adaptador cun sinal de advertencia e un adaptador ausente vense iguais no cliente pero necesitan reparacións distintas. Internet Connection Sharing adoita retelo. Se o servizo ocupou o adaptador, deteña o servizo e tente de novo antes de tocar o rexistro. Unha configuración de compartición residual pode volver ocupalo tras un reinicio, así que anote se a corrección sobrevive ao reinicio.

Unha reinstalación pode deixar un nome para mostrar malformado que volve inmanexable o adaptador. O valor debe ser texto simple, non un token de instalador sen resolver:

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"

Use o nome para mostrar que espera o seu cliente e logo reinicie para que o adaptador se enumere de novo. Fixar o valor sen reiniciar adoita deixar o estado antigo no seu sitio e a seguinte conexión volve dar 442.

O porto de abaixo nunca se abre

O erro 651 notifícase cando o xestor de conexións non pode abrir o miniporto WAN. O adaptador pode parecer san no cliente mentres o porto de abaixo nunca acada un estado iniciado. Enumere os miniportos e o seu estado antes de reinstalar nada:

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

Un miniporto con estado de erro é a pista directa. Reinstalalo desde o Administrador de dispositivos recrea o porto, e por iso esta reparación funciona cando a reinstalación do cliente non o fai. Os controladores de terceiros enlazados ao adaptador físico son a outra causa habitual. Un controlador de rede en ponte de VirtualBox, un controlador TAP residual de OpenVPN ou un filtro de captura poden ocupar o porto primeiro. Desmarcar o compoñente durante unha instalación non abonda cando o controlador xa está enlazado; hai que retiralo das propiedades do adaptador ou desinstalalo do almacén de controladores.

Desactivar IPv6 na conexión VPN resolveu este erro nalgúns builds, pero tráteo como unha proba e non como un deseño permanente. Se a conexión só arrinca con IPv6 desactivado, o miniporto ou o controlador subxacente segue sendo a causa.

Cambie unha capa e conserve as probas

Garde os valores de rexistro que cambie, anote a lista de adaptadores e filtros antes e despois, e reinicie entre intentos. O reinicio forma parte da reparación para cada familia aquí, porque a pila do adaptador constrúese ao arrincar e reiniciar un servizo non a reconstrúe.

Reinstale o cliente só cando o adaptador, os filtros e os miniportos antigos desaparecesen. Instalar un cliente novo sobre unha pila rota é como un 27850 reparábel se converte nunha máquina con dous adaptadores medio rexistrados e ningún erro claro. Detéñase e escale cando o mesmo erro sobreviva dúas veces á comprobación específica da capa. Nese punto o seguinte paso útil é unha revisión limpa da pila de rede co rexistro do instalador do provedor, non outro intento da mesma reinstalación.