Que ferramenta de macOS pode forzar unha soa app a pasar só pola VPN?
Un límite de só VPN necesita un camiño e un rexeitamento. Compare perfís por app, proxies, filtros e PF, e despois probe a app que lle importa.
Unha liña nun documento de requisitos, «esta app pode usar a VPN e nada máis», pide en voz baixa dous mecanismos que ningún interruptor ofrece. O tráfico necesita un camiño a través do túnel previsto, e o tráfico que sairía directamente debe ser rexeitado. As ferramentas que fan ben unha desas cousas e a outra non fan nada son frecuentes, por iso unha comparación que só pregunta se algo pode bloquear responde con confianza a metade da pregunta. Escriba primeiro o límite e despois escolla os compoñentes que cobren as súas dúas metades.
Dous requisitos agochados nunha soa frase
O encamiñamento é a parte que pon unha conexión no túnel ou no proxy. O rexeitamento é a parte que impide que a mesma conexión saia por calquera outra ruta. Impleméntanos compoñentes distintos, fallan de maneiras distintas, e un produto pode ser excelente nun e non dicir nada do outro:
| 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 a táboa como unha lista de comprobación e non como unha clasificación. Ningunha fila enche as dúas columnas centrais, e as filas que as cobren son dous compoñentes que cooperan: un posúe o camiño e o outro posúe o rexeitamento. A columna de identidade importa por outro motivo, porque unha regra que non pode nomear a app non pode aplicar unha regra sobre esa app. Sexa o que sexa que despregue, ten que responder ás tres, ou o límite do documento de requisitos non é o límite da máquina.
O encamiñamento por si só deixa unha saída
A configuración de proxy de aplicación é o exemplo máis claro de encamiñamento sen rexeitamento. Pode dirixir peticións dunha app que respecta o proxy do sistema e non cobre nada máis: un proceso auxiliar, un actualizador, un servizo en segundo plano ou un protocolo distinto poden viaxar polo seu propio camiño sen ler nunca esa preferencia. Por iso, escoller un extremo SOCKS nun panel non crea unha política de saída directa prohibida para a aplicación. Se o requisito é sobre a app no seu conxunto, pregunte que compoñentes identifica realmente a regra.
Un perfil de VPN por app encamiña mellor ca un proxy, porque a plataforma decide que apps entran no túnel en lugar de que cada app decida por si mesma. Aínda así non rexeita nada: o perfil fornece un camiño, e o tráfico que non encaixa con el toma a ruta ordinaria. Esa fenda é exactamente onde un segundo compoñente gaña o seu lugar, e é a razón de que os produtos que parecen un só interruptor adoiten ser dous.
O rexeitamento por si só rompe a app
A documentación de Apple sobre filtros de contido describe un veredicto de permitir ou bloquear sobre o tráfico mentres pasa pola pila de rede. Ese veredicto non é un túnel nin unha conexión de proxy, porque decide se algo pode continuar e non cara a onde vai. Un filtro por si só aplica o rexeitamento á perfección e deixa a aplicación inservible, con rexistros limpos e sen explicación. O veredicto dun filtro pode deter unha conexión pero nunca fornece o túnel, así que emparellalo co encamiñamento é a decisión de deseño e non un extra opcional.
Un conxunto de regras PF administrado localmente sitúase no outro extremo dese espectro. É unha decisión de soporte lexítima nunha máquina que posúe un administrador, e non é automaticamente a base dun produto distribuíble, porque quen posúe o conxunto de regras tamén posúe as súas interaccións con outros usuarios da devasa, a súa ruta de actualización e a súa recuperación cando unha regra é incorrecta. Engadir PF a un produto non elimina esa cuestión de propiedade; defínea.
O despregamento decide se a regra seguirá existindo mañá
Como se despregue unha Network Extension nas plataformas de Apple depende do tipo de provedor, da empaquetaxe e da versión do sistema operativo que teña diante. Unha extensión de app en macOS execútase nun contexto de usuario e remata cando ese usuario pecha a sesión, mentres que unha extensión de sistema ten un contexto global que non depende da sesión. Se a protección debe sobrevivir a un peche de sesión, esa diferenza é todo o deseño e non unha nota a pé de páxina. Confirme a ruta de despregamento antes de prometer o comportamento, porque o mesmo código aterra de forma distinta segundo que tipo de extensión se entrega.
A dispoñibilidade do código fonte é un asunto á parte da aplicación. Ler un repositorio dille como está implementado algo, non que pode facer o binario instalado nesta máquina. A sinatura, a instalación e a autorización seguen aplicándose, e as instrucións construídas arredor dunha extensión de kernel obsoleta ou dun truco de inxección de biblioteca describen outra plataforma e outra postura de risco, por ben que funcionasen no seu momento.
Un caso de aceptación que nomea a app
Escolla unha soa acción que a aplicación realice pola súa conta, anote o enderezo ao que debería chegar e se ese enderezo é IPv4 ou IPv6, e repita despois a mesma acción no estado aprobado sen túnel. A segunda execución ten que producir o rexeitamento declarado e non un reintento directo silencioso. Esa é a metade que a xente deixa sen especificar, e a única metade que demostra que o rexeitamento existe. Execúteo primeiro co túnel dispoñible, para que unha diferenza entre os dous resultados só poida vir do túnel ausente.
Despois percorra as transicións que o requisito nomea: reiniciar a app, a activación dun proceso auxiliar, a reconexión do túnel, o cambio de redes da máquina e un peche de sesión ou reinicio onde correspondan. Unha páxina de IP pública do navegador non é unha proba dos sockets doutra aplicación, así que non pode substituír esta. Onde ningún despregamento soportado cubra o comportamento real da app, un ambiente illado autorizado cunha pasarela explícita e sen saída alternativa é unha decisión de contención co seu propio custo de xestión, non un substituto dunha caixa de verificación.
Remate escribindo catro entradas: que compoñentes forman a app, quen posúe o encamiñamento, quen posúe o rexeitamento e os estados nos que a regra debe seguir valendo. Un repositorio público pode ser un criterio de selección, pero non é unha das catro, e esas entradas son as que deciden se unha ferramenta dada cumpre o requisito de rede.