Erro L2TP/IPsec 789, 720 ou 691: corrija primeiro a fase certa

O Windows 11 relata um número diferente para cada fase do L2TP/IPsec, e esse número marca uma fase em vez de avaliar a falha. O 789 falha antes de o vínculo PPP existir, o 720 falha enquanto o vínculo é levantado, e o 691 falha depois de o vínculo estar ativo e as credenciais serem rejeitadas. A decisão útil não é qual correção é mais popular; é qual fase o código prova que você alcançou. Leia isso primeiro e depois mude uma camada por tentativa, para que o próximo código ainda lhe diga algo.

Leia o código como uma fase, não como uma lista de falhas

Uma conexão L2TP atravessa três fronteiras numa ordem fixa. O IKE negocia associações de segurança sobre UDP 500, a travessia NAT move esse tráfego para UDP 4500, e só então o túnel L2TP transporta uma sessão PPP que autentica o usuário e atribui um endereço.

Essa ordem é a razão pela qual um código de erro que muda é uma prova útil. Passar de 789 para 720 significa que o IPsec já negocia e que a falha passou para a configuração do vínculo. Passar de 720 para 691 significa que o vínculo subiu e que o gateway rejeitou a identidade. Se aplicar cinco correções de uma vez, perde esse sinal e não consegue dizer qual mudança funcionou.

789: escolha entre o caminho e a política local

O código 789 é um erro de processamento durante as negociações de segurança iniciais. O IPsec nunca produziu uma associação utilizável, portanto a conta ainda não foi testada. Comece pelo caminho e pela chave compartilhada, não pela conta.

Confirme que UDP 500 e UDP 4500 chegam ao servidor e que a chave pré-compartilhada coincide byte a byte, incluindo maiúsculas e espaços finais. Se o servidor estiver atrás de NAT, o Windows também pode precisar do valor de registo documentado. Use 1 quando o servidor estiver atrás de NAT e 2 quando ambos os extremos estiverem, depois reinicie, porque o agente de políticas lê o valor no arranque:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

A reparação mais pesada do adaptador pertence ao outro ramo. Remover o dispositivo Wi-Fi e as miniportas WAN e depois verificar novamente o hardware justifica-se quando a própria pilha IPsec local está danificada e outros tipos de VPN falham da mesma forma. É esforço desperdiçado quando apenas um servidor L2TP falha enquanto todos os outros caminhos de rede funcionam.

720: escolha entre este adaptador e o conjunto de servidores

O erro 720 informa que a conexão ao computador remoto não pôde ser estabelecida, e aparece depois de o IPsec ter sucesso. O túnel chegou ao ponto de levantar uma interface ou obter um endereço e depois parou. Isso torna-o uma questão de adaptador local ou de capacidade do servidor.

Use o raio de impacto para decidir. Uma única máquina Windows a falhar aponta para uma miniporta WAN defeituosa, um serviço Remote Access parado ou um perfil de conexão corrompido. Vários clientes a falhar ao mesmo tempo apontam para o servidor: um conjunto de endereços esgotado, um serviço RRAS parado ou um conjunto que já não corresponde à sub-rede do cliente. Corrija o lado que o padrão indica antes de mudar o outro.

No ramo de um único cliente, remova as miniportas WAN uma vez e verifique as alterações de hardware, depois reinicie e tente novamente. No ramo do servidor, verifique o conjunto e o estado do serviço em vez do cliente, porque reinstalar um adaptador que funciona não pode criar um endereço que o servidor não tem.

691: escolha entre a credencial e um auxiliar parado

O código 691 é uma rejeição de autenticação, e é o código mais frequentemente mal interpretado como palavra-passe errada. O túnel está ativo, o gateway viu uma identidade e rejeitou-a. A causa ainda pode estar fora do campo da palavra-passe.

Verifique primeiro o campo de domínio, depois os caracteres exatos da palavra-passe. Uma palavra-passe com um espaço, aspas ou um carácter especial da shell pode ser corrompida antes de chegar ao servidor; no Linux, pppd relata a mesma rejeição que E=691 para um valor sem aspas ou um domínio em falta. Escreva novamente o segredo em vez de o colar, e apague qualquer credencial guardada que possa conter um valor antigo.

O ramo que as pessoas perdem é um serviço auxiliar parado. Quando um cliente de um fornecedor depende do seu próprio serviço para passar credenciais ao gateway, um serviço desativado ou bloqueado produz 691 mesmo quando a palavra-passe está correta. Verifique o estado do serviço do fornecedor antes de repor a conta, especialmente depois de um reinício ou de uma atualização.

Para separar os ramos, teste o mesmo nome de utilizador noutro perfil VPN funcional ou numa conta de teste RADIUS. Se isso funcionar, a credencial está bem e o caminho local do cliente é suspeito. Se falhar da mesma forma, o problema é a conta ou a política do gateway.

Mude uma camada por tentativa

Trabalhe de fora para dentro: acessibilidade e travessia NAT, depois a chave pré-compartilhada, depois a pilha do adaptador local, depois a credencial, depois o conjunto de servidores e os serviços. Essa ordem segue as fases que os códigos descrevem e mantém cada resultado atribuível a uma única mudança.

Mantenha um registo curto do código antes e depois de cada tentativa, da compilação do cliente e de se o servidor ou o cliente foi alterado. Uma sequência como 789, depois 720, depois 691 é um mapa do progresso; o mesmo código duas vezes significa que a última mudança não tratou dessa fase. Reinstalar o Windows apaga este mapa e raramente corrige uma falha que vive no gateway.

Quando o código deixar de mudar, pare de mudar coisas. Registe o código atual, o endereço do servidor, o método de autenticação e a hora da tentativa, depois compare esse registo com um cliente que funcione. A diferença entre os dois registos é normalmente menor do que a lista de correções que as pessoas experimentam por predefinição.