As exclusões de VPN por aplicação quebram quando um serviço partilhado obtém os dados

Exclui uma aplicação da VPN e a transferência de que precisava continua a falhar ou, pior, começa a funcionar e algo não relacionado para. A janela visível não é necessariamente o processo que abre cada ligação: uma aplicação pode entregar o trabalho a um auxiliar, a um serviço de transferência em segundo plano ou a um pacote completamente diferente. Por isso, uma regra por aplicação precisa do modelo de identidade real da plataforma e não de um nome de ficheiro de arranque familiar. As verificações abaixo começam pela observação e voltam a quem fez realmente o pedido.

Nestes pedidos costumam falhar duas coisas ao mesmo tempo: exclui-se o componente errado e a exclusão nunca é estreitada depois.

Encontre o processo, não a janela

Reproduza a operação falhada e identifique o processo ou pacote que detém a ligação enquanto ela decorre. No Windows esta é uma pergunta diferente de qual janela tem o foco, porque uma transferência em segundo plano pode ser intermediada por um serviço que corre com a sua própria identidade. No Linux e no macOS a mesma divisão aparece como processos auxiliares e daemons do sistema.

Anote três detalhes: a identidade do executável ou do pacote, o destino com que contactava e o momento do fluxo de trabalho em que aconteceu. Uma transferência que falha no início é muitas vezes uma obtenção de metadados por um componente diferente de uma transferência que falha a meio. Essa distinção sozinha costuma bastar para escolher a identidade certa antes de tocar na regra. Se a identidade se revelar um serviço e não uma aplicação, esse único facto muda toda a regra, por isso estabeleça-o primeiro.

Se não conseguir observar o processo porque a operação é demasiado breve, repita-a com uma carga maior ou um destino mais lento. O objetivo é uma observação reproduzível, não uma teoria sobre que auxiliar está envolvido.

Trate o DNS como um caminho próprio

A resolução de nomes do sistema pode não seguir de todo a aplicação excluída, e é por isso que um navegador excluído ainda pode falhar num nome de anfitrião privado enquanto o seu tráfego está corretamente fora do túnel. O navegador estava excluído; o resolutor não.

Verifique o que a plataforma faz com o DNS quando se aplica uma regra por aplicação, e verifique-o separadamente do pedido HTTP. Se o resolutor for um serviço partilhado, serve todas as aplicações do dispositivo, pelo que a exclusão que está a considerar tem um público muito mais vasto do que a que testou.

Registe que resolutor respondeu e através de que interface. Essa única observação resolve uma grande parte dos relatos «a aplicação está excluída mas o nome não resolve», por isso guarde-a com o pedido.

Não alargue um auxiliar partilhado

Um serviço partilhado realiza trabalho para várias aplicações, pelo que excluí-lo para reparar um fluxo de trabalho também altera tráfego não relacionado. O Background Intelligent Transfer Service no Windows é um bom exemplo da forma: é infraestrutura que muitas aplicações podem usar, e a sua identidade não é a identidade da aplicação que pediu a transferência.

Verifique o modelo de regras suportado pelo cliente e os requisitos da organização antes de adicionar essa exceção. Pergunte o que mais usa o componente, e se a regra que está prestes a escrever pode ser expressa em relação a destinos em vez de em relação a um processo partilhado.

Se o requisito não puder de todo ser expresso como fronteira de aplicação, uma política baseada em destinos ou outro desenho aprovado podem ser mais compreensíveis e mais seguros do que uma lista crescente de exceções de auxiliares.

Teste todo o fluxo de trabalho, não o passo que falha

Depois de uma alteração suportada, execute a tarefa pretendida com um pedido novo do início ao fim. Depois execute outro fluxo de trabalho que use o componente partilhado, porque é aí que um desvio amplo se anuncia. Uma correção que repara o primeiro e quebra silenciosamente o segundo não é uma correção. Guarde ambos os resultados no pedido e nomeie explicitamente o segundo fluxo de trabalho, para que um revisor o possa repetir.

Mantenha o teste pequeno e repetível: mesmo destino, mesma conta, mesmas condições. Se o segundo fluxo de trabalho não estiver documentado, pergunte ao seu proprietário de que depende antes de decidir que a alteração é segura.

Deixe um motivo, não uma lista de nomes

Documente o componente, o fluxo de trabalho que serve e o motivo por que foi excluído. Uma lista de nomes de auxiliares sem propósito associado torna-se insustentável em dois ciclos de lançamento, e o engenheiro seguinte remove a entrada errada enquanto a limpa.

Uma linha por exceção é suficiente: o que quebra sem ela, quem é dono desse fluxo de trabalho e quando foi verificado pela última vez. Esses três campos transformam uma lista misteriosa numa política que alguém pode defender.