Mac-VPN, inhoudsfilter of Private Relay: watter een is aktief?
Drie Mac-netwerklaagte lyk dieselfde in Instellings. Gebruik die uitgangspad, die vloeibeleid en die blaaiomvang om 'n VPN, 'n inhoudsfilter en Private Relay van mekaar te onderskei.
Jou Mac kan gelyktydig 'n VPN-tonnel, 'n inhoudsfilter en iCloud Private Relay hê, en nie een daarvan sê watter een 'n gegewe verbinding vorm nie. Die instellingspanele lyk eenders, die ikone lyk eenders, en byna elke verskaffer noem sy produk netwerksekuriteit. Drie feite onderskei hulle: of verkeer deur 'n afgeleë eindpunt gaan wat jy kan noem, of 'n beleidsenjin toelaat-of-verwerp-besluite oor individuele vloei neem, en of die beskerming by Safari stop. Kry daardie drie reg, en die meeste vrae oor of jou VPN aan is, beantwoord hulself.
Drie voorwaardes wat die komponent identifiseer
Voorwaarde een is die uitgang. 'n Tonnelverskaffer oorhandig pakkette aan 'n afgeleë poort, so jou openbare adres verander en, as die profiel dit sê, word hosts agter daardie poort bereikbaar. As die adres nooit verander nie en geen private subnet oopgaan nie, kyk jy nie na 'n werkende tonnel nie, wat die kieslysbalk ook al sê.
Voorwaarde twee is die beslissing. 'n Inhoudsfilter evalueer vloei en gee toelaat of verwerp terug. Dit kan 'n kategorieblokkade, 'n reël per toepassing of 'n beleid wat deur 'n werkgewer gestuur word, afdwing, en dit kan die uitspraak log. Wat dit nie op sy eie kan doen nie, is om die verkeer êrens heen te stuur.
Voorwaarde drie is omvang. Private Relay beskerm 'n bepaalde deel van blaai eerder as 'n hele toestel, en sy taak is om te skei wie jy is van wat jy besoek, nie om jou op 'n ander netwerk te plaas nie.
Sit die drie langs mekaar, en die grense is moeilik om mis te kyk:
| 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 |
'n Inhoudsfilter is 'n beleidsenjin, nie 'n uitgang nie
Op macOS kom 'n filter as 'n Network Extension wat op Apple se filterdataverskaffer-klas, NEFilterDataProvider, gebou is. In 'n bestuurde ontplooiing word dit deur MDM gestuur, as 'n stelseluitbreiding geïnstalleer en een keer onder Stelselinstellings, Algemeen, Aanmeldingsitems en Uitbreidings goedgekeur. Van toe af sien dit TCP-vloei, en in sommige konfigurasies ook UDP, en gee 'n uitspraak oor elkeen.
Die foutmodus is wat mense verwar. 'n Filter wat 'n vloei verwerp, veroorsaak 'n tydsverloop, 'n vasgevangde TLS-handdruk of 'n herstel, wat presies lyk soos 'n tonnel wat opgekom het maar nie verkeer kan deurlaat nie. Die openbare adres het nooit verander nie, want daar was nooit 'n uitgang om dit te verander nie.
Kommersiële kliënte bondel dikwels beide rolle. Een installeerder lewer 'n tonnelverskaffer en 'n filter, die filter doen die blokkering en die tonnel doen die roetering. Die toepassing se naam sê dus niks oor watter komponent die verbinding geweier het nie. Kyk na die uitbreidingslys, dan na die gekoppelde diens, dan na die kliëntlog, in daardie volgorde.
Private Relay dek Safari, nie die masjien nie
Private Relay stuur die blaai wat dit dek deur twee relays wat deur aparte partye bedryf word, so geen enkele operateur hou beide jou identiteit en jou bestemmings nie. Dit is 'n privaatheidsontwerp, nie 'n tonnel nie: daar is geen poort waarby jy kan inkom nie, geen private subnet nie, en geen manier om 'n uitgangsadres in 'n land van jou keuse vas te pen nie.
Sy omvang is doelbewus smal en dek Safari-blaai saam met die DNS-opsoeke en onveilige HTTP-ladings wat daarmee saamgaan. 'n Terminal-sessie, 'n e-poskliënt, 'n kletsprogram en 'n speletjie-lanseerder val buite dit. As 'n toets in Terminal steeds jou toegangsnetwerk-adres wys terwyl Safari 'n relay-adres wys, is dit die verwagte resultaat, nie 'n stukkende installasie nie.
Beskikbaarheid is voorwaardelik. Dit benodig 'n iCloud+-plan, dit word nie in elke streek aangebied nie, en 'n bestuurde netwerk kan relay-toegang blokkeer, in welke geval Safari na 'n direkte verbinding terugval. Apple se oorsig oor Private Relay is die verwysing vir die huidige omvang. Wanneer 'n VPN-profiel gekoppel is en daardie verkeer dra, word die relay nie bo-op dit gestapel nie; die profiel besluit die pad.
Lees die bewyse in die regte volgorde
Begin met diensstatus, want dit is die goedkoopste sein. scutil --nc list druk die gekonfigureerde VPN-dienste en of elkeen gekoppel is. 'n Profiel kan jare daar sit sonder om ooit gekoppel te word, en mense reken dit gereeld as 'n tonnel.
Kyk dan na koppelvlakke en roetes. ifconfig wys utun-koppelvlakke, maar hul teenwoordigheid bewys op sigself min, want macOS gebruik utun vir verskeie doeleindes buite VPN. Wat saak maak, is of die verstekroete in een daarvan wys, wat route -n get default rapporteer.
Vir naamoplossing lys scutil --dns die oplossers wat die stelsel werklik sal gebruik, en 'n DNS-proxyverskaffer wys daar. Om dig +short example.com met dig +short example.com @1.1.1.1 te vergelyk, skei die oplosser wat antwoord van die oplosser wat onderskep word.
Uitbreidingsaktiwiteit bereik die verenigde log: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Jy soek watter uitbreiding begin het en of 'n filter 'n uitspraak oor die vloei wat jou interesseer gerapporteer het, nie 'n reël om te memoriseer nie.
Vernou die simptoom voordat jy enigiets deaktiveer
Klassifiseer die fout eerste. 'n Naam wat nie oplos nie, 'n verbinding wat dadelik geweier word, en 'n verbinding wat tot tydsverloop hang, is drie verskillende waarnemings met drie verskillende eienaars. Naamoplossing wys na 'n oplosser of DNS-proxy. Onmiddellike weiering wys na 'n filterreël. Stilte wys gewoonlik na roetering, of na 'n tonnel wat op is maar nie deurstuur nie.
Op 'n bestuurde Mac, aanvaar die filter behoort aan die organisasie. Om dit te deaktiveer om die VPN te toets, verwyder die komponent wat jy probeer waarneem, en MDM herstel dit dikwels by die volgende aanmelding. Vra die administrateur vir die beleid se naam voordat jy enigiets verander, en toets met die spesifieke toepassing wat gefaal het eerder as die hele stelsel.
Nog 'n strik: om Private Relay af te skakel om 'n VPN te toets, sê niks oor buitelandse verkeer nie, want die relay het daardie verkeer nooit van die begin af gedek nie. Elke laag moet getoets word op die toepassing wat dit werklik beheer.
Werk deur hierdie lys en stop by die eerste item wat faal:
- Wys
scutil --nc listdie diens wat jy verwag as gekoppel? - Verskil die openbare adres wat in Terminal gesien word van die adres wat jou toegangsnetwerk toegeken het?
- Is 'n filteruitbreiding geïnstalleer, en het dit 'n uitspraak vir die falende vloei gelog?
- Is die fout net in Safari? Indien wel, kyk na die relay se omvang voordat jy die tonnel blameer.
As al vier slaag en die toepassing steeds faal, sit die probleem bo die netwerklaag: proxy-instellings, sertifikaatvertroue of 'n toelaatlys op toepassingsvlak.