Lista dozwolonych punktów końcowych VPN: odświeżanie DNS, o którym zapomniałeś

Wpisanie vpn.example.com do wyjątku zapory wydaje się subskrypcją DNS. Zwykle dochodzi do tłumaczenia przy wczytywaniu, po czym reguła trzyma adresy i nic ich nie odświeża. Dwa komponenty dzielą teraz zadanie: resolver, który odpowiada, i zapora, która przechowuje. Większość awarii punktów końcowych zaczyna się tam, gdzie tego przekazania nigdy nie zaprojektowano.

Nazwa hosta w regule nie jest żywą subskrypcją

Niektóre narzędzia rozwiązują nazwę przy wczytywaniu konfiguracji; inne trzymają nazwę hosta i rozwiązują ją ponownie według własnego harmonogramu; jeszcze inne akceptują tylko adresy. Widoczna konfiguracja rzadko mówi, który przypadek zachodzi. Przykłady w dokumentacji zwykle zakładają przypadek wczytywania, dlatego różnica zaskakuje ludzi podczas migracji. Przeczytaj zachowanie implementacji, zanim założysz, że zmiana adresu zostanie zauważona, ponieważ nieaktualna lista dozwolonych wygląda dokładnie jak działająca dopóki punkt końcowy się nie przeniesie.

Reguła nazywająca właściwy host nadal może przepuścić niewłaściwy adres. Ta luka to mit, nie literówka.

TTL pamięci podręcznej to nie timer twojej zapory

Rekordy DNS mają czas życia, a resolverzy buforują odpowiedzi na ten okres. Specyfikacja DNS definiuje to zachowanie pamięci podręcznej, ale rządzi danymi DNS, nie osobnym magazynem adresów zapory. Krótki TTL nie tworzy zadania odświeżania tam, gdzie go nie ma. Buforowanie odbywa się także na więcej niż jednej warstwie, więc odpowiedź widziana przez terminal może nie być tą, którą widziała zapora.

Zadaj prawdziwemu produktowi trzy pytania: kiedy rozwiązuje, gdzie przechowuje wynik i co wyzwala aktualizację. Jeśli odpowiedź dotyczy tylko rozruchu, długotrwała sesja może przeżyć adres, do którego została dopuszczona.

dig +short vpn.example.com
resolvectl query vpn.example.com

Zaprojektuj odświeżanie i awarię jako jedną politykę

Utrzymywany wyjątek wymaga wyraźnych odpowiedzi: co wyzwala odświeżanie, zanim klient wybierze nowy adres, jak zmienia się dozwolony zestaw bez otwierania szerokiego tymczasowego okna i kiedy usuwane są nieaktualne wpisy. Zapisz te odpowiedzi obok reguły.

Wybierz zachowanie przy awarii świadomie. Zachowanie starego adresu może uratować sesję i pozostawić nieaktualne pozwolenie; wyczyszczenie zestawu może zablokować odzyskanie. Żadne z nich nie powinno być przypadkowym wynikiem nieudanego wyszukiwania. Zapisz wybrane zachowanie w runbooku, aby następny operator nie improwizował pod presją.

Utrzymuj wąski także bootstrap DNS. Bezwarunkowy wyjątek dla publicznego resolvera to bezpośrednia ścieżka DNS dla wszystkiego, co pasuje, nie tylko dla nazwy punktu końcowego.

Udowodnij zmianę punktu końcowego, nie pierwsze połączenie

Użyj obsługiwanego menedżera klienta, jeśli już koordynuje rozwiązywanie i blokowanie. Na hoście PF zarządzanym przez witrynę zachowaj własność i plan odzyskiwania witryny, zamiast kopiować składnię tabeli nazw hostów z innej platformy o innym zachowaniu cyklu życia.

Za pomocą zatwierdzonego, nieszkodliwego testu porównaj adres wybierany przez klienta z aktywnym dozwolonym zestawem przed kontrolowaną zmianą i po niej. Pokryj nieudane wyszukiwanie, usunięcie wpisu, który nie jest już ważny, oraz, jeśli to obsługiwane, inną rodzinę adresów. Zamierzony tunel powinien się odzyskać, a niepowiązany ruch bezpośredni pozostawać pod polityką. Udane pierwsze połączenie dowodzi tylko, że początkowe tłumaczenie przypadkowo było poprawne.