Klient VPN na Maca: Network Extension kontra System Extension
Network Extension to możliwość, a System Extensions to mechanizm dostarczania: rozdziel je, aby wybrać krok zatwierdzania w macOS i dziennik do czytania.
Dwa terminy Apple są używane tak, jakby nazywały to samo, a to zamieszanie wysyła ludzi do niewłaściwego panelu ustawień. Network Extension opisuje możliwość: obsługiwany sposób implementowania tuneli VPN, serwerów proxy i filtrów. System Extensions opisuje mechanizm dostarczania i zatwierdzania rozszerzeń w przestrzeni użytkownika. Współczesny klient VPN na Maca zwykle potrzebuje obu, dlatego żadna z etykiet sama nie wyjaśnia objawu. Rozdzielenie obu odpowiada, który komponent sprawdzić i jakiego kroku zatwierdzania się spodziewać.
Dwa pytania, nie jedna etykieta
Zapytaj, co robi komponent, zanim zapytasz, jak jest instalowany. Możliwość decyduje o tym, która klasa dostawcy istnieje, a więc który kod obsługuje twoje pakiety. Mechanizm dostarczania decyduje o tym, jak trafia plik binarny, jak jest zatwierdzany i gdzie zapisywany jest jego stan. Produkt może implementować tunel pakietów bez dostarczania rozszerzenia systemowego w starszych wersjach i może dostarczać rozszerzenie systemowe implementujące coś innego niż tunel.
Rozszerzenia jądra to trzeci termin, który ludzie mieszają. Były starszym sposobem uruchamiania uprzywilejowanego kodu sieciowego, wymagały innych zatwierdzeń, a Apple od lat odsuwa od nich deweloperów. Zastosowanie receptury zatwierdzania rozszerzenia jądra do współczesnego klienta marnuje czas na okno dialogowe, które nigdy się nie pojawi.
Przeczytaj notatki wdrożeniowe dostawcy dla używanej wersji macOS zamiast wpisu na forum ze starszej wersji. Architektura zmieniła się więcej niż raz, a instrukcje szybko się starzeją. Notatka wspominająca zatwierdzanie rozszerzenia jądra opisuje inną erę produktu.
Co zapewnia Network Extension
Framework udostępnia typy dostawców dla typowych zadań sieciowych: tunel pakietów dla ruchu VPN, serwer proxy aplikacji dla przepływów według aplikacji, filtr treści do inspekcji ruchu oraz obsługę serwera proxy DNS dla zachowania resolvera. Typ dostawcy określa, co może robić rozszerzenie, a klient dostarczający dwóch dostawców może wykonywać dwa różne zadania.
Ma to znaczenie podczas diagnostyki, ponieważ ten sam objaw łączności może pochodzić z tunelu, filtra lub serwera proxy DNS. Blokowanie witryny to decyzja filtra, brak dostępu do prywatnej podsieci to zwykle decyzja tunelu, a rozwiązywanie złego adresu to zwykle decyzja resolvera. Nazwanie typu dostawcy zawęża poszukiwania, zanim zostanie odczytany jakikolwiek dziennik.
Nic w frameworku nie sugeruje stanowiska w sprawie prywatności. Rozszerzenie w przestrzeni użytkownika nadal ma uprawnienia, konfigurację i operatora za sobą, więc traktuj architekturę jako szczegół implementacji, a nie sygnał zaufania. Zapytaj, kto obsługuje punkt końcowy i co jest skonfigurowane do zbierania.
Co zmienia System Extensions
Mechanizm przenosi uprzywilejowany kod z jądra do przestrzeni użytkownika i zmienia sposób, w jaki system operacyjny prosi o zgodę. Aktywacja to osobny krok od instalacji, a użytkownik lub profil MDM musi ją zatwierdzić. Klient, który instaluje się, ale nigdy nie aktywuje wygląda na obecny w folderze Applications i nic nie robi dla łączności.
Stan rejestruje system, a nie aplikacja, co jest przydatne, ponieważ można o niego zapytać. Poniższe polecenie listuje rozszerzenia znane systemowi i ich stan aktywacji.
systemextensionsctl list
scutil --nc list
Pierwsze polecenie odpowiada, czy komponent jest zainstalowany i aktywowany. Drugie listuje konfiguracje VPN, które system posiada, co jest innym pytaniem i często tym, które ma znaczenie, gdy profil połączenia brakuje, a nie jest zepsuty.
Który sprawdzić przy danym objawie
Dopasuj objaw do warstwy, zanim otworzysz panel ustawień. Brakująca konfiguracja to pytanie o profil, zainstalowany, ale nieaktywny komponent to pytanie o dostarczanie, a aktywny komponent, który nie przepuszcza ruchu, to pytanie o możliwość.
| Symptom | First place to look |
|---|---|
| No VPN entry at all | Configuration profile or scutil list |
| Client installed, nothing happens | Extension activation state |
| Tunnel up, private host unreachable | Tunnel provider routes and policy |
| One app blocked, others fine | Filter or app proxy provider |
Strumień dziennika to wspólny dowód dla dwóch ostatnich wierszy. Odczyt podsystemu rozszerzenia sieciowego mówi, który dostawca obsłużył strumień, a decyzja filtra wygląda inaczej niż awaria tunelu, nawet gdy użytkownik opisuje oba jako zepsuty VPN.
log show --last 10m --predicate 'process == "nesessionmanager"'
Nie wnioskuj, że rozszerzenie jest aktywne, bo w pasku menu jest ikona. Ikony przeżywają nieudane aktywacje, a nieaktualna ikona to jedna z najczęstszych przyczyn rozpoczynania zgłoszenia do wsparcia w złym miejscu. Zamiast tego czytaj stan aktywacji, bo to system go rejestruje.
Zatwierdzanie, MDM i mit rozszerzenia jądra
Na zarządzanych Macach krok zatwierdzania należy do profilu MDM, a użytkownik, który kliknie Allow w System Settings, nadal może zostać zablokowany przez niezaktualizowaną politykę. Zapytaj zespół desktopowy, który mechanizm zatwierdza rozszerzenie dla tej floty, zanim poprosisz użytkownika o kliknięcie czegokolwiek.
Na niezarządzanym Macu monit o zatwierdzenie pojawia się raz, a odrzucenie może być trwałe, dopóki rozszerzenie nie zostanie zainstalowane ponownie. To zachowanie wyjaśnia maszynę, na której klient działał przed aktualizacją systemu, a teraz zgłasza połączenie, które nigdy nie powstaje.
Zapisz typ dostawcy, stan aktywacji i mechanizm zatwierdzania dla klienta, którego wdrażasz. Te trzy fakty odpowiadają na większość przyszłych pytań o VPN na Maca bez ponownego otwierania sporu możliwość kontra dostarczanie.