O túnel dividido para clientes de hotspot não é exclusão por aplicação
Excluir uma aplicação da VPN altera apenas o telefone. O portátil ligado precisa da sua própria regra de encaminhamento, combinada por origem, destino e NAT.
Dois requisitos que soam equivalentes não o são: «exclui esta aplicação da VPN» e «envia este único destino para fora da VPN para o portátil no meu hotspot». O primeiro altera a forma como um socket no telefone escolhe uma rede. O segundo tem de alterar uma decisão de encaminhamento para um pacote que chegou de outro dispositivo depois de o telefone já o ter aceitado. Confundir os dois é o que faz um cliente de hotspot acabar com uma exceção que sempre só se aplicou ao navegador do próprio telefone.
Dois subsistemas são donos das duas perguntas
O Android mantém separadas a rede das aplicações e a partilha de ligação. Os sockets das aplicações são atribuídos a uma rede pela pilha de conectividade, e uma aplicação VPN decide quais dos seus próprios sockets entram no túnel. Os pacotes encaminhados de um cliente ligado são tratados pelo subsistema de partilha, que pede ao netd rotas, regras de política e tradução na interface descendente.
A exclusão por aplicação é avaliada quando uma aplicação abre um socket. Um pacote encaminhado nunca chega a essa verificação, porque não teve origem num socket de aplicação deste dispositivo. É toda a razão pela qual as duas definições não podem substituir-se uma à outra, e não é um defeito em nenhuma delas.
O que a exclusão por aplicação altera realmente
Um construtor de VpnService pode nomear os pacotes que ficam fora do túnel com addDisallowedApplication, ou nomear os únicos pacotes permitidos dentro com addAllowedApplication. Essas aplicações abrem então sockets na rede subjacente enquanto a VPN continua a ser dona da rota predefinida para todo o resto.
O âmbito é preciso: os sockets do próprio pacote, neste dispositivo, enquanto o túnel estiver ativo. Não diz nada sobre tráfego encaminhado, nada sobre um segundo dispositivo e nada sobre pacotes que o sistema envia em nome da partilha.
Também não é um controlo de destino. Excluir um navegador exclui cada endereço que esse navegador alcança, incluindo o que querias manter dentro do túnel. Quando o requisito nomeia um destino em vez de uma aplicação, o seletor de aplicações é a ferramenta errada por construção.
Como um pacote partilhado se apresenta ao telefone
O pacote do cliente chega à interface do hotspot com um endereço de origem privado atribuído pelo telefone, digamos 192.168.43.20, e um destino público. Para o encaminhar, o telefone precisa de uma rota para uma ligação ascendente e de uma regra de tradução para que as respostas encontrem o caminho de volta, porque o endereço privado do cliente não significa nada na rede celular.
O Android exprime isso com regras de política que selecionam uma tabela de encaminhamento, e o netd reconstrói as tabelas e regras relevantes quando as redes e as VPN mudam. Um número de tabela, uma prioridade de regra ou um nome de interface copiados de uma publicação de fórum, ou do mesmo modelo numa versão anterior, não estabelecem uma posse duradoura. Essa reconstrução é também a razão pela qual uma regra escrita à mão pode funcionar durante uma hora e parar após a ligação seguinte.
Que política precisa realmente uma exceção de hotspot
Escreve a decisão como origem, destino e caminho pretendido antes de tocar numa regra. A forma mínima para um destino aprovado é 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 |
Os dois sentidos têm de estar completos. O ramo direto precisa de uma rota utilizável pela ligação ascendente celular que esteja actualmente ativa; o ramo VPN precisa da rota do túnel mais permissão para encaminhar. Qualquer tradução de origem tem de corresponder à saída que escolheste, porque o NAT aplicado numa interface de túnel apresenta o endereço do túnel e não o celular, e então o caminho de volta não concorda com o caminho de ida.
As respostas têm de chegar ao mesmo cliente descendente através de estado seguido ou de uma rota explícita, e um contador de pacotes de saída não prova nada disso. Mantém também o transporte exterior da própria VPN fora do âmbito da exceção, senão os pacotes portadores do túnel herdam uma política escrita para um pedido web de um cliente.
Um endereço capturado não é um destino
Um único endereço IPv4 lido de um navegador é uma fotografia instantânea. Os serviços grandes respondem a partir de anycast ou de um conjunto rotativo de endereços de bordo, muitos são de pilha dupla, e um fluxo de início de sessão pode tocar em anfitriões de autenticação e telemetria que a página nunca mostra. Uma exceção construída em torno do endereço que viste por acaso quebra-se da próxima vez que o serviço reequilibrar.
Usa os endereços documentados pelo proprietário do serviço, ou um intervalo que ele publique, e conta com as duas famílias de endereços. Se o requisito não puder ser expresso como um conjunto estável, é provavelmente uma questão de política para o serviço e não um truque de encaminhamento num telefone.
Verifica a partir do lado descendente
Três verificações, por esta ordem: o serviço escolhido a partir do portátil, um destino comum que tem de ficar dentro da VPN e uma aplicação do telefone que tem de ficar intacta. Depois repete após uma reconexão e após uma mudança de ligação ascendente, porque é então que as tabelas de política são reconstruídas.
Se a implementação de partilha do telefone não conseguir manter esse contrato ao longo de uma reconexão, move a política seletiva para um router descendente suportado em vez de acumular regras root no aparelho. Um router pode exprimir a correspondência de origem e destino com um proprietário estável, e a documentação do módulo de partilha de ligação é a referência correta para o que o telefone faz realmente.