VPN na Macu, filtr treści czy Private Relay: co jest aktywne
Trzy warstwy sieci na Macu wyglądają w Ustawieniach tak samo. Rozróżnij VPN, filtr treści i Private Relay po ścieżce wyjścia, polityce przepływów i zakresie przeglądania.
Twój Mac może mieć jednocześnie zainstalowany tunel VPN, filtr treści i iCloud Private Relay, a żaden z nich nie ogłasza, który kształtuje dane połączenie. Panele ustawień wyglądają podobnie, ikony wyglądają podobnie, a niemal każdy dostawca nazywa swój produkt bezpieczeństwem sieci. Trzy fakty je rozdzielają: czy ruch wychodzi przez zdalny punkt końcowy, który potrafisz nazwać, czy silnik polityki podejmuje decyzje zezwól-lub-odrzuć dla pojedynczych przepływów, i czy ochrona kończy się na Safari. Uporządkuj te trzy i większość pytań czy-mój-VPN-jest-włączony odpowiada się sama.
Trzy warunki identyfikujące komponent
Warunek pierwszy to wyjście. Dostawca tunelu przekazuje pakiety zdalnej bramie, więc twój publiczny adres się zmienia i, jeśli profil tak stanowi, hosty za tą bramą stają się osiągalne. Jeśli adres nigdy się nie zmienia i nie otwiera się żadna prywatna podsieć, nie patrzysz na działający tunel, cokolwiek mówi pasek menu.
Warunek drugi to decyzja. Filtr treści ocenia przepływy i zwraca zezwól albo odrzuć. Może egzekwować blokadę kategorii, regułę dla aplikacji albo politykę przesłaną przez pracodawcę, i może rejestrować werdykt. Czego nie potrafi sam, to dać ruchowi miejsca, do którego ma trafić.
Warunek trzeci to zakres. Private Relay chroni określony wycinek przeglądania, a nie całe urządzenie, a jego zadaniem jest oddzielenie tego, kim jesteś, od tego, co odwiedzasz, nie umieszczenie cię w innej sieci.
Postaw je obok siebie, a granice trudno przeoczyć:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
Filtr treści to silnik polityki, nie wyjście
W macOS filtr przychodzi jako Network Extension zbudowane na klasie dostawcy danych filtru Apple, NEFilterDataProvider. We wdrożeniu zarządzanym wypycha go MDM, instaluje się jako rozszerzenie systemowe i zatwierdza raz w System Settings > General > Login Items and Extensions. Od tego momentu widzi przepływy TCP, a w niektórych konfiguracjach także UDP, i zwraca werdykt dla każdego z nich.
To sposób awarii najbardziej myli ludzi. Filtr, który odrzuca przepływ, daje przekroczenie czasu, zablokowany uścisk TLS albo reset, co wygląda dokładnie jak tunel, który się podniósł, ale nie przepuszcza ruchu. Publiczny adres nigdy się nie zmienił, bo nie było wyjścia, które mogłoby go zmienić.
Klienci komercyjni często łączą obie role. Jeden instalator dostarcza dostawcę tunelu i filtr, filtr blokuje, a tunel routuje. Nazwa aplikacji nie mówi więc nic o tym, który komponent odmówił połączenia. Sprawdź listę rozszerzeń, potem podłączoną usługę, potem dziennik klienta, w tej kolejności.
Private Relay obejmuje Safari, nie całą maszynę
Private Relay wysyła objęte przeglądanie przez dwa przekaźniki prowadzone przez odrębne strony, więc żaden pojedynczy operator nie ma jednocześnie twojej tożsamości i twoich celów. To projekt prywatności, nie tunel: nie ma bramy, do której można wejść, nie ma prywatnej podsieci i nie ma sposobu przypięcia adresu wyjścia w wybranym przez ciebie kraju.
Jego zakres jest celowo wąski: obejmuje przeglądanie w Safari wraz z zapytaniami DNS i niezabezpieczonymi ładowaniami HTTP, które mu towarzyszą. Sesja terminala, klient poczty, aplikacja czatu i launcher gier stoją poza nim. Jeśli sprawdzenie w terminalu nadal pokazuje adres sieci dostępowej, a Safari pokazuje adres przekaźnika, to jest oczekiwany wynik, nie zepsuta instalacja.
Dostępność jest warunkowa. Wymaga planu iCloud+, nie jest oferowana w każdym regionie, a sieć zarządzana może blokować dostęp do przekaźnika, wtedy Safari wraca do połączenia bezpośredniego. Przegląd Private Relay od Apple to odniesienie dla obecnego zakresu. Gdy profil VPN jest podłączony i niesie ten ruch, przekaźnik nie jest nakładany na wierzch; ścieżkę wyznacza profil.
Czytaj dowody we właściwej kolejności
Zacznij od stanu usługi, bo to najtańszy sygnał. scutil --nc list wypisuje skonfigurowane usługi VPN i to, czy każda jest podłączona. Profil może leżeć tam latami, nigdy nie będąc podłączonym, a ludzie rutynowo liczą to jako tunel.
Potem spójrz na interfejsy i trasy. ifconfig pokazuje interfejsy utun, ale ich sama obecność niewiele dowodzi, bo macOS używa utun do kilku celów poza VPN. Liczy się to, czy trasa domyślna prowadzi do jednego z nich, co raportuje route -n get default.
Dla rozwiązywania nazw scutil --dns wymienia resolver, którego system naprawdę użyje, i pojawia się tam dostawca proxy DNS. Porównanie dig +short example.com z dig +short example.com @1.1.1.1 oddziela resolver odpowiadający od resolvera przechwytywanego.
Aktywność rozszerzeń trafia do dziennika zunifikowanego: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Szukasz tego, które rozszerzenie wystartowało i czy filtr zgłosił werdykt dla interesującego cię przepływu, a nie wiersza do wykucia.
Zawęź objaw, zanim cokolwiek wyłączysz
Najpierw sklasyfikuj awarię. Nazwa, która się nie rozwiązuje, połączenie odrzucane natychmiast oraz połączenie wiszące do przekroczenia czasu to trzy różne obserwacje z trzema różnymi właścicielami. Rozwiązywanie wskazuje na resolver lub proxy DNS. Natychmiastowa odmowa wskazuje na regułę filtru. Cisza zwykle wskazuje na routing albo na tunel, który jest podniesiony, ale nie przekazuje.
Na zarządzanym Macu zakładaj, że filtr należy do organizacji. Wyłączenie go, by przetestować VPN, usuwa właśnie ten komponent, który chciałeś obserwować, a MDM często go przywraca przy następnej kontroli. Zapytaj administratora o nazwę polityki, zanim cokolwiek zmienisz, i testuj tą konkretną aplikacją, która zawiodła, a nie całym systemem.
Jeszcze jedna pułapka: wyłączenie Private Relay, by przetestować VPN, nie mówi nic o ruchu zagranicznym, bo przekaźnik nigdy tego ruchu nie obejmował. Każdą warstwę trzeba testować w aplikacji, którą naprawdę rządzi.
Przejdź tę listę i zatrzymaj się na pierwszym punkcie, który zawiedzie:
- Czy
scutil --nc listpokazuje oczekiwaną usługę jako podłączoną? - Czy publiczny adres widziany z terminala różni się od adresu przydzielonego przez twoją sieć dostępową?
- Czy zainstalowane jest rozszerzenie filtrujące i czy zapisało werdykt dla zawodzącego przepływu?
- Czy awaria występuje tylko w Safari? Jeśli tak, sprawdź zakres przekaźnika, zanim obwinisz tunel.
Jeśli wszystkie cztery przejdą, a aplikacja nadal zawodzi, problem leży wyżej niż warstwa sieci: ustawienia proxy, zaufanie do certyfikatu albo lista dozwolonych na poziomie aplikacji.