Mac-VPN, innehållsfilter eller Private Relay: vilken är aktiv
Tre nätverkslager på Macen ser likadana ut i Inställningar. Skilj en VPN, ett innehållsfilter och Private Relay åt med utgångsväg, flödespolicy och surfomfattning.
Din Mac kan ha en VPN-tunnel, ett innehållsfilter och iCloud Private Relay installerade samtidigt, och ingen av dem meddelar vilken som formar en viss anslutning. Inställningspanelerna ser likadana ut, ikonerna ser likadana ut, och nästan varje leverantör kallar sin produkt nätverkssäkerhet. Tre fakta skiljer dem: om trafiken lämnar via en fjärrändpunkt du kan namnge, om en policymotor fattar tillåt-eller-släpp-beslut på enskilda flöden, och om skyddet stannar vid Safari. Får du ordning på dessa tre svarar de flesta frågor om är-min-VPN-på sig själva.
Tre villkor som identifierar komponenten
Villkor ett är utgången. En tunnelleverantör lämnar paketen till en fjärrgateway, så din publika adress ändras och, om profilen säger det, blir värdar bakom den gatewayen nåbara. Om adressen aldrig ändras och inget privat subnät öppnas tittar du inte på en fungerande tunnel, vad menyraden än säger.
Villkor två är beslutet. Ett innehållsfilter utvärderar flöden och returnerar tillåt eller släpp. Det kan genomdriva en kategorispärr, en regel per app eller en policy som en arbetsgivare skickat, och det kan logga domen. Vad det inte klarar på egen hand är att ge trafiken någonstans att ta vägen.
Villkor tre är omfattningen. Private Relay skyddar en avgränsad del av surfandet och inte en hel enhet, och dess uppgift är att skilja vem du är från vad du besöker, inte att placera dig på ett annat nätverk.
Ställ dem sida vid sida och gränserna är svåra att missa:
| 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 |
Ett innehållsfilter är en policymotor, inte en utgång
På macOS kommer ett filter som en Network Extension byggd på Apples klass för filterdataleverantörer, NEFilterDataProvider. I en hanterad utrullning skjuts det ut av MDM, installeras som en systemutvidgning och godkänns en gång under System Settings > General > Login Items and Extensions. Därefter ser det TCP-flöden, och i vissa konfigurationer även UDP, och returnerar en dom för varje.
Felläget är det som förvirrar folk. Ett filter som släpper ett flöde ger en timeout, ett fastlåst TLS-handskakning eller en återställning, vilket ser exakt ut som en tunnel som är uppe men inte kan föra trafik. Den publika adressen ändrades aldrig, eftersom det aldrig fanns en utgång som kunde ändra den.
Kommersiella klienter slår ofta ihop båda rollerna. Ett installationsprogram levererar tunnelleverantör och filter, filtret blockerar och tunneln routar. Applikationsnamnet säger dig därför ingenting om vilken komponent som avvisade anslutningen. Kontrollera utvidgningslistan, sedan den anslutna tjänsten, sedan klientloggen, i den ordningen.
Private Relay täcker Safari, inte maskinen
Private Relay skickar surfandet det täcker genom två reläer som drivs av separata parter, så ingen enskild operatör har både din identitet och dina destinationer. Det är en integritetsdesign, inte en tunnel: det finns ingen gateway att gå in i, inget privat subnät och inget sätt att fästa en utgångsadress i ett land du väljer.
Omfattningen är medvetet smal och täcker Safari-surfande tillsammans med DNS-frågorna och de osäkra HTTP-laddningarna som hör dit. En terminalsession, en e-postklient, en chattapp och en spelstartare står utanför. Om en kontroll i Terminal fortfarande visar åtkomstnätets adress medan Safari visar en reläadress är det förväntat resultat och inte en trasig installation.
Tillgängligheten är villkorad. Det kräver en iCloud+-prenumeration, det erbjuds inte i alla regioner, och ett hanterat nätverk kan blockera reläåtkomst, varvid Safari faller tillbaka på en direkt anslutning. Apples översikt över Private Relay är referensen för nuvarande omfattning. När en VPN-profil är ansluten och bär den trafiken staplas inte reläet ovanpå; profilen avgör vägen.
Läs bevisen i rätt ordning
Börja med tjänstestatusen, eftersom den är den billigaste signalen. scutil --nc list skriver ut de konfigurerade VPN-tjänsterna och om var och en är ansluten. En profil kan ligga där i åratal utan att någonsin anslutas, och folk räknar det rutinmässigt som en tunnel.
Titta sedan på gränssnitt och rutter. ifconfig visar utun-gränssnitt, men deras blotta närvaro bevisar lite, eftersom macOS använder utun för flera ändamål utöver VPN. Det som avgör är om standardrutten pekar in i ett av dem, vilket route -n get default rapporterar.
För namnmatchning listar scutil --dns de matchare systemet faktiskt kommer att använda, och där dyker en DNS-proxyleverantör upp. Att jämföra dig +short example.com med dig +short example.com @1.1.1.1 skiljer matcharen som svarar från den som avlyssnas.
Utvidgningarnas aktivitet når den enhetliga loggen: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Du letar efter vilken utvidgning som startade och om ett filter rapporterade en dom för flödet du bryr dig om, inte en rad att memorera.
Snäva in symptomet innan du stänger av något
Klassificera felet först. Ett namn som inte matchas, en anslutning som avvisas direkt och en anslutning som hänger till timeout är tre olika observationer med tre olika ansvariga. Matchning pekar på en matchare eller DNS-proxy. Omedelbar avvisning pekar på en filterregel. Tystnad pekar oftast på routning, eller på en tunnel som är uppe men inte vidarebefordrar.
På en hanterad Mac, utgå från att filtret tillhör organisationen. Att stänga av det för att testa VPN tar bort just den komponent du ville observera, och MDM återställer det ofta vid nästa incheckning. Fråga administratören om policyns namn innan du ändrar något, och testa med den specifika appen som misslyckades i stället för hela systemet.
Ännu en fälla: att stänga av Private Relay för att testa en VPN säger ingenting om utländsk trafik, eftersom reläet aldrig täckte den trafiken. Varje lager måste testas i den app det faktiskt styr.
Gå igenom listan och stanna vid första punkten som misslyckas:
- Visar
scutil --nc listtjänsten du förväntar dig som ansluten? - Skiljer sig den publika adressen som syns i Terminal från adressen ditt åtkomstnätverk tilldelade?
- Är en filterutvidgning installerad, och loggade den en dom för det misslyckade flödet?
- Är felet bara i Safari? Om så, kontrollera reläets omfattning innan du skyller på tunneln.
Om alla fyra passerar och appen ändå misslyckas ligger problemet ovanför nätverkslagret: proxyinställningar, certifikatförtroende eller en tillåten-lista på applikationsnivå.