O túnel dividido para clientes de punto de acceso non é unha exclusión por aplicación
Excluír unha aplicación da VPN só cambia o teléfono. O portátil conectado necesita a súa propia regra de reenvío, axustada por orixe, destino e NAT.
Dous requisitos que soan equivalentes non o son: «exclúe esta aplicación da VPN» e «envía este único destino fóra da VPN para o portátil do meu punto de acceso». O primeiro cambia como un socket do teléfono escolle unha rede. O segundo ten que cambiar unha decisión de reenvío para un paquete que chegou doutro dispositivo despois de que o teléfono xa o aceptase. Confundir os dous é o que fai que un cliente de punto de acceso acabe cunha excepción que só se aplicaba ao navegador do propio teléfono.
Dous subsistemas son donos das dúas preguntas
Android mantén separadas a rede das aplicacións e o tethering. A pila de conectividade asigna os sockets das aplicacións a unha rede, e unha aplicación VPN decide cales dos seus propios sockets entran no túnel. Os paquetes reenviados dun cliente conectado xestiónaos o subsistema de tethering, que lle pide a netd rutas, regras de política e tradución na interface descendente.
A exclusión por aplicación avalíase cando unha aplicación abre un socket. Un paquete reenviado nunca chega a esa comprobación, porque non se orixinou nun socket de aplicación deste dispositivo. Esa é toda a razón pola que os dous axustes non poden substituírse entre si, e non é un fallo en ningún dos dous.
Que cambia realmente a exclusión por aplicación
Un construtor de VpnService pode nomear os paquetes que quedan fóra do túnel con addDisallowedApplication, ou nomear os únicos paquetes permitidos dentro con addAllowedApplication. Esas aplicacións abren entón sockets na rede subxacente mentres a VPN segue sendo dona da ruta predeterminada para todo o demais.
O alcance é preciso: os sockets propios do paquete, neste dispositivo, mentres o túnel estea activo. Non di nada sobre o tráfico reenviado, nada sobre un segundo dispositivo e nada sobre os paquetes que o sistema envía en nome do tethering.
Tampouco é un control de destino. Excluír un navegador exclúe cada enderezo que ese navegador acada, incluído o que querías manter dentro do túnel. Cando o requisito nomea un destino en lugar dunha aplicación, o selector de aplicacións é a ferramenta equivocada por construción.
Como ve o teléfono un paquete conectado
O paquete do cliente chega á interface do punto de acceso cun enderezo de orixe privado asignado polo teléfono, digamos 192.168.43.20, e un destino público. Para reenvialo, o teléfono necesita unha ruta cara a unha ligazón ascendente e unha regra de tradución para que as respostas atopen o camiño de volta, porque o enderezo privado do cliente non significa nada na rede celular.
Android exprésao con regras de política que seleccionan unha táboa de encamiñamento, e netd reconstrúe as táboas e regras correspondentes cando cambian as redes e as VPN. Un número de táboa, unha prioridade de regra ou un nome de interface copiados dunha publicación de foro, ou do mesmo modelo nunha versión anterior, non establecen unha propiedade duradeira. Esa reconstrución é tamén a razón pola que unha regra escrita a man pode funcionar unha hora e deterse tras a seguinte reconexión.
A política que unha excepción de punto de acceso necesita de verdade
Escriba a decisión como orixe, destino e ruta prevista antes de tocar ningunha regra. A forma mínima para un destino aprobado é esta:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Ambos os sentidos teñen que estar completos. A rama directa necesita unha ruta utilizábel pola ligazón ascendente celular que resulte ser a actual; a rama VPN necesita a ruta do túnel máis permiso para reenviar. Calquera tradución de orixe debe coincidir coa saída que escolleu, porque o NAT aplicado nunha interface de túnel presenta o enderezo do túnel e non o celular, e entón o camiño de volta non concorda co camiño de ida.
As respostas deben chegar ao mesmo cliente descendente mediante estado seguido ou unha ruta explícita, e un contador de paquetes saíntes non demostra nada diso. Manteña tamén o transporte exterior propio da VPN fóra do alcance da excepción, ou os paquetes portadores do túnel herdan unha política escrita para unha solicitude web dun cliente.
Un enderezo capturado non é un destino
Un só enderezo IPv4 lido dun navegador é unha instantánea. Os servizos grandes responden desde anycast ou desde un conxunto rotatorio de enderezos de borde, moitos son de dobre pila, e un fluxo de inicio de sesión pode tocar hosts de autenticación e telemetría que a páxina nunca mostra. Unha excepción construída arredor do enderezo que viu por casualidade rompe a próxima vez que o servizo reequilibre.
Use os enderezos documentados polo propietario do servizo, ou un rango que publique, e conte coas dúas familias de enderezos. Se o requisito non se pode expresar como un conxunto estable, probablemente sexa unha cuestión de política para o servizo e non un truco de encamiñamento nun teléfono.
Verifique desde o lado descendente
Tres comprobacións, nesta orde: o servizo seleccionado desde o portátil, un destino corrente que debe quedar dentro da VPN e unha aplicación do teléfono que debe quedar sen afectación. Despois repita tras unha reconexión e tras un cambio de ligazón ascendente, porque é entón cando se reconstrúen as táboas de política.
Se a implementación de compartición do teléfono non pode manter ese contrato durante unha reconexión, mova a política selectiva a un encamiñador descendente compatible en lugar de acumular regras root no terminal. Un encamiñador pode expresar a coincidencia de orixe e destino cun propietario estable, e a documentación do módulo de tethering é a referencia correcta para o que o teléfono fai en realidade.