Wyjątki VPN dla poszczególnych aplikacji psują się, gdy wspólna usługa pobiera dane

Wykluczasz jedną aplikację z VPN, a potrzebne jej pobieranie nadal kończy się niepowodzeniem lub, co gorsza, zaczyna działać i coś niezwiązanego przestaje. Widoczne okno nie musi być procesem otwierającym każde połączenie: aplikacja może przekazać pracę pomocnikowi, usłudze transferu w tle lub całkiem innemu pakietowi. Dlatego reguła dla aplikacji potrzebuje rzeczywistego modelu tożsamości platformy, a nie znanej nazwy pliku uruchamiającego. Poniższe kontrole zaczynają się od obserwacji i wracają do tego, kto naprawdę wysłał żądanie.

W tych zgłoszeniach zwykle dwie rzeczy psują się jednocześnie: wykluczany jest niewłaściwy składnik, a wyjątek nigdy później nie zostaje zawężony.

Znajdź proces, a nie okno

Odtwórz nieudaną operację i zidentyfikuj proces lub pakiet, do którego należy połączenie, w trakcie jego trwania. W Windows to inne pytanie niż to, które okno ma fokus, ponieważ transfer w tle może być pośredniczony przez usługę działającą pod własną tożsamością. W Linux i macOS ten sam podział objawia się jako procesy pomocnicze i demony systemowe.

Zapisz trzy szczegóły: tożsamość pliku wykonywalnego lub pakietu, miejsce docelowe, z którym się łączył, oraz moment w przepływie pracy, w którym to nastąpiło. Pobieranie, które zawodzi na początku, często jest pobieraniem metadanych przez inny składnik niż pobieranie, które zawodzi w połowie. Sama ta różnica zwykle wystarcza, by wybrać właściwą tożsamość, zanim dotkniesz reguły. Jeśli tożsamość okaże się usługą, a nie aplikacją, ten jeden fakt zmienia całą regułę, więc ustal go najpierw.

Jeśli nie możesz obserwować procesu, bo operacja jest zbyt krótka, powtórz ją z większym ładunkiem lub wolniejszym miejscem docelowym. Celem jest jedna powtarzalna obserwacja, a nie teoria o tym, który pomocnik jest zaangażowany.

Traktuj DNS jako własną ścieżkę

Rozwiązywanie nazw systemowych może w ogóle nie podążać za wykluczoną aplikacją, dlatego wykluczona przeglądarka nadal może zawodzić na prywatnej nazwie hosta, choć jej ruch jest poprawnie poza tunelem. Przeglądarka była wykluczona; resolver nie.

Sprawdź, co platforma robi z DNS, gdy obowiązuje reguła dla aplikacji, i sprawdź to osobno od żądania HTTP. Jeśli resolver jest usługą współdzieloną, obsługuje każdą aplikację na urządzeniu, więc rozważany wyjątek ma znacznie szerszą publiczność niż ten przetestowany.

Zanotuj, który resolver odpowiedział i przez jaki interfejs. Ta jedna obserwacja rozwiązuje dużą część zgłoszeń „aplikacja jest wykluczona, ale nazwa się nie rozwiązuje”, więc zachowaj ją przy zgłoszeniu.

Nie poszerzaj wspólnego pomocnika

Wspólna usługa wykonuje pracę dla kilku aplikacji, więc wykluczenie jej w celu naprawy jednego przepływu pracy zmienia także ruch niezwiązany. Background Intelligent Transfer Service w Windows jest dobrym przykładem tej formy: to infrastruktura, której może używać wiele aplikacji, a jej tożsamość nie jest tożsamością aplikacji, która zażądała transferu.

Sprawdź model reguł obsługiwany przez klienta i wymagania organizacji, zanim dodasz ten wyjątek. Zapytaj, co jeszcze korzysta ze składnika, i czy regułę, którą zamierzasz napisać, można wyrazić wobec miejsc docelowych, a nie wobec wspólnego procesu.

Jeśli wymagania nie da się w ogóle wyrazić jako granicy aplikacji, polityka oparta na miejscach docelowych lub inny zatwierdzony projekt mogą być bardziej zrozumiałe i bezpieczniejsze niż rosnąca lista wyjątków dla pomocników.

Testuj cały przepływ pracy, a nie nieudany krok

Po obsługiwanej zmianie uruchom zamierzone zadanie z nowym żądaniem od początku do końca. Następnie uruchom inny przepływ pracy, który korzysta ze wspólnego składnika, bo tam szerokie obejście ogłasza się. Poprawka, która naprawia pierwszy i po cichu psuje drugi, nie jest poprawką. Zachowaj oba wyniki w zgłoszeniu i nazwij drugi przepływ pracy wprost, aby recenzent mógł go powtórzyć.

Utrzymuj test mały i powtarzalny: to samo miejsce docelowe, to samo konto, te same warunki. Jeśli drugi przepływ pracy nie jest udokumentowany, zapytaj jego właściciela, od czego zależy, zanim uznasz zmianę za bezpieczną.

Zostaw powód, nie listę nazw

Udokumentuj składnik, przepływ pracy, któremu służy, i powód jego wykluczenia. Lista nazw pomocników bez powiązanego celu staje się nie do utrzymania w ciągu dwóch cykli wydania, a następny inżynier usuwa niewłaściwy wpis, porządkując ją.

Jedna linia na wyjątek wystarczy: co się psuje bez niego, kto jest właścicielem tego przepływu pracy i kiedy ostatnio go zweryfikowano. Te trzy pola zamieniają tajemniczą listę w politykę, której ktoś może bronić.