VPN del Mac, filtre de contingut o Private Relay: quin està actiu
Tres capes de xarxa del Mac semblen iguals a Configuració. Distingiu una VPN, un filtre de contingut i Private Relay pel camí de sortida, la política de fluxos i l'abast de navegació.
El vostre Mac pot tenir alhora un túnel VPN, un filtre de contingut i iCloud Private Relay, i cap d'ells anuncia quin està modelant una connexió concreta. Els panells de configuració semblen iguals, les icones semblen iguals i gairebé tots els fabricants anomenen seguretat de xarxa el seu producte. Tres fets els separen: si el trànsit surt per un punt remot que pugueu anomenar, si un motor de polítiques decideix permetre o descartar fluxos individuals, i si la protecció s'atura a Safari. Amb aquests tres punts clars, la majoria de preguntes de si-la-meva-VPN-està-activa es responen soles.
Tres condicions que identifiquen el component
La primera condició és la sortida. Un proveïdor de túnel lliura els paquets a una passarel·la remota, de manera que la vostra adreça pública canvia i, si el perfil ho diu, els equips darrere d'aquella passarel·la esdevenen accessibles. Si l'adreça no canvia mai i no s'obre cap subxarxa privada, no esteu veient un túnel funcional, digui el que digui la barra de menús.
La segona condició és la decisió. Un filtre de contingut avalua fluxos i retorna permet o descarta. Pot aplicar un bloqueig de categoria, una regla per aplicació o una política enviada per l'empresa, i pot registrar el veredicte. El que no pot fer per si sol és donar al trànsit un lloc on anar.
La tercera condició és l'abast. Private Relay protegeix una porció definida de la navegació i no tot un dispositiu, i la seva feina és separar qui sou del que visiteu, no situar-vos en una altra xarxa.
Poseu-los un al costat de l'altre i els límits són difícils de confondre:
| 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 |
Un filtre de contingut és un motor de polítiques, no una sortida
A macOS un filtre arriba com una Network Extension construïda sobre la classe de proveïdor de dades de filtre d'Apple, NEFilterDataProvider. En un desplegament gestionat l'empeny l'MDM, s'instal·la com a extensió de sistema i s'aprova un cop a Configuració del Sistema > General > Ítems d'inici i extensions. A partir d'aleshores veu fluxos TCP, i en algunes configuracions també UDP, i retorna un veredicte per a cadascun.
El mode de fallada és el que confon la gent. Un filtre que descarta un flux produeix un temps d'espera exhaurit, un handshake TLS encallat o un reset, que sembla exactament un túnel que ha pujat però no pot passar trànsit. L'adreça pública no va canviar mai, perquè no hi havia cap sortida que la canviés.
Els clients comercials sovint agrupen tots dos papers. Un sol instal·lador porta un proveïdor de túnel i un filtre, el filtre fa el bloqueig i el túnel fa l'encaminament. Per tant, el nom de l'aplicació no us diu res sobre quin component va refusar la connexió. Reviseu la llista d'extensions, després el servei connectat i després el registre del client, en aquest ordre.
Private Relay cobreix Safari, no la màquina
Private Relay envia la navegació que cobreix a través de dos relés operats per parts separades, de manera que cap operador únic té alhora la vostra identitat i les vostres destinacions. És un disseny de privadesa, no un túnel: no hi ha passarel·la on entrar, ni subxarxa privada, ni manera de fixar una adreça de sortida en un país que trieu.
El seu abast és deliberadament estret: cobreix la navegació de Safari juntament amb les consultes DNS i les càrregues HTTP insegures que hi van associades. Una sessió de terminal, un client de correu, una aplicació de xat i un llançador de jocs queden fora. Si una comprovació al Terminal encara mostra l'adreça de la vostra xarxa d'accés mentre Safari mostra una adreça de relé, aquest és el resultat esperat, no una instal·lació trencada.
La disponibilitat és condicional. Cal un pla iCloud+, no s'ofereix a totes les regions i una xarxa gestionada pot bloquejar l'accés al relé, cas en què Safari torna a una connexió directa. La visió general de Private Relay d'Apple és la referència de l'abast actual. Quan un perfil VPN està connectat i porta aquest trànsit, el relé no se superposa; el perfil decideix el camí.
Llegiu les proves en l'ordre correcte
Comenceu per l'estat del servei, perquè és el senyal més barat. scutil --nc list llista els serveis VPN configurats i si cadascun està connectat. Un perfil pot estar-hi anys sense connectar-se mai, i la gent ho compta habitualment com un túnel.
Després mireu interfícies i rutes. ifconfig mostra interfícies utun, però la seva presència per si sola prova poc, ja que macOS fa servir utun per a diverses coses més enllà de la VPN. El que importa és si la ruta per defecte apunta a una d'elles, cosa que informa route -n get default.
Per a la resolució de noms, scutil --dns llista els resolutors que el sistema farà servir realment, i hi apareix un proveïdor de proxy DNS. Comparar dig +short example.com amb dig +short example.com @1.1.1.1 separa el resolutor que respon del resolutor que és interceptat.
L'activitat de les extensions arriba al registre unificat: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Busqueu quina extensió va començar i si un filtre va informar d'un veredicte sobre el flux que us interessa, no una línia per memoritzar.
Estrebeu el símptoma abans de desactivar res
Classifiqueu primer la fallada. Un nom que no es resol, una connexió refusada immediatament i una connexió que penja fins al temps d'espera són tres observacions diferents amb tres responsables diferents. La resolució apunta a un resolutor o a un proxy DNS. Un refús immediat apunta a una regla del filtre. El silenci sol apuntar a l'encaminament, o a un túnel que està aixecat però no reenvia.
En un Mac gestionat, suposeu que el filtre és de l'organització. Desactivar-lo per provar la VPN elimina el component que volíeu observar, i l'MDM sovint el restaura al següent check-in. Demaneu el nom de la política a l'administrador abans de canviar res, i proveu amb l'aplicació concreta que va fallar en lloc de tot el sistema.
Una trampa més: desactivar Private Relay per provar una VPN no diu res sobre el trànsit estranger, perquè el relé mai no va cobrir aquell trànsit. Cada capa s'ha de provar amb l'aplicació que realment governa.
Recorreu aquesta llista i atureu-vos al primer punt que falli:
scutil --nc listmostra com a connectat el servei que espereu?- L'adreça pública vista des del Terminal és diferent de l'adreça que va assignar la vostra xarxa d'accés?
- Hi ha una extensió de filtre instal·lada, i va registrar un veredicte per al flux que falla?
- La fallada és només a Safari? Si és així, reviseu l'abast del relé abans de culpar el túnel.
Si els quatre punts passen i l'aplicació encara falla, el problema és per sobre de la capa de xarxa: configuració de proxy, confiança en certificats o una llista d'aplicacions permeses.