VPN задачи, които възстановяват файла hosts, изтриват по-късни промени

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

Всеки работен процес, който прави снимка на споделен файл и после го възстановява, наследява всяка направена междувременно промяна като загуба.

Архивно копие, възстановено по-късно, не е копие на сегашното състояние

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

Едно фиксирано име на архивен файл влошава нещата. По-късно събитие за свързване може да копира вече променения файл върху уж оригинала, така че базата за възстановяване се измества към вида на файла при последното събитие.

Всяко събитие е известие, не транзакция

Задачата, задействана от събитие, е известие. Повторно свързване, прекъснато изключване или втори профил могат да преоформят нужното състояние, докато по-ранна задача още пише. Нищо не сериализира двете и нищо не връща назад недовършена промяна. Освен това един идентификатор на събитие не казва към кой профил принадлежи без доставчика и неговите данни. Третирането на задачата като транзакция е предположението, което се проваля.

Повтарящите се събития за свързване са другата половина: добавяне без проверка създава втори идентичен запис и някои резолвери тогава виждат два отговора за едно име.

Дайте на всяко съответствие собственик

Всеки ред във файла hosts съпоставя име на хост с адрес и не казва нищо за това кой тунел е активен. Ако автоматизацията е неизбежна, назначете един собственик за съответствията, управлявани от VPN. Този собственик трябва да обновява само своите записи, да запазва несвързаното текущо съдържание, да избягва дубликати при повторно събитие и да се сверява с връзките, които действително са активни, а не със запомнен списък.

Когато два живи тунела се нуждаят от едно и също съответствие, едно прекъсване не бива да го премахва, докато другият собственик още го изисква. Това изисква броене на препратки или явен запис за собственост, а не булева стойност.

Архивното копие все още има стойност за прегледано възстановяване. То не бива да е нормалното действие при прекъсване и не бива да е единственият запис за това какво е съдържал файлът.

Когато условният DNS е истинската нужда

Ако действителното изискване е частно именно пространство, което се решава само докато тунелът е активен, hosts е грешният механизъм. Windows NRPT може да избере резолвер за именно пространство и тя не създава сама записа за адреса; резолверът все още трябва да отговори. Това е различна архитектура с различен собственик и тя премахва изцяло редактирането на файла при всеки преход.

Ако hosts се пази нарочно за една фиксирана услуга, уверете се, че адресът ѝ остава достъпен по предвидения маршрут, а името на хоста остава стабилно, за да продължат да работят проверките за идентичност на приложението. Изчистването на DNS кеша не може да поправи остарял запис, който следващото търсене прочете отново.

Тествайте повторни свързвания, два едновременни профила и прекъсване след несвързана промяна. Резултатът трябва да е, че съответствието на VPN следва своя собственик, без да превърта назад останалата част от машината.