Задачи VPN, восстанавливающие файл hosts, стирают последующие правки

Задача подключения копирует файл hosts Windows, добавляет один частный адрес, а задача отключения копирует сохранённую версию обратно. Это работает неделями, а потом однажды днём машина не может открыть внутренний сайт, не имеющий никакого отношения к VPN. Восстановление сделало ровно то, что ему велели: вернуло файл времён до чужой правки. Ошибка в модели, а не в команде копирования.

Любой процесс, который снимает снимок общего файла и позже его восстанавливает, наследует каждое сделанное между этим изменение как потерю.

Резервная копия, восстановленная позже, не является копией настоящего

Пройдите обычную последовательность. Задача сохраняет файл и дописывает запись для туннеля. Позже администратор добавляет не связанную с этим правку, а второй профиль добавляет свою запись. При отключении восстановление возвращает исходный снимок, удаляя и запись второго профиля, и правку администратора. Ни то, ни другое не принадлежало VPN, и теперь обоих нет.

Одно фиксированное имя файла резервной копии всё ухудшает. Следующее событие подключения может скопировать уже изменённый файл поверх якобы исходного, и база восстановления смещается к тому виду файла, который был при последнем событии.

Каждое событие это уведомление, а не транзакция

Задача, запускаемая событием, это уведомление. Повторное подключение, прерванное выключение или второй профиль могут перестроить требуемое состояние, пока предыдущая задача ещё пишет. Ничто не сериализует эти две, и ничто не откатывает недоделанное изменение. Кроме того, один идентификатор события без поставщика и его данных не говорит, к какому профилю он относится. Отношение к задаче как к транзакции это допущение, которое подводит.

Повторяющиеся события подключения это вторая половина: добавление без проверки создаёт вторую такую же запись, и некоторые резолверы тогда видят два ответа на одно имя.

Дайте каждому сопоставлению владельца

Каждая строка в файле hosts сопоставляет имя хоста адресу и ничего не говорит о том, какой туннель поднят. Если автоматизации не избежать, назначьте одного владельца для сопоставлений, которыми управляет VPN. Этот владелец должен обновлять только свои записи, сохранять не связанное с ними текущее содержимое, избегать дублей при повторном событии и сверяться с теми соединениями, которые действительно активны, а не с запомненным списком.

Когда двум живым туннелям нужно одно и то же сопоставление, одно отключение не должно удалять его, пока другому владельцу оно ещё нужно. Это требует подсчёта ссылок или явной записи о владении, а не логического значения.

Резервная копия всё ещё полезна для проверенного восстановления. Она не должна быть обычным действием при отключении и не должна быть единственной записью о том, что было в файле.

Когда условный DNS это настоящая потребность

Если настоящее требование это частное пространство имён, которое разрешается только пока туннель поднят, hosts неподходящий механизм. Windows NRPT может выбрать резолвер для пространства имён, и она не создаёт саму запись адреса; резолвер всё равно должен ответить. Это другая конструкция с другим владельцем, и она полностью убирает правку файла при каждом переходе.

Если hosts сохраняют намеренно для одной фиксированной службы, убедитесь, что её адрес остаётся достижимым по предполагаемому маршруту, а имя хоста остаётся стабильным, чтобы проверки идентичности приложения продолжали работать. Очистка кеша DNS не может исправить устаревшую запись, которую следующий запрос прочитает снова.

Проверьте повторные подключения, два одновременных профиля и отключение после не связанной с ними правки. Результатом должно быть то, что сопоставление VPN следует за своим владельцем, не откатывая остальную машину назад.