Filtrar y canalizar el tráfico de red con NetworkExtension

Hola, soy María Alicia Dos Santos, del equipo de Internet Technologies de Apple. Voy a contarte todo sobre la estructura de Extensión de Red y sus avances más recientes en iOS y macOS 26.

Esta es una estructura que proporciona un amplio conjunto de API para que crees apps que amplíen y personalicen las capacidades de red en plataformas Apple.

Las apps de Extensión de Red funcionan a la perfección en toda la pila de redes, y se integran estrechamente con la estructura de red, CFNetwork, WebKit y la API de Sockets, así como con componentes a nivel de sistema. Esto le permite lograr las funcionalidades deseadas de la manera más optimizada en términos de rendimiento y seguridad de red.

Extensión de Red es una estructura potente que permite modificar redes en todo el sistema. Para garantizar que tu app funcione correctamente con otras apps y el sistema, debes elegir la API adecuada para el tipo de app que quieres crear.

Aquí, te presentaré la amplia gama de apps que puedes crear con la Estructura de Extensión de Red y las formas en que puedes crear apps para acceder a recursos remotos con retransmisiones y VPN. También explicaré cómo crear filtros de contenido con la estructura, incluida una nueva forma de crear un filtro basado en URL en iOS y macOS 26. La estructura admite varias formas para que las apps personalicen y amplíen las capacidades de red.

Las API de gestión de Wi-Fi y puntos de acceso permiten a las apps configurar el Wi-Fi e interactuar con puntos de acceso. Esto incluye la API de extensión NEHotspotHelper en iOS 26.

Y las apps de iOS pueden usar la API Local Push. Esto es para las apps que se usan en redes sin acceso al Apple Push Notification Service, como cruceros u hospitales. Puedes admitir funcionalidades como la mensajería de texto mientras se está en la red restringida.

Puedes crear una app para proteger el tráfico DNS de ataques con la configuración DNS y la API de proxy. Puedes instalar una configuración DNS y usar estos protocolos DNS encriptados o el tráfico del proxy DNS en tu canal de seguridad.

Con la API de proxy transparente, las apps de Mac pueden, por ejemplo, desviar el tráfico de una web a un servicio de seguridad en la nube para autenticar y autorizar. También puedes crear apps que permitan a las personas acceder a recursos remotos de forma segura o que las protejan filtrando el contenido al que acceden en la red.

El acceso remoto seguro incluye diferentes formas de conectarse a sistemas internos de forma segura desde afuera, o de proteger el tráfico personal en redes no seguras canalizando el tráfico desde un dispositivo a un servidor remoto. Con la Extensión de Red, hay dos métodos que considerar. Retransmisiones de red y VPN basada en IP. Usa la que mejor se adapte a tus necesidades según el tráfico que quieras canalizar. Elige las retransmisiones de red si quieres canalizar el tráfico TCP o UDP para acceder a apps específicas. Por ejemplo, las apps empresariales en la nube son ideales para las retransmisiones. El protocolo MASQUE permite proxy seguro y optimizado para el rendimiento. Se integra fácilmente en entornos de nube modernos. Y como la plataforma tiene soporte integrado para retransmisiones, no hace falta crear tu propia extensión. Puedes configurar la configuración de retransmisión y autenticación con NERelayManager o con un perfil de configuración del servidor de MDM. Si quieres canalizar el tráfico IP, usa la opción de VPN. Por ejemplo, las VPN basadas en IP se pueden usar en la empresa para extender la red corporativa al personal y darles acceso completo como si estuvieran en la oficina. Esta solución es ideal para el personal de confianza que necesita acceso continuo a la red de la empresa.

O puede que las organizaciones con políticas de seguridad de red estrictas tengan que enviar el tráfico desde sus dispositivos gestionados a través de su red.

Puede que las personas también deseen proteger su tráfico con una VPN en redes no seguras y preservar su privacidad.

Para crear un túnel VPN basado en IP, usa NEVPNManager para aprovechar uno de los protocolos integrados, IKEv2 o IPsec, o NEPacketTunnelProvider para usar tus propios protocolos personalizados. Al crear una VPN basada en IP, la implementación le dice al sistema qué tráfico debe canalizar, con las rutas incluidas y excluidas. En macOS, un administrador u otro proceso podría modificar la tabla de enrutamiento fuera de la app. Las rutas más precisas podrían interferir con las de tu VPN. La Extensión de Red le permite a la app aplicar sus rutas para que tengan prioridad y se cumplan en todo momento. También facilita la administración de los requisitos de enrutamiento de los túneles. Con una VPN de túnel dividido, puedes activar enforceRoutes para aplicar tanto las rutas incluidas como las excluidas. Para una VPN de túnel completo, puedes activar includeAllNetworks para hacer que todo el tráfico se enrute por el túnel. Cuando se activa esta opción, las rutas de excludedRoutes no tienen efecto. Ambas admiten excepciones para permitir que un conjunto de tráfico definido por el sistema salga del túnel para que los servicios esenciales funcionen mientras se usa la VPN. Por ejemplo, activa excludeLocalNetworks si quieres que los servicios como AirDrop y AirPlay omitan el túnel. O activa otras excepciones para que servicios como llamadas y mensajes, Apple Push Notification Service y la comunicación del dispositivo omitan el túnel. La mayoría de estas excepciones ya vienen activadas, pero te permiten personalizarlas.

Extensión de Red es la API compatible para crear una app VPN. Funciona muy bien con otros componentes de red y del sistema. Se desaconseja crear una app VPN con cualquier otra cosa. No uses el filtro de paquetes ni modifiques la tabla de enrutamiento en la Mac. Esto no es compatible y corres el riesgo de entrar en conflicto con las reglas de filtrado y enrutamiento instaladas. Si tu app VPN no utiliza Extensión de Red actualmente, debes migrarla lo antes posible. Esto garantizará que la app siga siendo compatible con el sistema y con todas las funcionalidades clave que los clientes esperan, como trabajar en armonía con funcionalidades como AirDrop, la Pantalla virtual de la Mac y Xcode. Solo usa NEPacketTunnelProvider para canalizar el tráfico IP. No se recomienda su uso para lograr otros objetivos. NEPacketTunnelProvider funciona en la capa IP y no recibe los metadatos de flujo o de nivel de aplicación necesarios para hacer otras cosas, como enviar solicitudes de DNS. Si buscas filtrar contenido, usa la API de filtro de contenido. Esta API permite realizar una introspección del tráfico en el dispositivo para monitorear o tomar decisiones de filtrado a medida que el tráfico fluye. Un uso común es un firewall personal, que examina y bloquea flujos de tráfico que considera maliciosos para un dispositivo personal. O una app de monitoreo del tráfico empresarial para dispositivos gestionados que supervise el tráfico de red entrante y saliente en entornos de alta seguridad.

Crea una subclase de uno o ambos proveedores de filtros para obtener el tráfico deseado. NEFilterDataProvider proporciona flujos TCP y UDP, así como otros tráficos de protocolo IP, como ICMP.

Para Mac, una subclase de NEFilterPacketProvider recibirá paquetes Layer 2.

Los proveedores no pueden cambiar el tráfico: le ofrecen un veredicto al sistema para permitir o descartar el flujo. El filtro de contenido de iOS solo se admite en dispositivos supervisados.

Los filtros de contenido que usan NEFilterDataProvider y NEFilterPacketProvider sirven si tu app necesita filtrar según el flujo de tráfico o con la inspección de paquetes. Pero puede que quieras filtrar según los metadatos a nivel de aplicación, como la URL. Con un filtro de contenido tradicional, tu app puede tomar decisiones de filtrado en función de la información a nivel de tráfico.

Puede que algunas apps no quieran bloquear sitios enteros y solo filtren ciertos recursos. Las solicitudes HTTPS están encriptadas, por lo que un filtro de contenido tradicional no tendría acceso a los detalles necesarios de la solicitud de URL para tomar una decisión precisa, como el recurso específico solicitado. A partir de iOS 26, puedes crear un filtro de URL, que toma decisiones de filtrado de contenido en función de la URL completa. El filtro de URL de Extensión de Red filtra solicitudes HTTP y HTTPS en todo el sistema y las compara con la URL entera de la solicitud. Esta tecnología te permite crear apps que bloquean recursos específicos en Internet. Por ejemplo, puedes crear apps de control parental para proteger a niños de sitios nocivos. Una app para escuelas podría usar un filtro para impedir que los estudiantes accedan a redes sociales, apuestas u otro contenido confidencial. O es posible que una empresa quiera bloquear el contenido no relacionado con el trabajo.

Para Apple, la privacidad es un derecho humano básico. El filtrado de URL usa criptografía moderna para que crees apps que tomen decisiones de filtrado basadas en la URL entera, sin arriesgar la privacidad. Las URL pueden revelar información confidencial, como identificadores únicos. La Extensión de Red está diseñada para permitirte crear un filtro de contenido que tome decisiones en función de la URL entera. Pero el contenido de la URL no se revela a la app y las consultas de la base de datos a servidores backend se anonimizan. La cadena de servidores backend, tanto de Apple como tuyos, no tendrá acceso a la información de contenido ni de identidad. El filtrado se realiza con tu conjunto de datos de URL, que incluye las URL que quieres bloquear. Proporcionas un prefiltro en el dispositivo y un servidor de base de datos fuera de este para búsquedas de URL. El sistema realiza todo el proceso de filtrado por ti con tu conjunto de datos. Tu app no se ejecuta en la ruta de filtrado y no tiene acceso al tráfico. El sistema realiza un prefiltro en el dispositivo para mejorar el rendimiento y puede realizar búsquedas en bases de datos fuera de este para obtener un veredicto final. Los intercambios de bases de datos fuera del dispositivo están protegidos para garantizar la privacidad. Los filtros de URL son compatibles tanto con dispositivos administrados como no administrados. Antes de explicar cómo funciona esta funcionalidad, hablaré de las tecnologías que la componen. Hay cuatro tecnologías en las que se basa el filtro de URL, que son: Filtros Bloom, recuperación de información privada, pase de privacidad y retransmisión Oblivious HTTP.

Primero, los filtros Bloom.

Para filtrar URL, la Extensión de Red usará el filtro que crees con tu conjunto de datos que contiene las URL a bloquear. El filtro se crea a partir de un conjunto de datos predefinido, se aplica un hash a cada elemento y se configuran los bits correspondientes en una matriz de bits de tamaño fijo. Una vez creado, puedes usar el filtro para probar si un elemento es miembro del conjunto. Estos filtros nunca darán falsos negativos, pero sí pueden dar falsos positivos.

Tu filtro se usará como prefiltro para una verificación rápida. Si la coincidencia es negativa, la URL verificada definitivamente no es parte de tu conjunto de datos y se permitirá sin verificación adicional. Si el resultado es positivo, no es definitivo por posibles falsos positivos. Será necesaria una verificación adicional para llegar a un veredicto concluyente.

El uso como prefiltro reduce las búsquedas en bases de datos fuera del dispositivo y mejora el rendimiento.

Otra tecnología clave es la recuperación de información privada. La recuperación de información privada, o PIR, permite al cliente buscar en una base de datos de valores de palabras clave sin revelar la palabra clave consultada ni el resultado de la búsqueda al servidor. Se basa en la encriptación homomórfica, que permite que el servidor de recuperación de información privada realice búsquedas en bases de datos sobre consultas encriptadas. Así que el servidor no accede a la consulta ni a la respuesta.

Así es como funciona. El cliente en el dispositivo genera la clave de encriptación y la mantiene privada, y se encriptan las consultas enviadas al servidor. Y el servidor usa las consultas encriptadas para buscar en bases de datos. El servidor no puede desencriptar la consulta en ningún momento. El servidor envía respuestas encriptadas al cliente. El cliente recibe y desencripta respuestas en el dispositivo. Solo el cliente (y no el servidor) puede desencriptar la respuesta del servidor. Luego el cliente usa los resultados de la búsqueda. La recuperación de información privada ya es una tecnología usada para muchas funciones de preservación de privacidad. Para el filtrado de URL, el servidor de recuperación de información privada realiza búsquedas de URL con consultas encriptadas, por lo que no sabe qué URL se están solicitando y qué resultados se están devolviendo. La tercera tecnología es el pase de privacidad. La recuperación de información privada la usa para la autenticación anónima en tu servidor. Esto te permite garantizar que tu servidor solo responda a consultas de dispositivos autenticados y autorizados, sin rastrear historiales de solicitudes individuales. Cada dispositivo pasa por una certificación inicial para obtener una credencial a largo plazo, que se usa para recuperar tokens firmados criptográficamente de forma ciega del emisor del pase. El dispositivo usa estos tokens para autenticarse con tu servidor sin revelar la identidad. Por último, retransmisión Oblivious HTTP. Es un proxy que preserva la privacidad y oculta la dirección IP del origen, lo evita que el servidor rastree y vincule solicitudes a lo largo del tiempo. Tiene tres entidades: el cliente, la retransmisión y la puerta de enlace. El cliente encripta solicitudes con la clave pública de la puerta de enlace. Luego envía la solicitud encriptada a la retransmisión. La retransmisión quita la dirección IP del cliente de las solicitudes entrantes y las reenvía a la puerta de enlace. La puerta de enlace desencripta la solicitud y la envía al recurso de destino. La retransmisión no recibe el contenido de las solicitudes, y la puerta de enlace y el recurso de destino no saben de dónde proviene el tráfico.

Hablé sobre las cuatro tecnologías. Explicaré cómo configurar la solución y cómo funciona el filtrado de URL.

Con la app de filtro de URL instalada, tu app proporcionará una Extensión de Red, tu conjunto de datos de URL, como un filtro Bloom y como una base de datos URL alojada en tu servidor de recuperación de información privada.

La configuración del servidor incluye un emisor de pases de privacidad para la autenticación anónima.

Tu app de filtro de URL le indica a Extensión de Red cómo llegar al servidor de recuperación de información privada. Tu app usa una nueva extensión para traer el filtro Bloom al dispositivo.

Las consultas y respuestas de la base de datos se transmiten por la retransmisión Oblivious HTTP de Apple. Es decir que alojarás la puerta de enlace de Oblivious HTTP para reenviar tráfico al servidor.

Haz una solicitud con Oblivious HTTP para el flujo de filtrado de URL con una retransmisión Oblivious HTTP de Apple.

Esta es una capacidad que debes solicitar en el formulario de solicitud de la documentación. Apple validará la configuración de tu servidor para la retransmisión antes de aprobarla. Debes hacerlo antes de que puedas distribuir tu app en App Store, con TestFlight, ad-hoc, ID de desarrollador o compilaciones de empresa. Las compilaciones firmadas por el desarrollador están exentas de este requisito, así puedes compilar y probar tu app de inmediato.

Con todas las piezas en su lugar, daré un ejemplo de cómo funciona el filtrado de URL. El sistema realizará el filtrado de URL. Tu app y la extensión no se ejecutan en esta ruta. El sistema examina las solicitudes y compara cada URL con tu conjunto de datos. Aquí, un navegador inicia una solicitud de URL a un recurso específico en example.com. El sistema comprobará primero la URL solicitada con el filtro Bloom. Una coincidencia negativa del filtro significa que la URL no está en tu conjunto de datos. Se permitirá la URL y el navegador procederá con la solicitud HTTP.

Ahora, el navegador inicia otra solicitud de URL para un recurso diferente, que obtiene una coincidencia positiva del filtro Bloom. Por posibles falsos positivos, esto significa que la URL podría estar en tu conjunto de datos. Aquí, el sistema buscará por fuera del dispositivo con tu servidor de recuperación de información privada y le enviará una consulta encriptada. En el servidor, se realiza una búsqueda en la base de datos para obtener un resultado coincidente. El servidor no tiene conocimiento de cuál es la consulta ni la respuesta. El servidor encripta el resultado y responde.

El sistema del dispositivo desencripta la respuesta. Se rechazará la URL y la solicitud si el resultado devuelto indica coincidencia.

El filtrado de URL de Extensión de Red se realiza en el sistema. Comprueba todas las solicitudes HTTP enviadas a través de las API de redes de Apple. Sin embargo, para las apps que no usan estas API de red, el sistema no verificará automáticamente su tráfico HTTP. Para quienes crean un navegador o app que no use WebKit o URLSession, usen la API de participación para verificar solicitudes de URL antes de enviarlas. Llama a NEURLFilter verdictForURL con la URL de la solicitud y respeta el veredicto rechazando la solicitud si se deniega la URL. Ahora que sabes cómo funcionan los filtros de URL, te explicaré cómo crear uno. Configura tu servidor de recuperación de información privada y crea tu filtro Bloom. Luego, crea tu app de filtro de URL y su extensión.

Comenzaré con la configuración del servidor. Usa el código de muestra para comenzar, que proporciona un servidor de muestra. En el repositorio del proyecto encontrarás implementaciones de muestra del servidor y también un emisor de pases de privacidad. Para personalizarlo para el filtrado de URL, crea un caso de uso con un formato de nombre específico. El nombre debe tener el identificador del paquete de tu app como prefijo, seguido de la cadena url.filtering.

El servidor almacena registros de datos en un formato clave-valor. Para el filtro de Extensión de Red, formatea tu conjunto de datos configurando cada registro con la cadena de URL como clave y el valor en el entero 1. El segundo paso es crear tu filtro Bloom. Crea el filtro Bloom con tu conjunto de datos de URL con las funciones hash y el método especificados, documentados para la API NEURLFilterControlProvider. Según qué tan estático o dinámico sea tu conjunto, decide cómo enviar tu filtro al dispositivo y cada cuánto actualizarlo. Para conjuntos de datos estáticos, incluye tu filtro Bloom en el paquete de la app y deja que la extensión lo obtenga de los recursos del paquete. Las actualizaciones del filtro se pueden incluir con las actualizaciones de tu app. Para datos dinámicos, configura el sistema para que active la búsqueda periódicamente. Cuando se activa la búsqueda, la extensión de tu app puede descargar el filtro Bloom desde el servidor. Lo que sigue es crear tu app de filtro de URL. Agrega la autorización url-filter-provider de Extensión de Red a tu app, que te permite usar las API de filtro de URL. Usa NEURLFilterManager en tu app para crear configuraciones y administrar el filtro de URL. Importa la estructura de Extensión de Red y usa la instancia Singleton compartida de NEURLFilterManager. Puedes configurar y habilitar tu filtro en unos pocos pasos. Carga la instantánea más reciente de la configuración del filtro desde el disco, si la hay. Establece el atributo obligatorio en la configuración para indicar al sistema cómo comunicarse con tu servidor de recuperación de información privada, y puedes configurar otros parámetros opcionales.

Por último, habilita y guarda la configuración del filtro. Ahora tendrá efecto el filtro de URL.

El filtro URL admite implementaciones del consumidor y de empresas. Para la implementación empresarial a escala, envía el perfil de configuración del filtro a través de Mobile Device Management a los dispositivos gestionados. La carga útil existente del filtro de contenido admite: una clave para activar el filtro de URL, así como un diccionario para configurar los parámetros del filtro. La configuración del filtro de MDM requiere la supervisión del dispositivo.

Ahora, debes crear la extensión de tu app de filtro de URL. Para crear la extensión de tu app, usa la nueva plantilla en Xcode. Implementa el protocolo NEURLFilterControlProvider como extensión. Este protocolo permite a la extensión obtener el filtro Bloom en el dispositivo. Importa la estructura de Extensión de Red e implementa el protocolo NEURLFilterControlProvider. El sistema invocará la implementación de la función fetchPrefilter para obtener el filtro Bloom, según el intervalo que hayas configurado. En tu implementación, busca el filtro Bloom y devuélvelo al sistema. La implementación puede recuperar los datos del filtro Bloom de los recursos del paquete de la app o descargándolos de tu servidor. Antes de enviar tu app a App Store o TestFlight, verifica que tu solicitud de capacidad se haya enviado y aprobado, para que las solicitudes puedan moverse a través de la puerta de enlace de Oblivious HTTP. Extensión de Red es una estructura tan potente que te permite hacer túneles y filtrar el tráfico y mucho más. Revisa cómo usas la Extensión de Red. Usa una API adecuada que te ayude a crear apps con la funcionalidad deseada y que funcionen bien con el sistema. Usa retransmisiones de red para un acceso remoto seguro para el tráfico TCP y UDP. Usa Extensión de Red para crear soluciones VPN. Crea filtros de contenido con la API de filtro de URL de Extensión de Red. Para empezar, consulta el servidor y la app de muestra. Gracias por mirar.