Mac-VPN, contentfilter of Private Relay: welke is actief
Drie netwerklagen van de Mac lijken in Instellingen op elkaar. Onderscheid een VPN, een contentfilter en Private Relay aan de hand van uitgangspad, stroombeleid en browsescope.
Je Mac kan tegelijk een VPN-tunnel, een contentfilter en iCloud Private Relay hebben geïnstalleerd, en geen ervan meldt welke een bepaalde verbinding vormgeeft. De instellingenpanelen lijken op elkaar, de pictogrammen lijken op elkaar, en bijna elke leverancier noemt zijn product netwerkbeveiliging. Drie feiten scheiden ze: of verkeer via een extern eindpunt vertrekt dat je kunt benoemen, of een beleidsengine per stroom beslist toestaan-of-wegwerpen, en of de bescherming bij Safari ophoudt. Zet die drie op een rij en de meeste vragen of-mijn-VPN-aan-staat beantwoorden zichzelf.
Drie voorwaarden die het onderdeel identificeren
Voorwaarde één is de uitgang. Een tunnelleverancier geeft pakketten aan een externe gateway, dus je openbare adres verandert en, als het profiel dat zegt, worden hosts achter die gateway bereikbaar. Verandert het adres nooit en opent zich geen privé-subnet, dan kijk je niet naar een werkende tunnel, wat de menubalk ook zegt.
Voorwaarde twee is de beslissing. Een contentfilter beoordeelt stromen en geeft toestaan of wegwerpen terug. Het kan een categoriblokkade, een regel per app of een door een werkgever gepusht beleid afdwingen, en het kan het oordeel loggen. Wat het niet alleen kan, is het verkeer een plek geven om naartoe te gaan.
Voorwaarde drie is de scope. Private Relay beschermt een afgebakend deel van het browsen en niet een heel apparaat, en zijn taak is wie je bent scheiden van wat je bezoekt, niet je op een ander netwerk plaatsen.
Zet ze naast elkaar en de grenzen zijn moeilijk te missen:
| 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 |
Een contentfilter is een beleidsengine, geen uitgang
Op macOS komt een filter als Network Extension, gebouwd op Apples filtergegevensaanbiederklasse NEFilterDataProvider. In een beheerde uitrol duwt MDM het, wordt het als systeemextensie geïnstalleerd en één keer goedgekeurd onder Systeeminstellingen > Algemeen > Inlogitems en extensies. Daarna ziet het TCP-stromen, en in sommige configuraties ook UDP, en geeft het voor elk daarvan een oordeel terug.
De faalmodus is wat mensen verwart. Een filter dat een stroom wegwerpt, levert een time-out, een vastgelopen TLS-handshake of een reset op, wat er precies uitziet als een tunnel die omhoog staat maar geen verkeer doorlaat. Het openbare adres veranderde nooit, omdat er nooit een uitgang was om het te veranderen.
Commerciële clients bundelen vaak beide rollen. Eén installatieprogramma levert een tunnelleverancier en een filter, het filter blokkeert en de tunnel routeert. De applicatienaam zegt je dus niets over welk onderdeel de verbinding weigerde. Controleer de extensielijst, dan de verbonden dienst, dan het clientlog, in die volgorde.
Private Relay dekt Safari, niet de machine
Private Relay stuurt het browsen dat het dekt via twee relays die door afzonderlijke partijen worden beheerd, zodat geen enkele operator zowel je identiteit als je bestemmingen heeft. Dat is een privacyontwerp, geen tunnel: er is geen gateway om binnen te gaan, geen privé-subnet, en geen manier om een uitgangsadres vast te zetten in een land dat je kiest.
De scope is bewust smal: het dekt Safari-browsen samen met de DNS-query's en onbeveiligde HTTP-loads die daarbij horen. Een terminalsessie, een mailclient, een chatapp en een gamelauncher staan erbuiten. Als een controle in Terminal nog je toegangsnetwerkadres toont terwijl Safari een relayadres toont, is dat het verwachte resultaat, geen kapotte installatie.
Beschikbaarheid is voorwaardelijk. Het vereist een iCloud+-abonnement, het wordt niet in elke regio aangeboden, en een beheerd netwerk kan relaytoegang blokkeren, waarna Safari terugvalt op een directe verbinding. Apples overzicht van Private Relay is de referentie voor de huidige scope. Als een VPN-profiel verbonden is en dat verkeer draagt, wordt de relay er niet bovenop gestapeld; het profiel bepaalt het pad.
Lees het bewijs in de juiste volgorde
Begin met de dienststatus, want dat is het goedkoopste signaal. scutil --nc list drukt de geconfigureerde VPN-diensten af en of elk verbonden is. Een profiel kan daar jaren staan zonder ooit verbonden te zijn, en mensen rekenen dat routinematig als een tunnel.
Kijk dan naar interfaces en routes. ifconfig toont utun-interfaces, maar hun aanwezigheid alleen bewijst weinig, omdat macOS utun voor meerdere doelen buiten VPN gebruikt. Wat telt is of de standaardroute in een ervan wijst, wat route -n get default meldt.
Voor naamresolutie somt scutil --dns de resolvers op die het systeem echt zal gebruiken, en daar verschijnt een DNS-proxyleverancier. Het vergelijken van dig +short example.com met dig +short example.com @1.1.1.1 scheidt de resolver die antwoordt van de resolver die wordt onderschept.
Extensieactiviteit bereikt het uniforme log: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Je zoekt welke extensie startte en of een filter een oordeel meldde over de stroom die je aangaat, niet een regel om uit je hoofd te leren.
Vernauw het symptoom voordat je iets uitschakelt
Classificeer eerst de fout. Een naam die niet oplost, een verbinding die meteen wordt geweigerd, en een verbinding die tot de time-out blijft hangen zijn drie verschillende waarnemingen met drie verschillende eigenaren. Resolutie wijst op een resolver of DNS-proxy. Onmiddellijke weigering wijst op een filterregel. Stilte wijst meestal op routering, of op een tunnel die omhoog staat maar niet doorstuurt.
Ga op een beheerde Mac uit van een filter van de organisatie. Het uitschakelen om de VPN te testen verwijdert juist het onderdeel dat je wilde observeren, en MDM herstelt het vaak bij de volgende controle. Vraag de beheerder om de naam van het beleid voordat je iets wijzigt, en test met de specifieke app die faalde in plaats van het hele systeem.
Nog een valkuil: Private Relay uitzetten om een VPN te testen zegt niets over buitenlands verkeer, omdat de relay dat verkeer nooit dekte. Elke laag moet worden getest in de app die hij werkelijk bestuurt.
Werk deze lijst door en stop bij het eerste punt dat faalt:
- Toont
scutil --nc listde dienst die je verwacht als verbonden? - Verschilt het openbare adres dat je in Terminal ziet van het adres dat je toegangsnetwerk toekende?
- Is er een filterextensie geïnstalleerd, en logde die een oordeel voor de falende stroom?
- Is de fout alleen in Safari? Zo ja, controleer dan de relayscope voordat je de tunnel de schuld geeft.
Als alle vier slagen en de app faalt nog steeds, zit het probleem boven de netwerklaag: proxyinstellingen, certificaatvertrouwen of een toegestane lijst op applicatieniveau.