VPN na Macu, filtr obsahu nebo Private Relay: co je aktivní

Váš Mac může mít současně nainstalovaný tunel VPN, filtr obsahu i iCloud Private Relay a žádný z nich neoznámí, který z nich utváří dané připojení. Panely nastavení vypadají podobně, ikony vypadají podobně a téměř každý výrobce nazývá svůj produkt síťovou bezpečností. Rozdělují je tři skutečnosti: zda provoz odchází přes vzdálený koncový bod, který umíte pojmenovat, zda rozhodovací engine na jednotlivých tocích volí povolit nebo zahodit, a zda ochrana končí u Safari. Když si tyto tři věci srovnáte, většina otázek typu je-moje-VPN-zapnutá odpoví sama.

Tři podmínky, které určí komponentu

První podmínkou je výstup. Poskytovatel tunelu předává pakety vzdálené bráně, takže se vaše veřejná adresa mění a, pokud to profil stanoví, hostitelé za touto branou jsou dostupní. Pokud se adresa nikdy nezmění a neotevře se žádná privátní podsíť, nedíváte se na fungující tunel, ať menu bar říká cokoli.

Druhou podmínkou je rozhodnutí. Filtr obsahu vyhodnocuje toky a vrací povolit nebo zahodit. Může vynutit blokaci kategorie, pravidlo pro aplikaci nebo politiku od zaměstnavatele a může verdikt zaznamenat. Co sám nedokáže, je dát provozu místo, kam má jít.

Třetí podmínkou je rozsah. Private Relay chrání vymezenou část prohlížení, nikoli celé zařízení, a jeho úkolem je oddělit, kdo jste, od toho, co navštěvujete, ne vás umístit do jiné sítě.

Postavte je vedle sebe a hranice se nedají přehlédnout:

Filtr obsahu je rozhodovací engine, ne výstup

V macOS přichází filtr jako Network Extension postavené na třídě poskytovatele dat filtru od Apple, NEFilterDataProvider. Ve spravovaném nasazení ho tlačí MDM, instaluje se jako systémové rozšíření a jednou se schválí v System Settings > General > Login Items and Extensions. Od té doby vidí TCP toky, v některých konfiguracích i UDP, a u každého vrací verdikt.

Matek zmatku je způsob selhání. Filtr, který tok zahodí, vytvoří timeout, zaseknutý TLS handshake nebo reset, což vypadá přesně jako tunel, který se zvedl, ale nepropouští provoz. Veřejná adresa se nikdy nezměnila, protože nebyl žádný výstup, který by ji změnil.

Komerční klienti často obě role slučují. Jeden instalátor přináší poskytovatele tunelu i filtr, filtr blokuje a tunel směruje. Název aplikace vám tedy nic neříká o tom, která komponenta spojení odmítla. Zkontrolujte seznam rozšíření, potom připojenou službu, potom log klienta, v tomto pořadí.

Private Relay pokrývá Safari, ne celý počítač

Private Relay posílá prohlížení, které pokrývá, přes dva relaye provozované oddělenými stranami, takže žádný jediný operátor nedrží vaši identitu i vaše cíle zároveň. To je návrh soukromí, ne tunel: není zde brána, do které byste vstoupili, žádná privátní podsíť a žádný způsob, jak připíchnout výstupní adresu v zemi, kterou si vyberete.

Jeho rozsah je záměrně úzký: pokrývá prohlížení v Safari spolu s DNS dotazy a nezabezpečenými HTTP načteními, která k němu patří. Terminálová relace, poštovní klient, chatovací aplikace a launcher her stojí mimo. Pokud kontrola v Terminálu stále ukazuje adresu vaší přístupové sítě, zatímco Safari ukazuje adresu relaye, je to očekávaný výsledek, ne rozbitá instalace.

Dostupnost je podmíněná. Vyžaduje plán iCloud+, nenabízí se v každém regionu a spravovaná síť může přístup k relayi zablokovat, načež Safari přejde na přímé připojení. Přehled Private Relay od Apple je referencí pro současný rozsah. Když je profil VPN připojený a tento provoz nese, relaye se na něj nevrství; cestu určuje profil.

Čtěte důkazy ve správném pořadí

Začněte stavem služby, protože je to nejlevnější signál. scutil --nc list vypíše nakonfigurované VPN služby a to, zda je každá připojená. Profil tam může roky ležet, aniž by se kdy připojil, a lidé to běžně počítají jako tunel.

Potom se podívejte na rozhraní a trasy. ifconfig ukazuje rozhraní utun, ale jejich pouhá přítomnost mnoho nedokazuje, protože macOS používá utun i k jiným účelům než VPN. Důležité je, zda výchozí trasa vede do některého z nich, což hlásí route -n get default.

Pro překlad názvů scutil --dns vypíše překladače, které systém skutečně použije, a objeví se tam i poskytovatel DNS proxy. Porovnání dig +short example.com s dig +short example.com @1.1.1.1 oddělí překladač, který odpovídá, od toho, který je zachytáván.

Aktivita rozšíření se dostane do unified logu: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Hledáte, které rozšíření začalo a zda filtr ohlásil verdikt pro tok, na kterém vám záleží, ne řádek k zapamatování.

Než cokoli vypnete, zúžte příznak

Nejdřív poruchu zařaďte. Název, který se nepřeloží, spojení okamžitě odmítnuté a spojení visící do timeoutu jsou tři různá pozorování se třemi různými vlastníky. Překlad ukazuje na překladač nebo DNS proxy. Okamžité odmítnutí ukazuje na pravidlo filtru. Ticho obvykle ukazuje na směrování nebo na tunel, který je zvednutý, ale nepředává.

Na spravovaném Macu předpokládejte, že filtr patří organizaci. Vypnutí kvůli testu VPN odstraní komponentu, kterou jste chtěli pozorovat, a MDM ji často při další kontrole obnoví. Před jakoukoli změnou se zeptejte správce na název politiky a testujte konkrétní aplikací, která selhala, ne celým systémem.

Ještě jedna past: vypnutí Private Relay kvůli testu VPN neřekne nic o cizím provozu, protože relaye ten provoz nikdy nepokrýval. Každou vrstvu je třeba testovat v aplikaci, které skutečně vládne.

Projděte tento seznam a zastavte se u první položky, která selže:

• Ukazuje scutil --nc list očekávanou službu jako připojenou?
• Liší se veřejná adresa viděná z Terminálu od adresy, kterou přidělila vaše přístupová síť?
• Je nainstalované rozšíření filtru a zaznamenalo verdikt pro selhávající tok?
• Je selhání jen v Safari? Pokud ano, zkontrolujte rozsah relaye, než obviníte tunel.

Pokud všechny čtyři projdou a aplikace stále selhává, problém je nad síťovou vrstvou: nastavení proxy, důvěra certifikátů nebo seznam povolených na úrovni aplikace.