VPN do Mac, filtro de contido ou Private Relay: cal está activo
Tres capas de rede do Mac parécense en Axustes. Distinga unha VPN, un filtro de contido e Private Relay pola ruta de saída, a política de fluxos e o alcance de navegación.
O seu Mac pode ter instalados á vez un túnel VPN, un filtro de contido e iCloud Private Relay, e ningún deles anuncia cal está a moldear unha conexión concreta. Os paneis de axustes parécense, as iconas parécense e case todos os provedores chaman seguridade de rede ao seu produto. Tres feitos sepáranos: se o tráfico sae por un punto remoto que vostede poida nomear, se un motor de políticas decide permitir ou descartar fluxos individuais, e se a protección remata en Safari. Con eses tres puntos claros, a maioría das preguntas de se-a-miña-VPN-está-activa respóndense soas.
Tres condicións que identifican o compoñente
A primeira condición é a saída. Un provedor de túnel entrega os paquetes a unha porta de enlace remota, así que o seu enderezo público cambia e, se o perfil o indica, os equipos detrás desa porta resultan accesibles. Se o enderezo nunca cambia e non se abre ningunha subrede privada, non está a ver un túnel funcional, diga o que diga a barra de menús.
A segunda condición é a decisión. Un filtro de contido avalía fluxos e devolve permitir ou descartar. Pode impor un bloqueo de categoría, unha regra por aplicación ou unha política enviada polo empregador, e pode rexistrar o veredicto. O que non pode facer por si só é darlle ao tráfico un lugar ao que ir.
A terceira condición é o alcance. Private Relay protexe unha porción definida da navegación e non un dispositivo enteiro, e o seu traballo é separar quen é vostede do que visita, non situalo noutra rede.
Póñaos un xunto a outro e os límites son difíciles de pasar por alto:
| 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 filtro de contido é un motor de políticas, non unha saída
En macOS un filtro chega como unha Network Extension construída sobre a clase de provedor de datos de filtrado de Apple, NEFilterDataProvider. Nunha implantación xestionada empurraa o MDM, instálase como extensión de sistema e apróbase unha vez en Axustes do Sistema > Xeral > Elementos de inicio e extensións. A partir de aí ve fluxos TCP, e nalgunhas configuracións tamén UDP, e devolve un veredicto para cada un.
O modo de fallo é o que confunde á xente. Un filtro que descarta un fluxo produce un tempo de espera esgotado, un aperto de man TLS atascado ou un reinicio, que se parece exactamente a un túnel levantado que non pode pasar tráfico. O enderezo público nunca cambiou, porque nunca houbo unha saída que o cambiase.
Os clientes comerciais adoitan agrupar ambos os papeis. Un só instalador trae un provedor de túnel e un filtro, o filtro fai o bloqueo e o túnel fai o encamiñamento. Así que o nome da aplicación non lle di nada sobre que compoñente rexeitou a conexión. Revise a lista de extensións, despois o servizo conectado e despois o rexistro do cliente, nesa orde.
Private Relay cobre Safari, non a máquina
Private Relay envía a navegación que cobre a través de dous retransmisores operados por partes separadas, de modo que ningún operador único ten á vez a súa identidade e os seus destinos. É un deseño de privacidade, non un túnel: non hai porta á que entrar, nin subrede privada, nin forma de fixar un enderezo de saída nun país que vostede elixa.
O seu alcance é deliberadamente estreito: cobre a navegación de Safari xunto coas consultas DNS e as cargas HTTP inseguras que a acompañan. Unha sesión de terminal, un cliente de correo, unha aplicación de chat e un lanzador de xogos quedan fóra. Se unha comprobación no Terminal segue mostrando o enderezo da súa rede de acceso mentres Safari mostra un enderezo de retransmisor, ese é o resultado esperado, non unha instalación rota.
A dispoñibilidade é condicional. Require un plan iCloud+, non se ofrece en todas as rexións e unha rede xestionada pode bloquear o acceso ao retransmisor, caso en que Safari volve a unha conexión directa. A descrición xeral de Private Relay de Apple é a referencia do alcance actual. Cando un perfil VPN está conectado e transporta ese tráfico, o retransmisor non se apila enriba; o perfil decide a ruta.
Lea as probas na orde correcta
Empece polo estado do servizo, porque é o sinal máis barato. scutil --nc list lista os servizos VPN configurados e se cada un está conectado. Un perfil pode quedar aí durante anos sen conectarse nunca, e a xente adoita contalo como un túnel.
Despois mire interfaces e rutas. ifconfig mostra interfaces utun, pero a súa presenza por si soa proba pouco, xa que macOS usa utun para varios fins ademais da VPN. O que importa é se a ruta predeterminada apunta a unha delas, algo que informa route -n get default.
Para a resolución de nomes, scutil --dns lista os resolutores que o sistema realmente usará, e alí aparece un provedor de proxy DNS. Comparar dig +short example.com con dig +short example.com @1.1.1.1 separa o resolutor que responde do resolutor que está a ser interceptado.
A actividade das extensións chega ao rexistro unificado: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Vostede busca que extensión arrincou e se un filtro informou dun veredicto sobre o fluxo que lle importa, non unha liña para memorizar.
Acinte o síntoma antes de desactivar nada
Clasifique primeiro o fallo. Un nome que non se resolve, unha conexión rexeitada de inmediato e unha conexión que se colga ata o tempo de espera son tres observacións distintas con tres responsables distintos. A resolución apunta a un resolutor ou a un proxy DNS. Un rexeitamento inmediato apunta a unha regra do filtro. O silencio adoita apuntar ao encamiñamento, ou a un túnel que está levantado pero non reenvía.
Nun Mac xestionado, dea por feito que o filtro pertence á organización. Desactivalo para probar a VPN elimina o compoñente que quería observar, e o MDM adoita restauralo na seguinte comprobación. Pida ao administrador o nome da política antes de cambiar nada, e probe coa aplicación concreta que fallou en lugar de con todo o sistema.
Outra trampa: apagar Private Relay para probar unha VPN non di nada sobre o tráfico estranxeiro, porque o retransmisor nunca cubriu ese tráfico. Cada capa debe probarse na aplicación que realmente goberna.
Percorra esta lista e detéñase no primeiro punto que falle:
scutil --nc listmostra como conectado o servizo que vostede espera?- O enderezo público visto desde o Terminal difire do enderezo que asignou a súa rede de acceso?
- Hai unha extensión de filtro instalada, e rexistrou un veredicto para o fluxo que falla?
- O fallo é só en Safari? Se é así, revise o alcance do retransmisor antes de culpar o túnel.
Se os catro puntos pasan e a aplicación segue fallando, o problema está por riba da capa de rede: axustes de proxy, confianza en certificados ou unha lista de permitidos a nivel de aplicación.