Mac-VPN, innholdsfilter eller Private Relay: hvilken er aktiv
Tre nettverkslag på Macen ser like ut i Innstillinger. Skill en VPN, et innholdsfilter og Private Relay fra hverandre med utgangsvei, flytpolitikk og nettleseromfang.
Macen din kan ha en VPN-tunnel, et innholdsfilter og iCloud Private Relay installert samtidig, og ingen av dem kunngjør hvilken som former en gitt tilkobling. Innstillingspanelene ser like ut, ikonene ser like ut, og nesten hver leverandør kaller produktet sitt nettverkssikkerhet. Tre fakta skiller dem: om trafikken går ut gjennom et fjernt endepunkt du kan navngi, om en politikkmotor tar tillat-eller-slipp-avgjørelser på enkeltflyter, og om beskyttelsen stopper ved Safari. Får du disse tre på plass, svarer de fleste spørsmål om er-VPN-en-min-på seg selv.
Tre betingelser som identifiserer komponenten
Betingelse én er utgangen. En tunnelleverandør overlater pakkene til en fjerntliggende gateway, så den offentlige adressen din endres, og hvis profilen sier det, blir verter bak den gatewayen tilgjengelige. Hvis adressen aldri endres og ingen privat subnett åpnes, ser du ikke på en fungerende tunnel, uansett hva menylinjen sier.
Betingelse to er avgjørelsen. Et innholdsfilter vurderer flyter og returnerer tillat eller slipp. Det kan håndheve en kategoriblokkering, en regel per app eller en politikk en arbeidsgiver har sendt, og det kan logge avgjørelsen. Det det ikke kan gjøre alene, er å gi trafikken et sted å gå.
Betingelse tre er omfanget. Private Relay beskytter en definert del av nettlesingen og ikke en hel enhet, og jobben er å skille hvem du er fra hva du besøker, ikke å plassere deg på et annet nettverk.
Still dem opp side om side, og grensene er vanskelige å overse:
| 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 |
Et innholdsfilter er en politikkmotor, ikke en utgang
På macOS kommer et filter som en Network Extension bygget på Apples filterdataleverandørklasse, NEFilterDataProvider. I en administrert utrulling skyves det ut av MDM, installeres som en systemutvidelse og godkjennes én gang under Systeminnstillinger > Generelt > Innloggede objekter og utvidelser. Deretter ser det TCP-flyter, og i noen konfigurasjoner også UDP, og returnerer en avgjørelse for hver av dem.
Feilmodusen er det som forvirrer folk. Et filter som slipper en flyt, gir en tidsavbrudd, et fastlåst TLS-håndtrykk eller en nullstilling, som ser nøyaktig ut som en tunnel som er oppe, men ikke kan føre trafikk. Den offentlige adressen endret seg aldri, fordi det aldri fantes en utgang som kunne endre den.
Kommersielle klienter slår ofte sammen begge rollene. Én installasjonspakke leverer tunnelleverandør og filter, filteret blokkerer, og tunnelen ruter. Applikasjonsnavnet sier deg derfor ingenting om hvilken komponent som avviste tilkoblingen. Sjekk utvidelseslisten, deretter den tilkoblede tjenesten, deretter klientloggen, i den rekkefølgen.
Private Relay dekker Safari, ikke maskinen
Private Relay sender nettlesingen det dekker gjennom to reléer som drives av atskilte parter, så ingen enkelt operatør har både identiteten din og destinasjonene dine. Det er en personvernutforming, ikke en tunnel: det finnes ingen gateway å gå inn i, ingen privat subnett, og ingen måte å feste en utgangsadresse i et land du velger.
Omfanget er bevisst smalt og dekker Safari-nettlesing sammen med DNS-oppslagene og de usikre HTTP-lastene som hører til. En terminaløkt, en e-postklient, en chat-app og en spillstarter står utenfor. Hvis en sjekk i Terminal fortsatt viser adressen til tilgangsnettverket ditt mens Safari viser en reléadresse, er det forventet resultat og ikke en ødelagt installasjon.
Tilgjengeligheten er betinget. Det krever et iCloud+-abonnement, det tilbys ikke i alle regioner, og et administrert nettverk kan blokkere relétilgang, og da faller Safari tilbake til en direkte tilkobling. Apples oversikt over Private Relay er referansen for dagens omfang. Når en VPN-profil er tilkoblet og fører denne trafikken, legges ikke reléet oppå; profilen bestemmer veien.
Les bevisene i riktig rekkefølge
Start med tjenestetilstanden, fordi det er det billigste signalet. scutil --nc list skriver ut de konfigurerte VPN-tjenestene og om hver av dem er tilkoblet. En profil kan ligge der i årevis uten å bli tilkoblet, og folk regner det rutinemessig som en tunnel.
Se deretter på grensesnitt og ruter. ifconfig viser utun-grensesnitt, men deres tilstedeværelse beviser lite i seg selv, siden macOS bruker utun til flere formål utover VPN. Det som betyr noe, er om standardruten peker inn i et av dem, noe route -n get default rapporterer.
For navneoppslag lister scutil --dns opp oppløserne systemet faktisk vil bruke, og en DNS-proxyleverandør dukker opp der. Å sammenligne dig +short example.com med dig +short example.com @1.1.1.1 skiller oppløseren som svarer fra oppløseren som blir avlyttet.
Utvidelsesaktivitet når den samlede loggen: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Du leter etter hvilken utvidelse som startet, og om et filter rapporterte en avgjørelse for flyten du bryr deg om, ikke en linje du skal pugge.
Avgrens symptomet før du deaktiverer noe
Klassifiser feilen først. Et navn som ikke løses opp, en tilkobling som avvises umiddelbart, og en tilkobling som henger til tidsavbrudd, er tre forskjellige observasjoner med tre forskjellige eiere. Oppslag peker på en oppløser eller DNS-proxy. Umiddelbar avvisning peker på en filterregel. Stillhet peker vanligvis på ruting, eller på en tunnel som er oppe men ikke videresender.
På en administrert Mac bør du anta at filteret tilhører organisasjonen. Å deaktivere det for å teste VPN fjerner komponenten du ville observere, og MDM gjenoppretter det ofte ved neste innsjekk. Spør administratoren om politikknavnet før du endrer noe, og test med den konkrete appen som feilet, ikke hele systemet.
En felle til: å slå av Private Relay for å teste en VPN sier ingenting om utenlandsk trafikk, fordi reléet aldri dekket den trafikken. Hvert lag må testes i appen det faktisk styrer.
Gå gjennom denne listen og stopp ved første punkt som feiler:
- Viser
scutil --nc listtjenesten du forventer som tilkoblet? - Er den offentlige adressen som ses fra Terminal forskjellig fra adressen tilgangsnettverket ditt delte ut?
- Er en filterutvidelse installert, og loggførte den en avgjørelse for flyten som feiler?
- Er feilen bare i Safari? I så fall, sjekk reléets omfang før du gir tunnelen skylden.
Hvis alle fire passerer og appen fortsatt feiler, ligger problemet over nettverkslaget: proxyinnstillinger, sertifikattillit eller en tillatt-liste på applikasjonsnivå.