VPN задачи што ја враќаат hosts-датотеката ги бришат подоцнежните измени

Задачата за поврзување ја копира hosts-датотеката во Windows, додава една приватна адреса, а задачата за исклучување ја копира зачуваната верзија назад. Работи со недели и потоа едно попладне машината не може да стигне до внатрешен сајт што нема никаква врска со VPN. Враќањето направи точно она што ѝ беше кажано: врати датотека од пред нечија туѓа измена. Грешката е во моделот, не во командата за копирање.

Секој работен тек што прави снимка од споделена датотека и подоцна ја враќа ја наследува секоја направена измена помеѓу како загуба.

Резервна копија вратена подоцна не е копија на сегашноста

Поминете низ обична низа. Задачата ја зачувува датотеката и додава запис за тунелот. Подоцна администратор додава неповрзана исправка, а втор профил додава свој запис. При исклучување враќањето ја враќа првобитната снимка, отстранувајќи го и записот на вториот профил и исправката на администраторот. Ниту едното не припаѓаше на VPN, и двете сега ги нема.

Едно фиксно име на резервната датотека го влошува тоа. Подоцнежен настан за поврзување може да ја копира веќе изменетата датотека врз наводниот оригинал, така што основата за враќање се лизга кон тоа како изгледала датотеката при последниот настан.

Секој настан е известување, не трансакција

Задачата активирана од настан е известување. Повторно поврзување, прекинато исклучување или втор профил можат да ја преобликуваат потребната состојба додека претходната задача сѐ уште пишува. Ништо не ги сериализира двете, и ништо не враќа половично завршена измена. Освен тоа, само идентификаторот на настан, без добавувачот и неговите податоци, не кажува на кој профил му припаѓа. Третирањето на задачата како трансакција е претпоставката што пропаѓа.

Повторените настани за поврзување се другата половина: додавање без проверка создава втор идентичен запис, и тогаш некои resolver-и гледаат два одговора за едно име.

Дајте на секое мапирање сопственик

Секоја линија во hosts-датотеката мапира име на домаќин на адреса и не кажува ништо за тоа кој тунел е активен. Ако автоматизацијата е неизбежна, определете еден сопственик за мапирањата што ги управува VPN. Тој сопственик треба да ги ажурира само своите записи, да ја зачува неповрзаната тековна содржина, да избегнува дупликати при повторен настан и да се усогласува со врските што навистина се активни, а не со запаметена листа.

Кога два живи тунели бараат исто мапирање, едно исклучување не смее да го отстрани додека другиот сопственик сѐ уште го бара. Тоа бара броење референции или експлицитен запис за сопственост, не логичка вредност.

Резервната копија сѐ уште има вредност за прегледано враќање. Таа не треба да биде вообичаената акција при исклучување, и не треба да биде единствениот запис за тоа што содржела датотеката.

Кога условниот DNS е вистинската потреба

Ако вистинското барање е приватен именски простор што се решава само додека тунелот е активен, hosts е погрешен механизам. Windows NRPT може да избере resolver за именски простор, и не го создава самиот записот за адреса; resolver-от сепак мора да одговори. Тоа е поинаков дизајн со поинаков сопственик, и целосно го отстранува уредувањето на датотеката при секој премин.

Ако hosts се чува намерно за една фиксна услуга, осигурајте се дека нејзината адреса останува достапна преку предвидената рута и дека името на домаќинот останува стабилно за проверките на идентитетот на апликацијата да продолжат да работат. Бришењето на DNS-кешот не може да поправи застарена записка што следното пребарување повторно ќе ја прочита.

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