Bloqueo de VPN con PF en Mac: una política de sitio, no una función distribuible

Funciona en su Mac, así que parece algo que puede entregar a los usuarios. Esa suposición es lo primero que hay que perder. El TN3165 de Apple afirma con claridad que Packet Filter no es una API compatible para productos distribuidos de forma general, y presenta la administración de sitio privilegiada y controlada como el caso razonable. Por tanto, un bloqueo de VPN construido sobre PF es una política operativa local con un propietario, no una función que pueda distribuirse dentro de una aplicación.

PF no es una superficie de empaquetado

La distinción no es académica. Un producto distribuido que depende de PF hereda cada cambio que Apple le hace, cada conflicto con otra herramienta que también escribe reglas, y ningún compromiso de soporte de que el arreglo siga funcionando. Un sitio que administra sus propias máquinas tiene una relación distinta: puede documentar la dependencia, probarla con cada versión del sistema operativo y aceptar el mantenimiento.

Algunos consejos de instalación cruzan una línea que conviene nombrar. Sobrescribir todo el conjunto de reglas del sistema para que se cargue un solo ancla, editar la configuración de arranque del sistema de Apple o desactivar System Integrity Protection no son requisitos aceptables para una receta reutilizable. Si una guía publicada necesita cualquiera de esas cosas, describe un laboratorio, no una política desplegable.

Escriba la intención de salida antes de la sintaxis

Decida qué está permitido antes de elegir una sola palabra clave. Por lo general deben existir tres rutas: el transporte propio del cliente VPN hacia su servidor, el tráfico de la aplicación protegida dentro del túnel y todo lo que la configuración o los servicios locales realmente requieren como ruta directa.

Dé a cada excepción propuesta un destino, un transporte y un propietario. Permitir todos los puertos hacia un extremo permite mucho más que el único transporte que usa el túnel, y la exposición adicional llega sin que nadie haya decidido que deba existir. Permitir un resolutor público es la misma trampa con un disfraz más amable: crea una ruta DNS directa incluso mientras el túnel está caído, así que las consultas de nombres siguen filtrándose.

La prueba útil para una excepción es si puede nombrar a la persona que la pidió y el fallo que evita. Si no existe ninguna de las dos respuestas, la regla es probablemente un rodeo para una configuración incorrecta que de otro modo permanecería invisible.

Los números utun no son una identidad

MacOS crea interfaces de túnel como dispositivos utun, y el número asignado a su VPN no es estable entre reinicios, reconexiones o la presencia de otro cliente. Una regla que enumera varios números adivinados no es una política; es una instantánea de una tarde.

Ancle la regla a algo que identifique al proveedor previsto: el plan de direcciones que asigna el túnel, el proceso que posee la interfaz o una configuración que mantiene el propio cliente VPN. Luego registre cómo funciona esa identificación, porque quien revise la regla dentro de un año no tendrá su historial de shell.

Haga atribuible la política cargada

Un nombre de ancla organiza reglas; no demuestra que la política efectiva sea la que usted pretendía. La precedencia entre anclas, las reglas que cargó otro software y el estado existente pueden cambiar el resultado. Revise el conjunto efectivo con quienquiera que también posea PF en esa máquina, y documente la propiedad en el mismo lugar que la configuración. Dos propietarios editando anclas distintas con supuestos distintos es la forma habitual en que un bloqueo desarrolla un agujero.

Mantenga el conjunto de reglas en la ruta de configuración compatible del sitio, versiónelo y anote qué versiones de macOS se probaron. Un cambio aplicado a mano y recordado por una sola persona no es infraestructura mantenida, diga lo que diga el encabezado del archivo.

Pruebe las transiciones, no el estado conectado

Una captura de pantalla tomada con el túnel activo no demuestra casi nada. Recorra los estados en su lugar: el arranque antes de cualquier conexión, un túnel que funciona, un túnel que cae sin aviso, una desconexión deliberada y un cambio de Wi-Fi a punto de acceso. Cada estado tiene su propia respuesta, y los interesantes son los fallos, no el camino feliz.

En cada estado, registre qué es accesible de forma intencionada. Compruebe IPv4 e IPv6 por separado, pruebe la resolución de nombres e incluya un flujo que ya estuviera establecido antes de la transición, ya que las conexiones existentes no siempre siguen la nueva política. Un navegador que falla mientras el túnel está caído es un punto de datos, no una prueba de que todas las demás rutas estén bloqueadas.

Por último, mantenga un método de recuperación que no dependa de la ruta de red que está cambiando. Una configuración buena conocida en almacenamiento local y una forma documentada de cargarla convierten un bloqueo en una política; sin ellas, una mala revisión deja al administrador fuera de la máquina que se suponía protegida.