Bloqueo de VPN con PF no Mac: unha política de sitio, non unha función distribuíble

Funciona no teu Mac, así que parece algo que podes entregar aos usuarios. Esa suposición é o primeiro que hai que perder. O TN3165 de Apple afirma claramente que Packet Filter non é unha API compatible para produtos distribuídos de forma xeral, e presenta a administración de sitio privilexiada e controlada como o caso razoable. Polo tanto, un bloqueo de VPN construído sobre PF é unha política operativa local cun propietario, non unha función que poidas distribuír dentro dunha aplicación.

PF non é unha superficie de empaquetado

A distinción non é académica. Un produto distribuído que depende de PF herda cada cambio que Apple lle fai, cada conflito con outra ferramenta que tamén escribe regras, e ningún compromiso de soporte de que o arranxo siga funcionando. Un sitio que administra as súas propias máquinas ten unha relación distinta: pode documentar a dependencia, probala con cada versión do sistema operativo e aceptar o mantemento.

Algúns consellos de instalación cruzan unha liña que paga a pena nomear. Sobrescribir todo o conxunto de regras do sistema para que se cargue unha soa áncora, editar a configuración de arranque do sistema de Apple ou desactivar System Integrity Protection non son requisitos aceptables para unha receita reutilizable. Se unha guía publicada necesita calquera desas cousas, describe un laboratorio, non unha política despregable.

Escribe a intención de saída antes da sintaxe

Decide que está permitido antes de escoller unha soa palabra clave. Normalmente deben existir tres rutas: o transporte propio do cliente VPN cara ao seu servidor, o tráfico da aplicación protexida dentro do túnel e todo o que a configuración ou os servizos locais realmente requiren como ruta directa.

Dalle a cada excepción proposta un destino, un transporte e un propietario. Permitir todos os portos cara a un extremo permite moito máis que o único transporte que usa o túnel, e a exposición adicional chega sen que ninguén decidise que debería existir. Permitir un resolutor público é a mesma trampa cun disfrace máis amable: crea unha ruta DNS directa mesmo mentres o túnel está caído, así que as consultas de nomes seguen filtrándose.

A proba útil para unha excepción é se podes nomear a persoa que a pediu e o fallo que evita. Se non existe ningunha das dúas respostas, a regra é probablemente unha volta para unha configuración incorrecta que doutro xeito permanecería invisible.

Os números utun non son unha identidade

MacOS crea interfaces de túnel como dispositivos utun, e o número asignado á túa VPN non é estable entre reinicios, reconexións ou a presenza doutro cliente. Unha regra que enumera varios números adiviñados non é unha política; é unha instantánea dunha tarde.

Ancla a regra a algo que identifique o provedor previsto: o plan de enderezos que asigna o túnel, o proceso que posúe a interface ou unha configuración que mantén o propio cliente VPN. Despois rexistra como funciona esa identificación, porque quen revise a regra dentro dun ano non terá o teu historial de shell.

Fai atribuíble a política cargada

Un nome de áncora organiza regras; non demostra que a política efectiva sexa a que pretendías. A precedencia entre áncoras, as regras que cargou outro software e o estado existente poden cambiar o resultado. Revisa o conxunto efectivo con quen queira que tamén posúa PF nesa máquina, e documenta a propiedade no mesmo lugar que a configuración. Dous propietarios editando áncoras distintas con suposicións distintas é a forma habitual en que un bloqueo desenvolve un burato.

Mantén o conxunto de regras na ruta de configuración compatible do sitio, versiónao e anota que versións de macOS se probaron. Un cambio aplicado a man e recordado por unha soa persoa non é infraestrutura mantida, diga o que diga a cabeceira do ficheiro.

Proba as transicións, non o estado conectado

Unha captura de pantalla tomada co túnel activo non demostra case nada. Percorre os estados no seu lugar: o arranque antes de calquera conexión, un túnel que funciona, un túnel que cae sen aviso, unha desconexión deliberada e un cambio de Wi-Fi a punto de acceso. Cada estado ten a súa propia resposta, e os interesantes son os fallos, non o camiño feliz.

En cada estado, rexistra que é accesible de forma intencionada. Comproba IPv4 e IPv6 por separado, proba a resolución de nomes e inclúe un fluxo que xa estivese establecido antes da transición, xa que as conexións existentes non sempre seguen a nova política. Un navegador que falla mentres o túnel está caído é un punto de datos, non unha proba de que todas as demais rutas estean bloqueadas.

Por último, mantén un método de recuperación que non dependa da ruta de rede que estás cambiando. Unha configuración boa coñecida en almacenamento local e unha forma documentada de cargala converten un bloqueo nunha política; sen elas, unha mala revisión deixa o administrador fóra da máquina que se supuña protexida.