Mantenga activa una VPN de Windows: dispare rasdial en el evento de desconexión

Windows no ofrece ninguna política de remarcado para su cliente VPN, así que una conexión que se cae a medianoche sigue caída en el desayuno. Una tarea programada que vigila la desconexión y ejecuta rasdial cierra ese hueco sin un cliente de terceros. Que la tarea se comporte como un operador o como un bucle se reduce a tres detalles: qué eventos empareja, qué credencial puede ver y qué hace con el resultado. Ninguno de los tres es difícil, y omitir cualquiera de ellos es lo que produce una tarea que marca para siempre.

Por qué un temporizador es el desencadenador equivocado

Un temporizador marca según su propio horario, tanto si el túnel está caído como si no. Eso produce intentos que nadie necesitaba, y un intento durante una sesión de trabajo puede interrumpirla. Un desencadenador de evento solo se activa cuando la conexión cambia de estado, lo que es más barato y más fácil de razonar. El evento también lleva el motivo, y el motivo es lo que separa un fallo de red de una persona que se desconecta a propósito.

Esa distinción es la diferencia entre una tarea útil y una que se pelea con el usuario cada noche. También es la parte que suele faltar en las recetas que solo describen la acción.

El par de eventos y el que hay que suprimir

El cliente del Servicio de acceso remoto escribe registros de ciclo de vida en el registro Application bajo el proveedor RasClient. 20226 marca una conexión que terminó, y 20227 marca un intento que falló, así que cualquiera de los dos puede justificar una nueva marcación. Todo lo demás en la tarea depende de emparejar esos dos identificadores exactamente. Han sido estables durante años, por eso las recetas construidas sobre ellos siguen circulando, pero una compilación que renombra el proveedor o los identificadores hace que la consulta no devuelva nada. Vuelva a ejecutar el paso de prueba después de cada actualización de función en lugar de esperar a que la tarea deje de dispararse.

Hay que excluir una terminación. El error 631 significa que el usuario desconectó el puerto, y una remarcación en ese momento se pelea con la persona que acaba de cambiar de red a propósito. Ponga la exclusión en el filtro del desencadenador y no en el script, para que la tarea no arranque en absoluto. Tiene que aplicarse a un solo identificador de evento, porque un predicado EventData solo coincide cuando existe el elemento nombrado, y una cláusula compartida descartaría en silencio todos los eventos del otro identificador. Lea el nombre del elemento de un registro real antes de escribir el filtro:

Get-WinEvent -LogName Application -MaxEvents 5 -FilterXPath "*[System[Provider[@Name='RasClient'] and EventID=20226]]" | Select-Object -First 1 -ExpandProperty ToXml

El XML muestra los nombres exactos de Data en ese registro. ErrorCode es la ortografía habitual, y un registro que use otra cosa necesita que ese nombre se sustituya en el filtro de abajo.

<QueryList><Query Id="0" Path="Application"><Select Path="Application">*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])</Select></Query></QueryList>

Pegue eso en el filtro personalizado del desencadenador y pruébelo como consulta antes de que se convierta en un desencadenador. El mismo XPath se ejecuta desde PowerShell contra el registro en vivo, que es la forma barata de ver con qué coincide mientras el historial de tareas aún no está implicado.

Get-WinEvent -LogName Application -MaxEvents 40 -FilterXPath "*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])" | Select-Object TimeCreated,Id,Message

Un desencadenador que en silencio no coincide con nada parece exactamente una tarea que se ejecuta y falla. Ambos se presentan como «la automatización no funciona», y ninguno dice qué mitad falta. Compruebe primero la salida de la consulta, porque separa los dos casos en un solo paso.

La marcación falla porque no hay nadie para escribir la contraseña

La acción ejecuta rasdial con el nombre de la conexión. Cuando el perfil no tiene ninguna credencial en caché, la marcación falla de inmediato porque no hay nadie para responder al aviso. Es el motivo más habitual de que una tarea bien desencadenada no haga nada visible, así que compruébelo antes de tocar el desencadenador. Marcar a mano desde un símbolo del sistema separa un problema de credenciales de un problema de programación.

Guarde la credencial una vez bajo la cuenta con la que se ejecutará la tarea, y haga que esa cuenta forme parte del diseño. Una tarea que se ejecuta como SYSTEM no puede leer una credencial guardada por su cuenta interactiva, y una tarea que se ejecuta como otra persona tampoco. El nombre también debe coincidir exactamente con el perfil, incluido cualquier prefijo de dominio en el campo de usuario.

rasdial
rasdial "Office VPN"
(Start-Process rasdial -ArgumentList '"Office VPN"' -Wait -PassThru -NoNewWindow).ExitCode

El primer comando enumera los nombres que Windows conoce. El segundo marca por nombre con la credencial en caché, y el tercero es la forma que debería usar una acción de PowerShell, porque espera y devuelve un valor que la tarea puede registrar.

Lea el código de salida en lugar de la ventana

Una tarea que inicia un proceso sin esperar informa de éxito en cuanto el proceso existe. Para una marcación que puede fallar un segundo después, ese veredicto no vale nada. Esperar el código de salida convierte la acción en un resultado real. El historial de tareas por sí solo solo muestra que un proceso se inició, nunca que un túnel se levantó.

Registre el valor con una marca de tiempo en cada ejecución. Un fallo único después de una caída es normal, mientras que tres fallos seguidos con el mismo código apuntan a la credencial o al perfil y no a la red. Ese patrón es lo que hace que el historial merezca leerse.

Añada un intervalo de repetición corto como seguro, y sea explícito sobre cómo interactúa con un desencadenador de evento. Una repetición cada minuto durante cinco minutos aporta el segundo intento cuando internet volvió con el túnel, y en Configuración, «Si la tarea ya se está ejecutando, se aplica la siguiente regla», la tarea quiere «No iniciar una instancia nueva» para que una repetición no se solape con una marcación aún en curso. Sin esa configuración, dos procesos rasdial pueden competir por el mismo puerto y el segundo falla sin ningún motivo útil.

Demuestre la ruta de recuperación

Pruebe las dos direcciones a propósito. Desconecte a mano y confirme que no se produce ninguna remarcación, luego desactive el adaptador de red y confirme que la tarea se dispara cuando vuelve el enlace. Esas dos pruebas cubren la regla de supresión y el caso real de fallo, y nada más lo hace.

Después lea el historial de tareas en lugar del icono de conexión. El historial registra cuándo se ejecutó la tarea, qué cuenta usó y qué devolvió la acción, y esa es la evidencia que hace falta cuando la misma máquina vuelva a caer el mes que viene.