Завдання VPN, що відновлюють файл hosts, стирають пізніші правки

Завдання підключення копіює файл hosts Windows, додає одну приватну адресу, а завдання відключення копіює збережену версію назад. Це працює тижнями, а потім одного дня по обіді машина не може відкрити внутрішній сайт, який не має жодного стосунку до VPN. Відновлення зробило рівно те, що йому наказали: повернуло файл часів до чужої правки. Помилка в моделі, а не в команді копіювання.

Будь-який процес, який знімає копію спільного файла і згодом його відновлює, успадковує кожну зроблену між цим зміну як втрату.

Резервна копія, відновлена пізніше, не є копією теперішнього

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

Одне фіксоване ім’я файла резервної копії все погіршує. Наступна подія підключення може скопіювати вже змінений файл поверх нібито початкового, і база відновлення зсувається до того вигляду файла, який був під час останньої події.

Кожна подія це сповіщення, а не транзакція

Завдання, яке запускається подією, це сповіщення. Повторне підключення, перерване вимкнення або другий профіль можуть перебудувати потрібний стан, поки попереднє завдання ще пише. Ніщо не серіалізує ці дві, і ніщо не відкочує недоладне змінення. Крім того, сам ідентифікатор події без постачальника та його даних не каже, до якого профілю він належить. Ставлення до завдання як до транзакції це припущення, яке підводить.

Повторювані події підключення це друга половина: додавання без перевірки створює другий такий самий запис, і деякі розв’язувачі тоді бачать дві відповіді на одне ім’я.

Дайте кожному зіставленню власника

Кожен рядок у файлі hosts зіставляє ім’я хоста з адресою і нічого не каже про те, який тунель піднято. Якщо автоматизації не уникнути, призначте одного власника для зіставлень, якими керує VPN. Цей власник має оновлювати лише свої записи, зберігати не пов’язаний з ними поточний вміст, уникати дублікатів під час повторної події і звірятися з тими з’єднаннями, які справді активні, а не зі запам’ятованим списком.

Коли двом живим тунелям потрібне те саме зіставлення, одне відключення не повинно його видаляти, поки іншому власнику воно ще потрібне. Це вимагає підрахунку посилань або явного запису про власність, а не логічного значення.

Резервна копія все ще корисна для перегляненого відновлення. Вона не має бути звичайною дією під час відключення і не має бути єдиним записом про те, що містив файл.

Коли умовний DNS це справжня потреба

Якщо справжня вимога це приватний простір імен, який розв’язується лише поки тунель піднято, hosts це неправильний механізм. Windows NRPT може вибрати розв’язувач для простору імен, і вона не створює саму адресний запис; розв’язувач усе одно має відповісти. Це інша конструкція з іншим власником, і вона повністю прибирає редагування файла під час кожного переходу.

Якщо hosts зберігають навмисно для однієї фіксованої служби, переконайтеся, що її адреса залишається досяжною через передбачений маршрут, а ім’я хоста залишається стабільним, щоб перевірки ідентичності застосунку продовжували працювати. Очищення кешу DNS не може виправити застарілий запис, який наступний пошук прочитає знову.

Перевірте повторні підключення, два одночасні профілі та відключення після не пов’язаної з ними правки. Результатом має бути те, що зіставлення VPN іде за своїм власником, не відкочуючи решту машини назад.