Zadania VPN przywracające plik hosts usuwają późniejsze zmiany

Zadanie połączenia kopiuje plik hosts systemu Windows, dopisuje jeden adres prywatny, a zadanie rozłączenia kopiuje zapisaną wersję z powrotem. Działa tygodniami, a potem pewnego popołudnia maszyna nie dociera do wewnętrznej strony, która nie ma nic wspólnego z VPN. Przywrócenie zrobiło dokładnie to, co mu polecono: wstawiło plik sprzed czyjejś zmiany. Błąd leży w modelu, nie w poleceniu kopiowania.

Każdy przepływ pracy, który robi migawkę współdzielonego pliku, a później ją przywraca, dziedziczy każdą zmianę wykonaną pomiędzy jako stratę.

Kopia przywrócona później nie jest kopią teraźniejszości

Przejdź zwykłą sekwencję. Zadanie zapisuje plik i dopisuje wpis dla tunelu. Później administrator dodaje niepowiązaną poprawkę, a drugi profil dodaje własny wpis. Przy rozłączeniu przywrócenie wstawia pierwotną migawkę, usuwając zarówno wpis drugiego profilu, jak i poprawkę administratora. Żadne z nich nie należało do VPN, a oba teraz zniknęły.

Jedna stała nazwa pliku kopii pogarsza sprawę. Późniejsze zdarzenie połączenia może skopiować już zmieniony plik na domniemany oryginał, więc podstawa odzyskiwania dryfuje w stronę wyglądu pliku z ostatniego zdarzenia.

Każde zdarzenie jest powiadomieniem, nie transakcją

Zadanie wyzwalane zdarzeniem jest powiadomieniem. Ponowne połączenie, przerwane wyłączenie lub drugi profil mogą przekształcić wymagany stan, podczas gdy wcześniejsze zadanie jeszcze zapisuje. Nic nie serializuje tych dwóch, i nic nie wycofuje połowicznej zmiany. Sam identyfikator zdarzenia też nie mówi, do którego profilu należy, bez dostawcy i jego danych. Traktowanie zadania jak transakcji to założenie, które zawodzi.

Powtarzające się zdarzenia połączenia to druga połowa: dopisanie bez sprawdzenia tworzy drugi identyczny wpis, a niektóre resolvery widzą wtedy dwie odpowiedzi dla jednej nazwy.

Daj każdej mapie właściciela

Każdy wiersz pliku hosts mapuje nazwę hosta na adres i nie mówi nic o tym, który tunel jest aktywny. Jeśli automatyzacji nie da się uniknąć, wyznacz jednego właściciela map zarządzanych przez VPN. Ten właściciel powinien aktualizować tylko własne wpisy, zachowywać niepowiązaną bieżącą treść, unikać duplikatów przy powtórzonym zdarzeniu i uzgadniać stan z połączeniami, które naprawdę są aktywne, a nie z zapamiętaną listą.

Gdy dwa aktywne tunele potrzebują tej samej mapy, jedno rozłączenie nie może jej usunąć, dopóki drugi właściciel jej jeszcze potrzebuje. Wymaga to liczenia odwołań albo jawnego rekordu własności, a nie wartości logicznej.

Kopia nadal ma wartość do sprawdzonego odzyskiwania. Nie powinna być zwykłą czynnością przy rozłączeniu i nie powinna być jedynym zapisem tego, co zawierał plik.

Gdy warunkowy DNS jest prawdziwą potrzebą

Jeśli rzeczywistym wymaganiem jest prywatna przestrzeń nazw, która rozwiązuje się tylko wtedy, gdy tunel jest aktywny, hosts jest niewłaściwym mechanizmem. Windows NRPT potrafi wybrać resolver dla przestrzeni nazw, a sama nie tworzy rekordu adresu; resolver i tak musi odpowiedzieć. To inny projekt z innym właścicielem, i całkowicie usuwa edytowanie pliku przy każdym przejściu.

Jeśli hosts jest celowo utrzymywany dla jednej stałej usługi, upewnij się, że jej adres pozostaje osiągalny przez zamierzoną trasę, a nazwa hosta pozostaje stabilna, aby kontrole tożsamości aplikacji nadal działały. Wyczyszczenie pamięci podręcznej DNS nie naprawi nieaktualnego wpisu, który następne wyszukiwanie odczyta ponownie.

Sprawdź powtarzane połączenia, dwa jednoczesne profile i rozłączenie po niepowiązanej zmianie. Wynikiem powinno być to, że mapa VPN podąża za swoim właścicielem bez przewijania reszty maszyny wstecz.