¿Qué herramienta de macOS puede obligar a una sola app a pasar únicamente por la VPN?
Un límite de solo VPN necesita un camino y un rechazo. Compare perfiles por app, proxys, filtros y PF, y luego pruebe la app que le importa.
Una línea en un documento de requisitos, «esta app puede usar la VPN y nada más», pide en voz baja dos mecanismos que ningún interruptor ofrece. El tráfico necesita un camino a través del túnel previsto, y el tráfico que saldría directamente debe ser rechazado. Las herramientas que hacen bien una de esas cosas y la otra no hacen nada son frecuentes, por eso una comparación que solo pregunta si algo puede bloquear responde con confianza la mitad de la pregunta. Escriba primero el límite y después elija los componentes que cubren sus dos mitades.
Dos requisitos escondidos en una sola frase
El direccionamiento es la parte que pone una conexión en el túnel o en el proxy. El rechazo es la parte que impide que la misma conexión salga por cualquier otra ruta. Los implementan componentes distintos, fallan de maneras distintas, y un producto puede ser excelente en uno y no decir nada del otro:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
Lea la tabla como una lista de comprobación y no como una clasificación. Ninguna fila llena las dos columnas centrales, y las filas que las cubren son dos componentes que cooperan: uno posee el camino y el otro posee el rechazo. La columna de identidad importa por otro motivo, porque una regla que no puede nombrar la app no puede aplicar una regla sobre esa app. Sea lo que sea que despliegue, tiene que responder a las tres, o el límite del documento de requisitos no es el límite de la máquina.
El direccionamiento por sí solo deja una salida
La configuración de proxy de aplicación es el ejemplo más claro de direccionamiento sin rechazo. Puede dirigir peticiones de una app que respeta el proxy del sistema y no cubre nada más: un proceso auxiliar, un actualizador, un servicio en segundo plano o un protocolo distinto pueden viajar por su propio camino sin leer nunca esa preferencia. Por eso, elegir un extremo SOCKS en un panel no crea una política de salida directa prohibida para la aplicación. Si el requisito es sobre la app en su conjunto, pregunte qué componentes identifica realmente la regla.
Un perfil de VPN por app direcciona mejor que un proxy, porque la plataforma decide qué apps entran en el túnel en lugar de que cada app decida por sí misma. Aun así no rechaza nada: el perfil suministra un camino, y el tráfico que no encaja con él toma la ruta ordinaria. Esa grieta es exactamente donde un segundo componente se gana su lugar, y es la razón de que los productos que parecen un solo interruptor suelan ser dos.
El rechazo por sí solo rompe la app
La documentación de Apple sobre filtros de contenido describe un veredicto de permitir o bloquear sobre el tráfico mientras pasa por la pila de red. Ese veredicto no es un túnel ni una conexión de proxy, porque decide si algo puede continuar y no hacia dónde va. Un filtro por sí solo aplica el rechazo a la perfección y deja la aplicación inservible, con registros limpios y sin explicación. El veredicto de un filtro puede detener una conexión pero nunca suministra el túnel, así que emparejarlo con el direccionamiento es la decisión de diseño y no un extra opcional.
Un conjunto de reglas PF administrado localmente se sitúa en el otro extremo de ese espectro. Es una decisión de soporte legítima en una máquina que posee un administrador, y no es automáticamente la base de un producto distribuible, porque quien posee el conjunto de reglas también posee sus interacciones con otros usuarios del cortafuegos, su ruta de actualización y su recuperación cuando una regla es incorrecta. Añadir PF a un producto no elimina esa cuestión de propiedad; la define.
El despliegue decide si la regla seguirá existiendo mañana
Cómo se despliega una Network Extension en las plataformas de Apple depende del tipo de proveedor, del empaquetado y de la versión del sistema operativo que tenga delante. Una extensión de app en macOS se ejecuta en un contexto de usuario y termina cuando ese usuario cierra la sesión, mientras que una extensión de sistema tiene un contexto global que no depende de la sesión. Si la protección debe sobrevivir a un cierre de sesión, esa diferencia es todo el diseño y no una nota a pie de página. Confirme la ruta de despliegue antes de prometer el comportamiento, porque el mismo código aterriza de forma distinta según qué tipo de extensión se entregue.
La disponibilidad del código fuente es un asunto aparte de la aplicación. Leer un repositorio le dice cómo está implementado algo, no qué puede hacer el binario instalado en esta máquina. La firma, la instalación y la autorización siguen aplicándose, y las instrucciones construidas en torno a una extensión de kernel obsoleta o a un truco de inyección de biblioteca describen otra plataforma y otra postura de riesgo, por bien que funcionaran en su momento.
Un caso de aceptación que nombra la app
Elija una sola acción que la aplicación realice por su cuenta, anote la dirección a la que debería llegar y si esa dirección es IPv4 o IPv6, y repita después la misma acción en el estado aprobado sin túnel. La segunda ejecución tiene que producir el rechazo declarado y no un reintento directo silencioso. Esa es la mitad que la gente deja sin especificar, y la única mitad que demuestra que el rechazo existe. Ejecútelo primero con el túnel disponible, para que una diferencia entre los dos resultados solo pueda venir del túnel ausente.
Después recorra las transiciones que el requisito nombra: reiniciar la app, la activación de un proceso auxiliar, la reconexión del túnel, el cambio de redes de la máquina y un cierre de sesión o reinicio donde correspondan. Una página de IP pública del navegador no es una prueba de los sockets de otra aplicación, así que no puede sustituir a esta. Donde ningún despliegue soportado cubra el comportamiento real de la app, un entorno aislado autorizado con una puerta de enlace explícita y sin salida alternativa es una decisión de contención con su propio coste de gestión, no un sustituto de una casilla de verificación.
Termine escribiendo cuatro entradas: qué componentes forman la app, quién posee el direccionamiento, quién posee el rechazo y los estados en los que la regla debe seguir valiendo. Un repositorio público puede ser un criterio de selección, pero no es una de las cuatro, y esas entradas son las que deciden si una herramienta dada cumple el requisito de red.