Marcaches unha app en OpenVPN? Decide a base da lista
O mesmo paquete marcado significa incluír ou excluír segundo a base da lista. Escolle primeiro só-incluír, reconecta e despois proba todo o fluxo de traballo.
A caixa parece a decisión enteira, e en Android non o é. O mesmo paquete marcado significa «só esta app usa a VPN» cunha base de só-incluír e «esta app salta a VPN» cunha base de excluír os seleccionados. A xente instala un cliente, atopa unha lista chamada Apps permitidas, marca o único paquete que lle importa e marcha cunha política que fai o contrario. Cambiar de cliente raramente axuda; elixir a base antes de tocar a lista si axuda.
A base é a política, non a caixa
Co VpnService de Android, un cliente configura o encamiñamento por app con addAllowedApplication ou addDisallowedApplication. O primeiro limita o túnel aos paquetes listados, o segundo encamiña todo excepto eles. Os clientes envolven ambos nunha interface que pode parecer case idéntica, e algúns nomean a sección pola lista en lugar do modo, así que o título da sección por si só non pode dicirche que base está activa.
Le o control de modo por riba da lista, non o encabezado. No cliente orixinal OpenVPN for Android a lista de apps permitidas ten unha base de só-incluír e outra de excluír os seleccionados, e unha compilación de marca pode formular ambas de forma distinta mantendo os mesmos dous comportamentos. Unha captura doutro cliente, ou dunha versión anterior do mesmo, non é proba do modo no que estás.
| What the client shows | What a checked app gets |
|---|---|
| Allowed apps, include-only baseline | The app uses the tunnel; unchecked apps do not |
| Allowed apps, exclude-selected baseline | The app bypasses the tunnel; everything else uses it |
| No list configured | Client or profile default, commonly all apps |
Esa táboa é todo o mito. Marcar a app é unha afirmación sobre un paquete; a base decide se a afirmación é «inclúeo» ou «exclúeo».
Primeiro o modo, despois o paquete
Traballa nesta orde, porque unha selección feita cunha base pode sobrevivir a un cambio de modo e inverter o seu efecto en silencio:
- Identifica o paquete real e se é a copia do perfil persoal ou do de traballo.
- Abre os axustes de selección de aplicacións para o perfil VPN exacto co que te conectas.
- Establece a base cuxo significado é «só as apps seleccionadas usan a VPN».
- Inclúe o paquete desexado e deixa as apps non relacionadas fóra do conxunto.
- Reconecta para que o cliente reconstruía a interface coa nova lista.
O perfil importa tanto como o paquete. Un cliente pode ter varios perfís, e a selección por app pertence ao que realmente usas para conectarte; editar un perfil que nunca usas non cambia nada. Nun dispositivo xestionado, o perfil de traballo é un usuario á parte coa súa propia copia da app e a súa propia política, así que o feito de que a instancia persoal estea dentro do túnel non di nada sobre a instancia de traballo.
Reconecta antes de xulgar o resultado
VpnService le as listas de aplicacións cando se establece a interface do túnel. Un túnel en funcionamento non recolle necesariamente unha edición da lista, e os clientes difiren en se reconstruen automaticamente ou esperan a que te desconectes e volvas conectar.
Se o cambio parece non facer nada, proba a reconexión antes de dubidar da lista. Despois fai unha petición nova en lugar de recargar unha páxina que xa estaba aberta: unha app que mantén unha conexión establecida é un mal suxeito de proba, e o resultado que ves pode pertencer á interface antiga.
O teu fluxo de traballo pode saír da app
Unha app pode delegar nun navegador para iniciar sesión, nun visor de documentos ou nun destino de compartición. Cunha base de só-incluír, eses axudantes quedan fóra do túnel, así que un fluxo de traballo pode fallar a metade de camiño aínda que a primeira app estivese ben configurada. Inclúe o axudante só se o fluxo de traballo o necesita de verdade, e engádeo a propósito en lugar de descubrilo durante unha demostración.
A selección por app tampouco substitúe a política de rutas propia da conexión. O perfil aínda ten que levar os prefixos de destino e as familias de enderezos que usa a app, e a pasarela aínda ten que permitir o servizo. Unha app listada correctamente cun destino inalcanzable parece o mesmo que unha lista mal configurada.
Proba ambos os dous lados e despois escribe a política
Proba unha petición nova na app incluída e outra nunha app que debería quedar fóra. Compara o enderezo de saída e o acceso a un recurso privado, e repite despois dunha reconexión. Se a túa organización usa a política de Android de bloquear conexións sen VPN, unha app excluída pode quedar bloqueada de todo en lugar de ir directa; iso é a política funcionando, non unha falla que haxa que sortear.
Rexistra o modo, os nomes dos paquetes co seu perfil, que apps deben omitir, que familias de enderezos leva o túnel e que debería pasar cando o túnel está caído. Se o cliente non pode expresar o fluxo de traballo con claridade, escolle un conxunto de apps aprobado máis amplo ou unha política de perfil xestionado en lugar de editar regras de devasas a nivel de raíz, o que non forma parte do mecanismo por app compatible con Android.