VPN Tasks That Restore the Hosts File Erase Later Edits

A connect task copies the Windows hosts file, appends one private address, and a disconnect task copies the saved version back. It works for weeks and then one afternoon the machine cannot reach an internal site that has nothing to do with the VPN. The restore did exactly what it was told: it put back a file from before somebody else's edit. The failure is in the model, not in the copy command.

Any workflow that snaps a shared file and later restores it inherits every change made in between as a loss.

A Backup Restored Later Is Not a Backup of Now

Walk through an ordinary sequence. The task saves the file and appends an entry for the tunnel. Later an administrator adds an unrelated correction, and a second profile adds its own entry. On disconnect the restore puts back the original snapshot, removing both the second profile's entry and the administrator's correction. Neither belonged to the VPN, and both are now gone.

A single fixed backup filename makes it worse. A later connect event can copy the already-modified file over the supposed original, so the recovery baseline drifts toward whatever the file looked like at the last event.

Every Event Is a Notification, Not a Transaction

An event-triggered task is a notification. A reconnect, a shutdown cut short or a second profile can reshape the required state while an earlier task is still mid-write. Nothing serializes the two, and nothing rolls back a half-finished change. An event identifier alone also does not say which profile it belongs to without the provider and its data. Treating the task as a transaction is the assumption that fails.

Repeated connect events are the other half: an append without a check creates a second identical entry, and some resolvers then see two answers for one name.

Give Each Mapping an Owner

Every line in the hosts file maps a hostname to an address and says nothing about which tunnel is up. If automation is unavoidable, assign one owner for the VPN-managed mappings. That owner should update only its own entries, preserve unrelated current content, avoid duplicates on a repeated event, and reconcile against the connections that are actually active rather than against a remembered list.

When two live tunnels need the same mapping, a single disconnect must not remove it while the other owner still needs it. That requires reference counting or an explicit ownership record, not a boolean.

A backup still has value for reviewed recovery. It should not be the normal disconnect action, and it should not be the only record of what the file contained.

When Conditional DNS Is the Real Need

If the actual requirement is a private namespace that resolves only while the tunnel is up, hosts is the wrong mechanism. Windows NRPT can select a resolver for a namespace, and it does not create the address record itself; a resolver still has to answer. That is a different design with a different owner, and it removes the per-transition file editing entirely.

If hosts is kept on purpose for a single fixed service, make sure its address stays reachable over the intended route and its hostname stays stable so application identity checks keep working. Clearing a DNS cache cannot repair a stale entry the next lookup reads again.

Test repeated connects, two simultaneous profiles and a disconnect after an unrelated edit. The result should be that the VPN's mapping follows its owner without rewinding the rest of the machine.