Jak przetestować drugi klient VPN na Macu bez utraty pierwszego

Instalujesz drugiego klienta, aby go porównać, a pierwszy przestaje działać. Nic nie zostało usunięte i obie aplikacje są nadal zainstalowane. Zmieniło się to, co jest pod nimi: rozszerzenie systemowe, ustawienie DNS lub trasa domyślna, i obaj klienci nie zgadzają się już, do kogo to należy. Instalacja nie jest ryzykowną częścią; ryzykowną częścią jest uruchamianie obu bez zapisanego stanu wyjściowego, do którego można wrócić.

Objaw: działająca konfiguracja zatrzymuje się po drugiej instalacji

Współczesne klienty VPN dla macOS często dostarczają rozszerzenie sieciowe zamiast interfejsu w starym stylu. Instalacja jednego może wymagać zatwierdzenia, dodać profil konfiguracji lub zarejestrować rozszerzenie systemowe, które wpływa na ruch jeszcze przed nawiązaniem jakiegokolwiek połączenia. Rozszerzenie ładuje się, zanim pojawi się okno aplikacji, dlatego pierwotny klient może zawieść, gdy nowy stoi bezczynnie.

Jeśli pierwotny klient nie może się wtedy połączyć albo łączy się i niczego nie rozwiązuje, nowe rozszerzenie jest pierwszym podejrzanym. To nie jest dowód konfliktu, ale tam zaczyna się dochodzenie. Następnie sprawdź listę rozszerzeń i zainstalowane profile konfiguracji, nie tylko folder aplikacji.

Zapisz stan wyjściowy, zanim cokolwiek zainstalujesz

Zapisz, co działa teraz: wynik aplikacji, wersję klienta, punkt końcowy, z którym się łączy, oraz wszelkie wyjątki dla poszczególnych aplikacji lub tunelu dzielonego. Zapisz pierwotny profil przez chroniony proces obsługiwany przez klienta, a nie przez kopiowanie plików z pakietu aplikacji.

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

Przechwyć te trzy wyniki, gdy działający klient jest połączony. Dają ci stan resolvera, tabelę tras i listę interfejsów, które wytwarza działająca konfiguracja, i dokładnie tego potrzebujesz do późniejszego porównania. Jeśli Maciem zarządza pracodawca, potwierdź przed rozpoczęciem, że porównanie jest dozwolone, ponieważ automatyczne połączenie służbowe może się ponownie aktywować podczas testu, a wynik nie reprezentuje wtedy żadnego z klientów osobno. Zachowaj trzy wyniki obok notatki o profilu, aby późniejsze porównanie miało punkt odniesienia.

Zmieniaj jedną aktywną ścieżkę naraz

Zatrzymaj pierwotne połączenie jego zwykłą kontrolką, a następnie uruchom alternatywę. Dwa połączone jednocześnie klienty dają wynik opisujący kombinację, a nie którykolwiek z produktów. Utrzymuj punkt końcowy i zadanie porównywalne, jeśli usługi na to pozwalają, ponieważ szybsze pobieranie przez inny serwer porównuje dwie opcje połączenia, a nie dwie aplikacje.

Jeśli nowy klient zawiedzie, zachowaj jego pierwszy błąd, zanim zmienisz cokolwiek innego. Pierwszy błąd zwykle nazywa etap, a druga próba po zmianie ustawień często zgłasza coś mniej użytecznego.

Porównaj DNS, trasy i aplikację, nie tylko prędkość

Uruchom te same trzy polecenia z połączonym nowym klientem i porównaj je linia po linii. Resolver wskazujący gdzie indziej lub tabela tras bez prywatnej podsieci wyjaśnia większość różnic w zachowaniu, zanim spojrzysz na przepustowość. Następnie przetestuj samą aplikację z tym samym zadaniem, ponieważ klient, który łączy się szybko i nie potrafi rozwiązać wewnętrznej nazwy, nie wygrał porównania, nawet jeśli okno stanu wygląda lepiej.

Zwróć uwagę, którego interfejsu użył ruch. W macOS nazwa interfejsu tunelu nie jest wiarygodnym wskaźnikiem, który klient posiada trasę, więc połącz listę interfejsów z tabelą tras, zamiast czytać tylko jedną z nich. Jeśli istnieją dwa interfejsy utun, ruch niesie ten z pasującą trasą i wpisem resolvera. Zgadywanie po nazwie jest sposobem, w jaki obwinia się niewłaściwy interfejs, ponieważ istniejący interfejs nie zawsze jest tym, który niesie ruch.

Czytaj trzy wyniki, zamiast tylko je przeglądać. W zrzucie resolvera serwer nazw powiązany z interfejsem utun pokazuje, który klient go zainstalował; w tabeli tras trasa domyślna wskazuje interfejs niosący ruch; na liście interfejsów drugie urządzenie utun oznacza utworzenie drugiego tunelu. Te trzy linie, porównane ze stanem wyjściowym, oddzielają przywróconą konfigurację od tej, w której oba klienty nadal konkurują.

Przywróć, a następnie usuń czysto

Wróć przez własny przepływ pracy pierwotnego klienta i potwierdź, że wyniki stanu wyjściowego zgadzają się z tym, co zapisałeś. Jeśli resolver lub tabela tras się nie odtworzą, zatrzymaj się i napraw to, zanim usuniesz cokolwiek innego. Usuń nieużywaną konfigurację przez komponent, do którego należy: deinstalator klienta, profil lub ustawienia rozszerzenia systemowego.

Zakończ, aktualizując notatki o przetestowaną wersję, użyty punkt końcowy i wynik dla każdego. Pół roku później ten zapis jest różnicą między decyzją a plotką.