Mac-VPN, indholdsfilter eller Private Relay: hvilken er aktiv
Tre netværkslag på Macen ser ens ud i Indstillinger. Brug udgangsvej, flowpolitik og browsingomfang til at skelne en VPN, et indholdsfilter og Private Relay fra hinanden.
Din Mac kan have en VPN-tunnel, et indholdsfilter og iCloud Private Relay installeret på samme tid, og ingen af dem fortæller, hvilken der former en given forbindelse. Indstillingspanelerne ser ens ud, ikonerne ser ens ud, og næsten hver leverandør kalder sit produkt netværkssikkerhed. Tre fakta skiller dem ad: om trafikken forlader gennem et fjernendepunkt, du kan navngive, om en politikmotor træffer tillad-eller-drop-beslutninger på enkelte flows, og om beskyttelsen stopper ved Safari. Får du de tre på plads, besvarer de fleste spørgsmål om er-min-VPN-tændt sig selv.
Tre betingelser, der identificerer komponenten
Betingelse et er udgangen. En tunneludbyder giver pakkerne videre til en fjern-gateway, så din offentlige adresse ændrer sig, og hvis profilen siger det, bliver værter bag den gateway tilgængelige. Hvis adressen aldrig ændrer sig, og der ikke åbnes et privat subnet, kigger du ikke på en fungerende tunnel, uanset hvad menulinjen siger.
Betingelse to er beslutningen. Et indholdsfilter vurderer flows og returnerer tillad eller drop. Det kan håndhæve en kategoriblokering, en regel pr. app eller en politik, som en arbejdsgiver har sendt, og det kan logge afgørelsen. Det, det ikke selv kan, er at give trafikken et sted at tage hen.
Betingelse tre er omfanget. Private Relay beskytter en afgrænset del af browsing frem for en hel enhed, og dets opgave er at adskille, hvem du er, fra hvad du besøger — ikke at placere dig på et andet netværk.
Stil dem op ved siden af hinanden, og grænserne er svære at 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 indholdsfilter er en politikmotor, ikke en udgang
På macOS ankommer et filter som en Network Extension bygget på Apples filterdataudbyderklasse, NEFilterDataProvider. I en administreret udrulning skubbes det af MDM, installeres som en systemudvidelse og godkendes én gang under Systemindstillinger > Generelt > Login-objekter og udvidelser. Derefter ser det TCP-flows, og i nogle konfigurationer også UDP, og returnerer en afgørelse for hver af dem.
Fejlmåden er det, der forvirrer folk. Et filter, der dropper et flow, giver en timeout, et fastlåst TLS-håndtryk eller et reset, hvilket ser præcis ud som en tunnel, der er oppe, men ikke kan føre trafik. Den offentlige adresse ændrede sig aldrig, fordi der aldrig var en udgang til at ændre den.
Kommercielle klienter samler ofte begge roller. Et installationsprogram leverer både tunneludbyder og filter, filteret blokerer, og tunnelen ruter. Så applikationsnavnet fortæller dig intet om, hvilken komponent der afviste forbindelsen. Tjek udvidelseslisten, derefter den forbundne tjeneste, derefter klientloggen, i den rækkefølge.
Private Relay dækker Safari, ikke maskinen
Private Relay sender den browsing, den dækker, gennem to relæer, der drives af adskilte parter, så ingen enkelt operatør har både din identitet og dine destinationer. Det er et privatlivsdesign, ikke en tunnel: der er ingen gateway at gå ind i, intet privat subnet og ingen måde at fastgøre en udgangsadresse i et land, du vælger.
Dets omfang er bevidst snævert og dækker Safari-browsing sammen med de DNS-opslag og usikre HTTP-indlæsninger, der hører med. En terminalsession, en mailklient, en chatapp og en spilstarter ligger udenfor. Hvis en kontrol i Terminal stadig viser din adgangsnetværksadresse, mens Safari viser en relæadresse, er det det forventede resultat, ikke en ødelagt installation.
Tilgængeligheden er betinget. Det kræver et iCloud+-abonnement, det tilbydes ikke i alle regioner, og et administreret netværk kan blokere relæadgang, hvorefter Safari falder tilbage til en direkte forbindelse. Apples oversigt over Private Relay er referencen for det aktuelle omfang. Når en VPN-profil er forbundet og fører den trafik, lægges relæet ikke ovenpå; profilen bestemmer vejen.
Læs beviserne i den rigtige rækkefølge
Start med tjenestetilstanden, fordi det er det billigste signal. scutil --nc list udskriver de konfigurerede VPN-tjenester og om hver af dem er forbundet. En profil kan ligge der i årevis uden nogensinde at være forbundet, og folk regner det rutinemæssigt som en tunnel.
Se derefter på grænseflader og ruter. ifconfig viser utun-grænseflader, men deres tilstedeværelse beviser lidt i sig selv, da macOS bruger utun til flere formål ud over VPN. Det afgørende er, om standardruten peger ind i en af dem, hvilket route -n get default rapporterer.
Til navneopløsning viser scutil --dns de resolvere, systemet faktisk vil bruge, og en DNS-proxyudbyder dukker op der. At sammenligne dig +short example.com med dig +short example.com @1.1.1.1 adskiller den resolver, der svarer, fra den resolver, der bliver opsnappet.
Udvidelsesaktivitet når den samlede log: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Du leder efter, hvilken udvidelse der startede, og om et filter rapporterede en afgørelse for det flow, du bekymrer dig om — ikke en linje, du skal huske.
Indsnævr symptomet, før du deaktiverer noget
Klassificér fejlen først. Et navn, der ikke opløses, en forbindelse, der afvises med det samme, og en forbindelse, der hænger til timeout, er tre forskellige observationer med tre forskellige ejere. Opløsning peger på en resolver eller DNS-proxy. Øjeblikkelig afvisning peger på en filterregel. Tavshed peger normalt på routing eller på en tunnel, der er oppe, men ikke videresender.
På en administreret Mac må du antage, at filteret tilhører organisationen. At deaktivere det for at teste VPN fjerner den komponent, du forsøgte at observere, og MDM gendanner det ofte ved næste check-in. Spørg administratoren om politiknavnet, før du ændrer noget, og test med den specifikke app, der fejlede, i stedet for hele systemet.
Endnu en fælde: at slå Private Relay fra for at teste en VPN siger intet om udenlandsk trafik, fordi relæet aldrig dækkede den trafik. Hvert lag skal testes i den app, det faktisk styrer.
Gå gennem denne liste, og stop ved det første punkt, der fejler:
- Viser
scutil --nc listden tjeneste, du forventer, som forbundet? - Afviger den offentlige adresse, der ses fra Terminal, fra den adresse, dit adgangsnetværk tildelte?
- Er der installeret en filterudvidelse, og loggede den en afgørelse for det fejlende flow?
- Er fejlen kun i Safari? Hvis ja, tjek relæets omfang, før du giver tunnelen skylden.
Hvis alle fire består, og appen stadig fejler, ligger problemet over netværkslaget: proxyindstillinger, certifikattillid eller en tilladelsesliste på applikationsniveau.