Mac VPN, enhava filtrilo aŭ Private Relay: kiu estas aktiva
Tri retaj tavoloj de Mac aspektas same en Agordoj. Distingu VPN, enhavan filtrilon kaj Private Relay per elirvojo, flupolitiko kaj retumada amplekso.
Via Mac povas havi samtempe instalitajn VPN-tunelon, enhavan filtrilon kaj iCloud Private Relay, kaj neniu el ili anoncas, kiu el ili formigas difinitan konekton. La agordaj paneloj aspektas similaj, la ikonoj aspektas similaj, kaj preskaŭ ĉiu vendanto nomas sian produkton reta sekureco. Tri faktoj apartigas ilin: ĉu trafiko eliras tra fora finpunkto, kiun vi povas nomi, ĉu politika motoro decidas permesi-aŭ-forĵeti por unuopaj fluoj, kaj ĉu la protekto haltas ĉe Safari. Ordigi tiujn tri kaj la plej multaj demandoj ĉu-mia-VPN-estas-ŝaltita respondas sin mem.
Tri kondiĉoj, kiuj identigas la komponanton
La unua kondiĉo estas la eliro. Tunela provizanto transdonas pakaĵojn al fora enirejo, do via publika adreso ŝanĝiĝas kaj, se la profilo tion diras, gastigantoj malantaŭ tiu enirejo fariĝas atingeblaj. Se la adreso neniam ŝanĝiĝas kaj neniu privata subreto malfermiĝas, vi ne rigardas funkciantan tunelon, kion ajn diras la menuobreto.
La dua kondiĉo estas la decido. Enha filtrilo taksas fluojn kaj redonas permesi aŭ forĵeti. Ĝi povas plenumi kategorian blokadon, regulon por unuopa aplikaĵo aŭ politikon senditan de dunganto, kaj ĝi povas registri la verdikton. Kion ĝi sola ne povas, estas doni al la trafiko lokon, kien iri.
La tria kondiĉo estas la amplekso. Private Relay protektas difinitan parton de retumado anstataŭ la tutan aparaton, kaj ĝia tasko estas apartigi, kiu vi estas, de tio, kion vi vizitas, ne meti vin en alian reton.
Metu ilin unu apud la alia kaj la limojn malfacilas maltrafi:
| 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 |
Enha filtrilo estas politika motoro, ne eliro
En macOS filtrilo alvenas kiel Network Extension konstruita sur la filtrila datumprovizanta klaso de Apple, NEFilterDataProvider. En administrata disfaldiĝo ĝin puŝas MDM, ĝi instaliĝas kiel sistema etendaĵo kaj aprobiĝas unufoje sub Sistemaj Agordoj > Ĝeneralaj > Salutaj eroj kaj etendaĵoj. De tiam ĝi vidas TCP-fluojn, kaj en kelkaj agordoj ankaŭ UDP, kaj redonas verdikton pri ĉiu.
La malsukcesa maniero estas tio, kio konfuzas homojn. Filtrilo, kiu forĵetas fluon, produktas tempolimon, haltintan TLS-manpremon aŭ restarigon, kio aspektas ĝuste kiel tunelo, kiu leviĝis sed ne povas pasigi trafikon. La publika adreso neniam ŝanĝiĝis, ĉar neniam estis eliro por ŝanĝi ĝin.
Komercaj klientoj ofte kunigas ambaŭ rolojn. Unu instalilo liveras tunelan provizanton kaj filtrilon, la filtrilo faras la blokadon, kaj la tunelo faras la enkursigon. Do la aplikaĵa nomo diras al vi nenion pri tio, kiu komponanto rifuzis la konekton. Kontrolu la liston de etendaĵoj, poste la konektitan servon, poste la klientan protokolon, en tiu ordo.
Private Relay kovras Safari, ne la maŝinon
Private Relay sendas la retumadon, kiun ĝi kovras, tra du relajsoj funkciigataj de apartaj partioj, do neniu unuopulo tenas kaj vian identecon kaj viajn celojn. Tio estas privateca dizajno, ne tunelo: estas neniu enirejo, en kiun vi povus eniri, neniu privata subreto, kaj neniu maniero fiksi eliran adreson en lando, kiun vi elektas.
Ĝia amplekso estas intence mallarĝa, kovrante retumadon en Safari kune kun la DNS-serĉoj kaj nesekuraj HTTP-ŝarĝoj, kiuj akompanas ĝin. Terminala seanco, poŝta kliento, babileja aplikaĵo kaj luda lanĉilo staras ekster ĝi. Se kontrolo en Terminalo ankoraŭ montras la adreson de via alirreto dum Safari montras relajsan adreson, tio estas la atendita rezulto, ne difektita instalaĵo.
Disponebleco estas kondiĉa. Ĝi postulas iCloud+ planon, ĝi ne estas ofertata en ĉiu regiono, kaj administrata reto povas bloki relajsan aliron, en kiu kazo Safari reiras al rekta konekto. La superrigardo de Private Relay de Apple estas la referenco por la nuna amplekso. Kiam VPN-profilo estas konektita kaj portas tiun trafikon, la relajso ne stakiĝas sur ĝi; la profilo decidas la vojon.
Legu la pruvojn en la ĝusta ordo
Komencu per la serva stato, ĉar ĝi estas la plej malmultekosta signalo. scutil --nc list presas la agorditajn VPN-servojn kaj ĉu ĉiu estas konektita. Profilo povas sidi tie dum jaroj sen iam konektiĝi, kaj homoj rutine kalkulas tion kiel tunelon.
Poste rigardu interfacojn kaj vojojn. ifconfig montras utun-interfacojn, sed ilia ĉeesto mem pruvas malmulte, ĉar macOS uzas utun por pluraj celoj krom VPN. Gravas, ĉu la defaŭlta vojo montras en unu el ili, kion raportas route -n get default.
Por nomrezolucio scutil --dns listigas la solvilojn, kiujn la sistemo efektive uzos, kaj tie aperas DNS-prokura provizanto. Kompari dig +short example.com kun dig +short example.com @1.1.1.1 apartigas la solvilon, kiu respondas, de la solvilo, kiu estas interkaptata.
Etendaĵa agado atingas la unuigitan protokolon: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Vi serĉas, kiu etendaĵo ekfunkciis kaj ĉu filtrilo raportis verdikton pri la fluo, kiu zorgas vin, ne linion por parkerigi.
Mallarĝigu la simptomon antaŭ ol vi malŝaltos ion ajn
Klasifiku la fiaskon unue. Nomo, kiu ne solviĝas, konekto tuj rifuzita, kaj konekto, kiu pendas ĝis tempolimo, estas tri malsamaj observoj kun tri malsamaj respondeculoj. Solvado montras al solvilo aŭ DNS-prokuro. Tuja rifuzo montras al filtrila regulo. Silento kutime montras al enkursigo, aŭ al tunelo, kiu staras sed ne plusendas.
Sur administrata Mac, supozu, ke la filtrilo apartenas al la organizo. Malŝalti ĝin por testi la VPN forigas la komponanton, kiun vi volis observi, kaj MDM ofte restarigas ĝin ĉe la sekva kontrolo. Demandu la administranton pri la politika nomo antaŭ ol ŝanĝi ion ajn, kaj testu per la konkreta aplikaĵo, kiu malsukcesis, anstataŭ per la tuta sistemo.
Ankoraŭ unu kaptilo: malŝalti Private Relay por testi VPN diras nenion pri eksterlanda trafiko, ĉar la relajso neniam kovris tiun trafikon. Ĉiu tavolo devas esti testata en la aplikaĵo, kiun ĝi efektive regadas.
Trairu ĉi tiun liston kaj haltu ĉe la unua ero, kiu malsukcesas:
- Ĉu
scutil --nc listmontras la atenditan servon kiel konektitan? - Ĉu la publika adreso vidata el Terminalo diferencas de la adreso, kiun atribuis via alirreto?
- Ĉu filtrila etendaĵo estas instalita, kaj ĉu ĝi registris verdikton por la malsukcesanta fluo?
- Ĉu la fiasko estas nur en Safari? Se jes, kontrolu la relajsan amplekson antaŭ ol kulpigi la tunelon.
Se ĉiuj kvar pasas kaj la aplikaĵo ankoraŭ malsukcesas, la problemo sidas super la reta tavolo: prokuraj agordoj, atestila fido, aŭ permeslisto je aplikaĵa nivelo.