VPN del Mac, filtro de contenido o Private Relay: cuál está activo
Tres capas de red del Mac se parecen en Ajustes. Distinga una VPN, un filtro de contenido y Private Relay por la ruta de salida, la política de flujos y el alcance de navegación.
Su Mac puede tener instalados a la vez un túnel VPN, un filtro de contenido y iCloud Private Relay, y ninguno de ellos anuncia cuál está modelando una conexión concreta. Los paneles de ajustes se parecen, los iconos se parecen y casi todos los fabricantes llaman seguridad de red a su producto. Tres hechos los separan: si el tráfico sale por un punto remoto que usted pueda nombrar, si un motor de políticas decide permitir o descartar flujos individuales, y si la protección termina en Safari. Con esos tres puntos claros, la mayoría de las preguntas de si-mi-VPN-está-activa se responden solas.
Tres condiciones que identifican el componente
La primera condición es la salida. Un proveedor de túnel entrega los paquetes a una puerta de enlace remota, así que su dirección pública cambia y, si el perfil lo indica, los equipos detrás de esa puerta resultan accesibles. Si la dirección nunca cambia y no se abre ninguna subred privada, no está viendo un túnel funcional, diga lo que diga la barra de menús.
La segunda condición es la decisión. Un filtro de contenido evalúa flujos y devuelve permitir o descartar. Puede imponer un bloqueo de categoría, una regla por aplicación o una política enviada por el empleador, y puede registrar el veredicto. Lo que no puede hacer por sí solo es dar al tráfico un lugar adonde ir.
La tercera condición es el alcance. Private Relay protege una porción definida de la navegación y no un dispositivo entero, y su trabajo es separar quién es usted de lo que visita, no situarlo en otra red.
Póngalos uno junto a otro y los 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 contenido es un motor de políticas, no una salida
En macOS un filtro llega como una Network Extension construida sobre la clase de proveedor de datos de filtrado de Apple, NEFilterDataProvider. En una implementación gestionada lo empuja el MDM, se instala como extensión de sistema y se aprueba una vez en Ajustes del Sistema > General > Ítems de inicio y extensiones. A partir de ahí ve flujos TCP, y en algunas configuraciones también UDP, y devuelve un veredicto para cada uno.
El modo de fallo es lo que confunde a la gente. Un filtro que descarta un flujo produce un tiempo de espera agotado, un apretón de manos TLS atascado o un reinicio, que se parece exactamente a un túnel levantado que no puede pasar tráfico. La dirección pública nunca cambió, porque nunca hubo una salida que la cambiara.
Los clientes comerciales suelen agrupar ambos papeles. Un solo instalador trae un proveedor de túnel y un filtro, el filtro hace el bloqueo y el túnel hace el enrutamiento. Así que el nombre de la aplicación no le dice nada sobre qué componente rechazó la conexión. Revise la lista de extensiones, luego el servicio conectado y luego el registro del cliente, en ese orden.
Private Relay cubre Safari, no la máquina
Private Relay envía la navegación que cubre a través de dos retransmisores operados por partes separadas, de modo que ningún operador único tiene a la vez su identidad y sus destinos. Es un diseño de privacidad, no un túnel: no hay puerta a la que entrar, ni subred privada, ni forma de fijar una dirección de salida en un país que usted elija.
Su alcance es deliberadamente estrecho: cubre la navegación de Safari junto con las consultas DNS y las cargas HTTP inseguras que la acompañan. Una sesión de terminal, un cliente de correo, una aplicación de chat y un lanzador de juegos quedan fuera. Si una comprobación en Terminal sigue mostrando la dirección de su red de acceso mientras Safari muestra una dirección de retransmisor, ese es el resultado esperado, no una instalación rota.
La disponibilidad es condicional. Requiere un plan iCloud+, no se ofrece en todas las regiones y una red gestionada puede bloquear el acceso al retransmisor, en cuyo caso Safari vuelve a una conexión directa. La descripción general de Private Relay de Apple es la referencia del alcance actual. Cuando un perfil VPN está conectado y transporta ese tráfico, el retransmisor no se apila encima; el perfil decide la ruta.
Lea las pruebas en el orden correcto
Empiece por el estado del servicio, porque es la señal más barata. scutil --nc list lista los servicios VPN configurados y si cada uno está conectado. Un perfil puede quedarse ahí durante años sin conectarse nunca, y la gente suele contarlo como un túnel.
Luego mire interfaces y rutas. ifconfig muestra interfaces utun, pero su presencia por sí sola prueba poco, ya que macOS usa utun para varios fines además de la VPN. Lo que importa es si la ruta predeterminada apunta a una de ellas, algo que informa route -n get default.
Para la resolución de nombres, scutil --dns lista los resolutores que el sistema realmente usará, y ahí aparece un proveedor de proxy DNS. Comparar dig +short example.com con dig +short example.com @1.1.1.1 separa el resolutor que responde del resolutor que está siendo interceptado.
La actividad de las extensiones llega al registro unificado: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Usted busca qué extensión arrancó y si un filtro informó de un veredicto sobre el flujo que le importa, no una línea para memorizar.
Acinte el síntoma antes de desactivar nada
Clasifique primero el fallo. Un nombre que no se resuelve, una conexión rechazada de inmediato y una conexión que se cuelga hasta el tiempo de espera son tres observaciones distintas con tres responsables distintos. La resolución apunta a un resolutor o a un proxy DNS. Un rechazo inmediato apunta a una regla del filtro. El silencio suele apuntar al enrutamiento, o a un túnel que está levantado pero no reenvía.
En un Mac gestionado, dé por hecho que el filtro pertenece a la organización. Desactivarlo para probar la VPN elimina el componente que quería observar, y el MDM suele restaurarlo en la siguiente comprobación. Pida al administrador el nombre de la política antes de cambiar nada, y pruebe con la aplicación concreta que falló en lugar de con todo el sistema.
Otra trampa: apagar Private Relay para probar una VPN no dice nada sobre el tráfico extranjero, porque el retransmisor nunca cubrió ese tráfico. Cada capa debe probarse en la aplicación que realmente gobierna.
Recorra esta lista y deténgase en el primer punto que falle:
- ¿Muestra
scutil --nc listel servicio que usted espera como conectado? - ¿Difiere la dirección pública vista desde Terminal de la dirección que asignó su red de acceso?
- ¿Hay una extensión de filtro instalada, y registró un veredicto para el flujo que falla?
- ¿El fallo es solo en Safari? Si es así, revise el alcance del retransmisor antes de culpar al túnel.
Si los cuatro puntos pasan y la aplicación sigue fallando, el problema está por encima de la capa de red: ajustes de proxy, confianza en certificados o una lista de permitidos a nivel de aplicación.