Las tareas de VPN que restauran el archivo hosts borran las ediciones posteriores

Una tarea de conexión copia el archivo hosts de Windows, añade una dirección privada, y una tarea de desconexión vuelve a copiar la versión guardada. Funciona durante semanas y luego una tarde la máquina no llega a un sitio interno que no tiene nada que ver con la VPN. La restauración hizo exactamente lo que se le ordenó: devolvió un archivo anterior a la edición de otra persona. El fallo está en el modelo, no en el comando de copia.

Cualquier flujo de trabajo que capture un archivo compartido y luego lo restaure hereda cada cambio hecho mientras tanto como una pérdida.

Una copia restaurada más tarde no es una copia del ahora

Recorra una secuencia corriente. La tarea guarda el archivo y añade una entrada para el túnel. Más tarde un administrador añade una corrección no relacionada, y un segundo perfil añade su propia entrada. Al desconectar, la restauración devuelve la instantánea original y elimina tanto la entrada del segundo perfil como la corrección del administrador. Ninguna de las dos pertenecía a la VPN, y ambas han desaparecido.

Un único nombre de archivo de copia fijo lo empeora. Un evento de conexión posterior puede copiar el archivo ya modificado sobre el supuesto original, de modo que la base de recuperación se desplaza hacia el aspecto que tenía el archivo en el último evento.

Cada evento es una notificación, no una transacción

Una tarea activada por un evento es una notificación. Una reconexión, un apagado interrumpido o un segundo perfil pueden reformar el estado requerido mientras una tarea anterior todavía está escribiendo. Nada serializa las dos, y nada revierte un cambio a medio terminar. Además, un identificador de evento por sí solo no dice a qué perfil pertenece sin el proveedor y sus datos. Tratar la tarea como una transacción es la suposición que falla.

Los eventos de conexión repetidos son la otra mitad: añadir sin comprobar crea una segunda entrada idéntica, y algunos resolutores ven entonces dos respuestas para un nombre.

Dé a cada asignación un propietario

Cada línea del archivo hosts asigna un nombre de host a una dirección y no dice nada sobre qué túnel está activo. Si la automatización es inevitable, asigne un solo propietario para las asignaciones gestionadas por la VPN. Ese propietario debería actualizar solo sus propias entradas, preservar el contenido actual no relacionado, evitar duplicados en un evento repetido y reconciliarse con las conexiones que están realmente activas y no con una lista recordada.

Cuando dos túneles activos necesitan la misma asignación, una sola desconexión no debe eliminarla mientras el otro propietario aún la necesita. Eso exige conteo de referencias o un registro explícito de propiedad, no un booleano.

Una copia todavía tiene valor para una recuperación revisada. No debería ser la acción normal al desconectar, ni debería ser el único registro de lo que contenía el archivo.

Cuando el DNS condicional es la necesidad real

Si el requisito real es un espacio de nombres privado que solo resuelve mientras el túnel está activo, hosts es el mecanismo equivocado. Windows NRPT puede elegir un resolutor para un espacio de nombres, y no crea el registro de dirección por sí misma; un resolutor sigue teniendo que responder. Ese es un diseño distinto con un propietario distinto, y elimina por completo la edición del archivo en cada transición.

Si hosts se mantiene a propósito para un único servicio fijo, asegúrese de que su dirección siga siendo alcanzable por la ruta prevista y de que su nombre de host siga siendo estable para que las comprobaciones de identidad de la aplicación sigan funcionando. Borrar una caché de DNS no puede reparar una entrada obsoleta que la siguiente consulta volverá a leer.

Pruebe conexiones repetidas, dos perfiles simultáneos y una desconexión tras una edición no relacionada. El resultado debería ser que la asignación de la VPN siga a su propietario sin rebobinar el resto de la máquina.