Códigos de erro de VPN en Windows: que etapa fallou e que rexistrar

Abra o diálogo de VPN de Windows tras un fallo e daralle un número e unha frase, e a frase adoita ser a metade menos útil. O número identifica que etapa da conexión fallou, e a etapa determina que rexistro, que axuste e que equipo mirar a continuación. Percorrer as etapas en orde leva uns dez minutos e evita a secuencia habitual de reinstalar adaptadores, cambiar protocolos e reiniciar a pila para arranxar unha conta á que nunca se lle permitiu marcar.

Lea o número como unha etapa

Unha conexión nativa pasa por catro fitos. Chega ao servidor e establece un enlace, negocia a seguridade, autentica o usuario e aplica direccionamento e encamiñamento. Un fallo en cada un deles deixa probas distintas, e un código que pertence a unha etapa non di nada útil sobre as demais.

O erro que hai que evitar é tratar o código como unha gravidade. Un fallo de enlace e un fallo de autorización len ambos como "non se puido conectar", e non teñen nada máis en común. A gravidade di canto é urxente algo; a etapa di que abrir.

Etapa un: o enlace e o intento de marcación

829 significa que o enlace subxacente caeu. Non di se o par remoto deixou de responder, se un elemento intermedio matou a sesión ou se unha política do cliente a pechou. Un código de final de marcación como 703 é aínda máis temperán: o intento nunca chegou a ter enlace, o que adoita apuntar ao perfil, ao estado do servizo ou a unha política local.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

A consulta de eventos é a parte que a xente salta. Un rexistro do lado do cliente cunha marca de tempo e un nome de interface vale máis que o diálogo, porque di se o intento sequera saíu da máquina. Ningún rexistro e ningunha resposta do oínte é un problema de alcance, e ningunha edición do cliente o cambia.

Se o mesmo perfil funciona noutra rede, detéñase aquí. O código describe unha condición da ruta e non un erro de configuración, e a seguinte comparación útil son as dúas capturas e non outra reinstalación.

Etapa dous: PPP e o enlace do miniporto

720 sitúase entre o enlace e o usuario. O túnel levantouse e logo a capa PPP non puido negociar un enderezo nin un protocolo de control, o que a miúdo é un problema de enlace no cliente e non unha credencial rexeitada. Esa distinción é todo o valor do código: di que a credencial nunca se alcanzou, así que a conta non é o sospeitoso.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Ler esas dúas saídas é máis informativo que reiniciar calquera cousa. Un miniporto que está presente pero non se iniciou, ou un enlace de protocolo desactivado por outro software, producen exactamente o fallo desta etapa. Ambos se poden arranxar sen tocar o resto da pila. Un reinicio completo, en cambio, elimina direccionamento e estado de filtrado que non tiñan nada que ver co fallo.

Etapa tres: identidade e autorización

691 significa que se rexeitaron as credenciais. 649 significa que a conta non ten permiso para marcar, e 812 significa que unha política de acceso remoto rexeitou a conexión. Son decisións, non fallos de transporte, e o cliente só pode notificalas.

As probas están no outro lado. Pida ao operador da pasarela o intento desa marca de tempo e a política que coincidiu; pregunte ao propietario do directorio se a conta ten permiso de marcación e se está no grupo que esixe a política. Cambiar o tipo de túnel ou reinstalar o cliente non pode alterar unha decisión tomada sobre unha identidade.

Un hábito útil nesta etapa é escribir a cadea exacta da conta no ticket, incluído calquera prefixo de dominio. Unha cantidade sorprendente de casos 691 son credenciais gardadas para o dominio equivocado, e iso vese na cadea da conta e non nos axustes do protocolo.

Etapa catro: conectado, e nada funciona

Unha conexión pode completarse e seguir sendo inútil. Ten un enderezo, o cliente informa de éxito e cada petición da aplicación caduca. Nada no diálogo reflicte iso, e non hai código que consultar. Nese punto o diálogo rematou e as probas útiles están noutro sitio.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Se falta a ruta, o servidor non a empurrou ou o cliente descartouna. Se a ruta existe e o nome falla, o problema é a resolución. Se ambos funcionan e a aplicación segue fallando, pasou o túnel e está na configuración da propia aplicación.

Manteña os cambios nunha capa por proba. Cada edición antes do seguinte intento pasa a formar parte do contexto do seguinte código, e un código que describe a súa última edición é peor que ningún código.

Un intento, un cambio, un rexistro

Sexa cal sexa a etapa, o rexistro debe conter o código, a mensaxe, o nome do perfil, a marca de tempo e a rede na que estaba. Cinco campos, e cada un deles xa está diante de vostede no diálogo ou no rexistro do cliente. Ese conxunto é o bastante pequeno para pegalo nun ticket e o bastante concreto para que outra persoa o reproduza.

Despois poña esa marca de tempo xunto ao rexistro do outro lado. A táboa preto da parte superior desta páxina di que etapa posúe cada discrepancia. Sen o segundo rexistro o código só estreita a busca; con el, a etapa queda decidida. A comparación é o que converte un número nun diagnóstico e non nunha conxectura.

Ese hábito cobre case calquera fallo nativo de VPN en Windows, e ningunha das ramas require reinstalar nada. O diálogo sempre lle dicía cal tiña; o traballo está en negarse a tratalos todos como o mesmo problema.