Silnik OpenVPN czy Tunnelblick: kto posiada sesję VPN na Macu?

Homebrew instaluje program OpenVPN; Tunnelblick instaluje menedżer, który uruchamia jeden lub więcej silników. To różne warstwy, a użyteczne pytanie nie brzmi, czy lubisz używać terminala. Brzmi ono: kto posiada konfigurację, zmiany DNS, proszenie o dane logowania i sprzątanie po zakończeniu sesji. Jeden właściciel tych warstw sprawia, że konfiguracja jest przewidywalna.

Przejdź przez pięć kontroli poniżej po kolei. Pierwsza, która ma dwóch właścicieli, tworzy te dziwne półpołączone stany, które ludzie zrzucają na sam OpenVPN. Każda kontrola wskazuje dowód, który ją rozstrzyga.

Kontrola pierwsza: który plik binarny OpenVPN naprawdę działa

Uruchom pgrep -fl openvpn podczas połączenia i przeczytaj całą linię poleceń. Pierwsza ścieżka to silnik, który naprawdę działa. Na Apple Silicon instalacja Homebrew zwykle znajduje się w /opt/homebrew, a Maci Intel używają /usr/local, zaś Tunnelblick uruchamia silnik z wnętrza własnego pakietu aplikacji.

Tunnelblick dołącza silniki i pozwala konfiguracji wybrać jeden z nich. Aktualizacja formuły Homebrew zmienia samodzielny plik binarny, a nie silnik uruchamiany przez profil Tunnelblick. Jeśli porównujesz wersje, aby wyjaśnić różnicę w zachowaniu, porównaj silnik z listy procesów, a nie ten z menedżera pakietów. Sam łańcuch wersji nie powie ci, który profil ten silnik wczytał.

Skopiowany profil może też sprawić, że dwa silniki wyglądają identycznie, choć czytają różne pliki. Ścieżka profilu w linii poleceń mówi, którą konfigurację wczytał działający proces; profil otwarty w edytorze nie jest dowodem. Porównaj tę ścieżkę przed porównywaniem zachowania.

Kontrola druga: kto zmienia DNS i trasy

Silnik może wykonywać własne dyrektywy up i down OpenVPN, ale menedżer może posiadać ten sam cykl życia. Ustawienia serwera nazw w Tunnelblick kontrolują jego standardowe skrypty połączenia i rozłączenia, a gdy ta integracja jest włączona, konkurencyjne dyrektywy w profilu mogą być ignorowane.

To ważne, bo DNS to miejsce, w którym działający tunel najczęściej wygląda na zepsuty. Sprawdź scutil --dns podczas połączenia, zanotuj, który resolver jest pierwszy, i potwierdź, że wraca po rozłączeniu. Jeśli profil oczekuje samodzielnego ustawienia DNS, a menedżer też nim zarządza, jeden z tych dwóch przegra.

Zdecyduj, która warstwa posiada DNS przed pierwszym połączeniem, a potem usuń przegrywającą dyrektywę, zamiast zostawiać obie. Zmiany tras podlegają tej samej regule: jeden właściciel, widoczny w konfiguracji, z udokumentowaną ścieżką przywracania.

Kontrola trzecia: skąd pochodzą dane logowania

Interaktywne pytanie i proces bez nadzoru mają różne wymagania. Dane logowania zapisane przez jedną aplikację nie są automatycznie dostępne dla innego procesu, a element pęku kluczy ograniczony do menedżera może być niewidoczny dla samodzielnego silnika uruchomionego z powłoki.

Wymień źródło danych logowania dla profilu: certyfikat i klucz klienta, pytanie o nazwę użytkownika i hasło albo token dostarczany przez zewnętrznego pomocnika. Następnie potwierdź, że wybrany właściciel może dotrzeć do tego źródła bez człowieka, jeśli połączenie ma przetrwać restart.

Kontrola czwarta: kto uruchamia, nadzoruje i zatrzymuje proces

Samodzielne wdrożenie potrzebuje nadzorcy, jeśli ma pozostać uruchomione. Launchd może uruchomić silnik przy logowaniu lub na żądanie, zrestartować go po awarii i czysto zatrzymać, ale ktoś musi napisać to zadanie i być jego właścicielem. Uruchamianie polecenia w terminalu sprawdza się w teście, a nie u użytkownika, który zamyka okno.

Jeśli Tunnelblick pozostaje właścicielem, użyj jego obsługiwanych elementów sterujących zamiast uruchamiać drugi silnik. Plik binarny Homebrew, otrzymawszy skopiowany profil, otwiera niezależne połączenie z własną konfiguracją i kontekstem integracji, zamiast wydawać polecenia istniejącej sesji Tunnelblick.

Niezależnie od wybranego właściciela określ, co dzieje się przy uśpieniu, zmianie sieci i wylogowaniu. Menedżer zwykle obsługuje te zdarzenia; goły proces zwykle nie, a powstała nieaktualna trasa lub resolver bywa mylona z awarią serwera.

Kontrola piąta: jak weryfikuje się przekazanie

Przetestuj nowego właściciela przy wyłączonym starym, a potem przetestuj starego ponownie, jeśli zamierzasz go zachować. Zasób prywatny, który odpowiada w jednym przepływie pracy, a w drugim nie, jest dowodem na brakującą integrację, a nie na serwer.

Przy przekazaniu do samodzielnego silnika zapisz ścieżkę profilu, ścieżkę pliku binarnego, nadzorcę, właściciela DNS i źródło danych logowania. Następnie zweryfikuj zasób prywatny, drogę do publicznego internetu i czyste rozłączenie w tej kolejności. Jeśli po rozłączeniu zostają DNS lub trasy, nowy właściciel nie skończył.

Przy przekazaniu do Tunnelblick wybierz silnik dla konfiguracji, włącz zamierzoną integrację DNS i usuń dyrektywy profilu, które jej się sprzeciwiają. Następnie powtórz te same trzy kontrole. Połączenie, które działa, ale zostawia zmieniony resolver, to nieudane przekazanie, nawet jeśli tunel wstał.

Pakowanie nie rozstrzyga zgodności z serwerem. Sprawdź własne wymagania klienta tej usługi i wybierz sam silnik tylko wtedy, gdy zamierzasz zapewnić jego zarządzanie.