Bloqueig de VPN amb PF al Mac: una política de lloc, no una funció distribuïble

Funciona al teu Mac, així que sembla una cosa que pots donar als usuaris. Aquesta suposició és la primera que cal perdre. El TN3165 d'Apple afirma clarament que Packet Filter no és una API admesa per a productes distribuïts generalment, i presenta l'administració de lloc privilegiada i controlada com el cas raonable. Per tant, un bloqueig de VPN construït sobre PF és una política operativa local amb un propietari, no una funció que puguis lliurar dins d'una aplicació.

PF no és una superfície d'empaquetament

La distinció no és acadèmica. Un producte distribuït que depèn de PF hereta cada canvi que Apple hi fa, cada conflicte amb una altra eina que també escriu regles, i cap compromís de suport que l'arranjament continuï funcionant. Un lloc que administra les seves pròpies màquines té una relació diferent: pot documentar la dependència, provar-la contra cada versió del sistema operatiu i acceptar el manteniment.

Alguns consells d'instal·lació creuen una línia que val la pena anomenar. Sobreescriure tot el conjunt de regles del sistema perquè es carregui una sola àncora, editar la configuració d'inici del sistema d'Apple o desactivar System Integrity Protection no són requisits acceptables per a una recepta reutilitzable. Si una guia publicada necessita qualsevol d'aquestes coses, descriu un laboratori, no una política desplegable.

Escriu la intenció de sortida abans que la sintaxi

Decideix què es permet abans de triar una sola paraula clau. Normalment calen tres camins: el transport propi del client VPN cap al seu servidor, el trànsit de l'aplicació protegida dins del túnel i tot allò que la configuració o els serveis locals requereixen realment com a camí directe.

Dona a cada excepció proposada una destinació, un transport i un propietari. Permetre tots els ports cap a un punt final permet molt més que el transport únic que fa servir el túnel, i l'exposició addicional arriba sense que ningú hagi decidit que hi hagués de ser. Permetre un resolutor públic és la mateixa trampa amb un vestit més amable: crea un camí DNS directe fins i tot quan el túnel està caigut, així que les consultes de noms encara es filtren.

La prova útil per a una excepció és si pots nomenar la persona que la va demanar i la fallada que evita. Si no existeix cap de les dues respostes, la regla és probablement una solució alternativa per a una configuració incorrecta que d'una altra manera romandria invisible.

Els números utun no són una identitat

El MacOS crea interfícies de túnel com a dispositius utun, i el número assignat a la teva VPN no és estable entre reinicis, reconnexions o la presència d'un altre client. Una regla que llista diversos números suposats no és una política; és una instantània d'una tarda.

Ancla la regla a alguna cosa que identifiqui el proveïdor previst: el pla d'adreces que assigna el túnel, el procés que posseeix la interfície o una configuració que manté el mateix client VPN. Després registra com funciona aquesta identificació, perquè la persona que revisi la regla d'aquí a un any no tindrà el teu historial de shell.

Fes que la política carregada sigui atribuïble

Un nom d'àncora organitza regles; no demostra que la política efectiva sigui la que pretenies. La precedència entre àncores, les regles que ha carregat altre programari i l'estat existent poden canviar el resultat. Revisa el conjunt efectiu amb qui més posseeixi PF en aquella màquina, i documenta la propietat al mateix lloc que la configuració. Dos propietaris editant àncores diferents amb suposicions diferents és la manera habitual com un bloqueig desenvolupa un forat.

Mantén el conjunt de regles al camí de configuració suportat del lloc, versiona'l i anota quines versions de macOS s'han provat. Un canvi aplicat a mà i recordat per una sola persona no és infraestructura mantinguda, digui el que digui la capçalera del fitxer.

Prova les transicions, no l'estat connectat

Una captura de pantalla feta amb el túnel actiu no demostra gairebé res. Recorre els estats: l'arrencada abans de qualsevol connexió, un túnel que funciona, un túnel que cau sense avís, una desconnexió deliberada i un canvi de Wi-Fi a punt d'accés. Cada estat té la seva resposta, i els interessants són les fallades, no el camí feliç.

A cada estat, registra què és accessible intencionadament. Comprova IPv4 i IPv6 per separat, prova la resolució de noms i inclou un flux que ja s'hagués establert abans de la transició, ja que les connexions existents no sempre segueixen la nova política. Un navegador que falla mentre el túnel està caigut és un punt de dades, no una prova que tots els altres camins estiguin bloquejats.

Finalment, mantén un mètode de recuperació que no depengui del camí de xarxa que estàs canviant. Una configuració bona coneguda en emmagatzematge local i una manera documentada de carregar-la converteixen un bloqueig en una política; sense elles, una mala revisió deixa l'administrador fora de la màquina que s'havia de protegir.