Mac-VPN, innholdsfilter eller Private Relay: hvilken er aktiv

Mac-en din kan ha en VPN-tunnel, et innholdsfilter og iCloud Private Relay installert samtidig, og ingen av dem forteller hvilken som former en bestemt forbindelse. Innstillingspanelene ser like ut, ikonene ser like ut, og nesten alle leverandører kaller produktet sitt nettverkssikkerhet. Tre forhold skiller dem: om trafikken forlater maskinen gjennom et eksternt endepunkt du kan navngi, om en politikkmotor avgjør tillat-eller-slipp for enkeltflyter, og om beskyttelsen stopper ved Safari. Får du orden på disse tre, gir de fleste spørsmål om VPN-en-er-på svar av seg selv.

Tre vilkår som identifiserer komponenten

Vilkår nummer én er utgangen. En tunnelleverandør overlater pakkene til en ekstern gateway, slik at den offentlige adressen din endres, og dersom profilen sier det, blir maskiner bak den gatewayen tilgjengelige. Endres adressen aldri og åpnes det ikke noe privat subnett, ser du ikke på en tunnel som virker, uansett hva menylinjen påstår.

Vilkår nummer to er avgjørelsen. Et innholdsfilter vurderer flyter og svarer tillat eller slipp. Det kan håndheve en kategorisperre, en regel per app eller en policy som en arbeidsgiver har sendt ut, og det kan loggføre avgjørelsen. Det det ikke klarer på egen hånd, er å gi trafikken et sted å ta veien.

Vilkår nummer tre er omfanget. Private Relay beskytter en avgrenset del av nettlesingen og ikke hele enheten, og oppgaven er å skille hvem du er fra hva du besøker, ikke å plassere deg på et annet nett.

Setter du dem ved siden av hverandre, er grensene vanskelige å overse:

Et innholdsfilter er en politikkmotor, ikke en utgang

På macOS kommer et filter som en Network Extension bygget på Apples klasse for filterdataleverandører, NEFilterDataProvider. I en administrert utrulling skyves det ut via MDM, installeres som en systemutvidelse og godkjennes én gang under System Settings > General > Login Items and Extensions. Fra da av ser det TCP-flyter, og i enkelte oppsett også UDP, og returnerer en avgjørelse for hver enkelt.

Feilmåten er den som skaper forvirring. Et filter som slipper en flyt, gir tidsavbrudd, fastlåst TLS-håndtrykk eller en nullstilling, og det ser nøyaktig ut som en tunnel som er oppe, men som ikke slipper trafikk gjennom. Den offentlige adressen ble aldri endret, fordi det aldri fantes noen utgang som kunne endre den.

Kommersielle klienter samler ofte begge rollene. Én installasjonspakke leverer både tunnelleverandør og filter, filteret står for blokkeringen, og tunnelen står for rutingen. Applikasjonsnavnet sier deg derfor ingenting om hvilken komponent som avviste forbindelsen. Sjekk utvidelseslisten, deretter den tilkoblede tjenesten, deretter klientloggen, i nettopp den rekkefølgen.

Private Relay dekker Safari, ikke hele maskinen

Private Relay sender nettlesingen det dekker gjennom to reléer som drives av forskjellige parter, slik at ingen enkelt operatør sitter på både identiteten din og målene dine. Dette er personvern-design, ikke en tunnel: det finnes ingen gateway å gå inn i, ikke noe privat subnett, og ingen måte å feste en utgangsadresse i et land du selv velger.

Omfanget er med vilje smalt og dekker Safari-nettlesing sammen med DNS-spørringene og de usikrede HTTP-lastene som hører med. En terminaløkt, en e-postklient, en chat-app og en spillstarter faller utenfor. Viser en sjekk i Terminal fortsatt adressen til aksessnettet ditt mens Safari viser en reléadresse, er det forventet resultat og ikke en ødelagt installasjon.

Tilgjengeligheten er betinget. Det krever et iCloud+-abonnement, tilbys ikke i alle regioner, og et administrert nett kan blokkere relé-tilgang, og da faller Safari tilbake til direkte forbindelse. 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 på toppen; profilen bestemmer veien.

Les bevisene i riktig rekkefølge

Begynn med tjenestestatusen, fordi den er det billigste signalet. scutil --nc list skriver ut de konfigurerte VPN-tjenestene og hvorvidt hver av dem er tilkoblet. En profil kan bli liggende der i årevis uten å bli koblet til, og folk regner det rutinemessig som en tunnel.

Se så på grensesnitt og ruter. ifconfig viser utun-grensesnitt, men at de finnes beviser lite i seg selv, siden macOS bruker utun til flere formål utenom VPN. Det som betyr noe, er om standardruten peker inn i ett av dem, noe route -n get default rapporterer.

For navneoppslag lister scutil --dns opp de oppløserne systemet faktisk kommer til å bruke, og der dukker det opp en DNS-proxy-leverandør. Å 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.

Aktiviteten til utvidelser 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.

Begrens symptomet før du deaktiverer noe

Klassifiser feilen først. Et navn som ikke lar seg slå opp, en forbindelse som avvises umiddelbart, og en forbindelse som henger til tidsavbrudd, er tre forskjellige observasjoner med tre forskjellige ansvarlige. Oppslag peker mot en oppløser eller DNS-proxy. Umiddelbar avvisning peker mot en filterregel. Stillhet peker vanligvis mot ruting, eller mot 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 nettopp den komponenten du ønsket å observere, og MDM gjenoppretter det ofte ved neste innsjekk. Spør administratoren om navnet på policyen før du endrer noe, og test med den konkrete appen som feilet i stedet for hele systemet.

En felle til: å skru av Private Relay for å teste en VPN sier ingenting om utenlandsk trafikk, fordi reléet aldri dekket den trafikken. Hvert lag må testes i den appen det faktisk styrer.

Gå gjennom denne listen og stopp ved første punkt som feiler:

• Viser scutil --nc list tjenesten du forventer som tilkoblet?
• Er den offentlige adressen du ser fra Terminal forskjellig fra adressen aksessnettet ditt delte ut?
• Er det installert en filterutvidelse, og loggførte den en avgjørelse for flyten som feiler?
• Er feilen bare i Safari? I så fall, sjekk omfanget til reléet før du gir tunnelen skylden.

Dersom alle fire passerer og appen fortsatt feiler, ligger problemet over nettverkslaget: proxyinnstillinger, sertifikattillit eller en tillatt-liste på applikasjonsnivå.