Un restablecimiento de red de Windows borra más que el fallo de la VPN

El consejo llega a los diez minutos de cada queja de VPN en Windows: ejecuta el restablecimiento de red, lo arregla todo. No lo hace, y no es estrecho. Ese botón limpia adaptadores, vuelve a enlazar protocolos, elimina direcciones estáticas y rutas predeterminadas, descarta entradas de firewall y filtros y, por si fuera poco, olvida perfiles de Wi-Fi. En una máquina con un túnel que funciona pero está mal configurado, convierte un fallo diagnosticable en una reconstrucción no documentada. Guarde cinco cosas primero y conservará la opción de deshacerlo.

El restablecimiento no se limita al perfil de la VPN

Una conexión VPN es un objeto entre muchos que comparten la pila de red. Quitar y volver a añadir un adaptador cambia el índice de la interfaz, y cualquier cosa que hiciera referencia a ese índice, desde una ruta hasta una regla de firewall hasta un controlador de filtro de terceros, ahora hace referencia a algo que ya no existe.

La virtualización lo empeora. Los conmutadores Hyper-V, los puentes de VMware, las redes de contenedores y los clientes VPN con sus propios adaptadores virtuales viven todos en el mismo espacio. Un restablecimiento que reinstala la pila base puede dejar esos componentes a medio presentar, y la máquina resultante informa de hardware que funciona sin ninguna ruta que funcione.

Nada de eso es un argumento contra reiniciar alguna vez. Es un argumento contra reiniciar primero, en una máquina que no ha documentado, cuando el fallo real puede ser una entrada de ruta o un filtro obsoleto. Un restablecimiento es una herramienta amplia con una tasa de éxito estrecha, y usarlo como primer movimiento garantiza que nunca sabrá cuál de las dos cosas era.

Guarde las pruebas antes de guardar la configuración

El propio fallo son datos. Anote el código de error exacto, la hora, qué perfil estaba seleccionado y si la puerta de enlace registró algún intento. Un código que dice que el túnel nunca recibió respuesta y un código que dice que la autenticación falló apuntan a reparaciones completamente distintas. Después de un restablecimiento puede que no sea capaz de reproducir ninguno de los dos. Trate el estado roto como un activo que está a punto de gastar.

Capture el estado mientras sigue roto, en una carpeta fuera de los directorios temporales de la máquina:

mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xml

El último comando es el que la gente omite, y a menudo es el que explica el fallo. Los filtros sobrantes de un cliente eliminado sobreviven como política persistente, y el XML exportado es el único registro local de ellos. Léalo antes de que un restablecimiento borre lo que estaba intentando identificar.

Guarde la configuración que no volverá

Algunos ajustes se recrean automáticamente. Las direcciones estáticas, las rutas personalizadas, los sufijos DNS, las excepciones de proxy y las reglas de firewall no. Tampoco los perfiles en sí, que viven en un archivo de libreta de teléfonos que el restablecimiento no le restaura.

Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfter

La lista de certificados importa más de lo que parece. Los certificados de cliente no los destruye un restablecimiento de red, pero la lista le dice de cuáles dependía el perfil y si alguno caduca pronto. Descubrir un certificado caducado después de una reconstrucción desperdicia la reconstrucción.

Escriba la ruta de recuperación antes de empezar

Si la máquina está remota y la VPN es su única vía de entrada, el restablecimiento puede terminar su sesión y puede que no haya vuelta sin alguien en el sitio. Confirme que existe acceso fuera de banda, o que hay una persona disponible, antes de ejecutar cualquier cosa que toque adaptadores.

Guarde los instaladores y los datos de conexión en un lugar al que la máquina aún pueda llegar después. Un cliente que hay que reinstalar desde un portal del proveedor al que se llega por el túnel es una dependencia circular, y es la forma más común de que este procedimiento se convierta en una caída del servicio.

Luego registre qué está haciendo y por qué, incluidos los comandos exactos. La siguiente persona necesita saber si el restablecimiento fue un experimento o una decisión, y “lo probamos todo” no es un registro.

Pruebe por capas después del restablecimiento

Restaurar demasiado de golpe hace ilegible el resultado. Trabaje desde abajo: adaptador y dirección, luego resolución de nombres, luego la etapa de identidad del túnel, luego la aplicación. Cada capa tiene un comando que responde a su propia pregunta:

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443

Si la capa del adaptador está sana y la resolución no, deténgase y arregle la resolución. Reinstalar el cliente VPN en ese punto añade una variable y elimina una pista. Restaure solo los ajustes que pueda explicar, uno a la vez, comprobando la misma capa después de cada uno.

La propia guía de solución de problemas de Microsoft para el error 720, por ejemplo, distingue problemas de enlace de problemas de asignación de direcciones en lugar de recetar un restablecimiento general, que es el instinto correcto para cada código de esta familia. Lea qué afirma el código antes de echar mano de la herramienta más amplia disponible.