27850, 442 e 651: uma pilha, três verificações iniciais

O instalador para em 27850, uma conexão é recusada com 442 e outro perfil devolve 651. Os números parecem três avarias independentes, e a reação habitual é reinstalar o cliente três vezes. Mas vêm de um único subsistema: o adaptador virtual e a pilha de filtros à sua volta. O número do erro indica qual camada falhou, e isso decide a primeira verificação. Reinstalar antes de ler o número costuma reproduzir a mesma avaria.

Relacione o número com a camada

Cada erro surge num ponto diferente, por isso a primeira verificação muda mesmo quando o sintoma visível é a mesma conexão recusada. Três famílias cobrem todos os casos: o instalador, o adaptador e a porta por baixo. A tabela abaixo coloca cada número ao lado da verificação que implica.

Se o erro aparecer antes de escolher qualquer perfil, pertence à família do instalador. Se aparecer quando o cliente tenta levantar o adaptador, é da família do adaptador. Se o adaptador estiver visível e a porta nunca abrir, é da família do miniporto. Anote o número antes de mudar qualquer coisa. As três reparações tocam em partes diferentes da pilha, e uma alteração feita para a família errada torna a tentativa seguinte mais difícil de ler.

Uma pilha de filtros cheia ou um pacote de segurança que bloqueia o controlador

Instalar o cliente regista um pequeno componente de filtro na cadeia do adaptador. O Windows tem um teto rígido para quantos componentes desses podem ligar-se, e o valor predefinido deixa pouco espaço quando há antivírus, uma ponte de virtualização e um controlador de captura. Então a instalação falha com 27850, embora o pacote VPN esteja correto. O instalador não distingue uma pilha cheia de uma avariada.

Leia o valor atual, aumente-o e reinicie antes de tentar outra vez. Um filtro novo não se pode ligar até a pilha ser reconstruída:

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 é um pacote de segurança que bloqueia a instalação do controlador sem aviso visível. A autodefesa pode impedir o filtro de se registar, e o instalador relata então uma falha genérica de componente. Veja o registo do próprio pacote e, se a autodefesa for o obstáculo, desative-a apenas durante a instalação e reponha-a logo depois. Se o valor já está aumentado e nenhum pacote bloqueia, procure controladores de filtro órfãos de um produto VPN anterior. Um filtro antigo que já não tem serviço correspondente ocupa uma vaga e pode fazer falhar a instalação nova.

O adaptador está lá e fica em baixo

O erro 442 significa que o adaptador virtual está presente e que o cliente não o consegue levantar. A primeira verificação é o Gestor de dispositivos com os dispositivos ocultos visíveis: um adaptador desativado, um adaptador com sinal de aviso e um adaptador em falta parecem iguais no cliente mas exigem reparações diferentes. O Internet Connection Sharing costuma retê-lo. Se o serviço ocupou o adaptador, pare o serviço e tente de novo antes de tocar no registo. Uma configuração de partilha residual pode voltar a ocupá-lo após um reinício, por isso anote se a correção sobrevive ao reinício.

Uma reinstalação pode deixar um nome de apresentação malformado que torna o adaptador ingovernável. O valor deve ser texto simples, não um token de instalador por 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 de apresentação que o seu cliente espera e reinicie para que o adaptador seja enumerado de novo. Definir o valor sem reiniciar deixa normalmente o estado antigo no lugar e a ligação seguinte volta a dar 442.

A porta por baixo nunca abre

O erro 651 é reportado quando o gestor de ligações não consegue abrir o miniporto WAN. O adaptador pode parecer saudável no cliente enquanto a porta por baixo nunca atinge um estado iniciado. Liste os miniportos e o seu estado antes de reinstalar seja o que for:

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

Um miniporto com estado de erro é a pista direta. Reinstalá-lo a partir do Gestor de dispositivos recria a porta, e é por isso que esta reparação funciona quando a reinstalação do cliente não funciona. Os controladores de terceiros ligados ao adaptador físico são a outra causa comum. Um controlador de rede em ponte do VirtualBox, um controlador TAP residual do OpenVPN ou um filtro de captura podem ocupar a porta primeiro. Desmarcar o componente durante uma instalação não chega quando o controlador já está ligado; tem de ser removido das propriedades do adaptador ou desinstalado do armazém de controladores.

Desativar o IPv6 na ligação VPN resolveu este erro em algumas compilações, mas trate isso como um teste e não como um desenho permanente. Se a ligação só arranca com IPv6 desativado, o miniporto ou o controlador por baixo continua a ser a causa.

Mude uma camada e guarde as provas

Guarde os valores de registo que altera, anote a lista de adaptadores e filtros antes e depois, e reinicie entre tentativas. O reinício faz parte da reparação para cada família aqui, porque a pilha do adaptador é construída no arranque e reiniciar um serviço não a reconstrói.

Reinstale o cliente só depois de o adaptador, os filtros e os miniportos antigos terem desaparecido. Instalar um cliente novo sobre uma pilha avariada é o modo como um 27850 reparável se transforma numa máquina com dois adaptadores meio registados e sem erro claro. Pare e escale quando o mesmo erro sobrevive duas vezes à verificação específica da camada. Nesse ponto o passo seguinte útil é uma revisão limpa da pilha de rede com o registo do instalador do fornecedor, não outra tentativa da mesma reinstalação.