As exclusións de VPN por aplicación rompen cando un servizo compartido descarga datos

Exclúe unha aplicación da VPN e a descarga que necesitaba segue fallando ou, peor aínda, comeza a funcionar e algo non relacionado detense. A ventá visible non é necesariamente o proceso que abre cada conexión: unha aplicación pode entregar o traballo a un axudante, a un servizo de transferencia en segundo plano ou a un paquete completamente distinto. Por iso, unha regra por aplicación necesita o modelo de identidade real da plataforma e non un nome de ficheiro de inicio coñecido. As comprobacións seguintes parten da observación e volven a quen fixo a solicitude de verdade.

Nestes tickets adoitan fallar dúas cousas á vez: exclúese o compoñente equivocado e a exclusión nunca se restrinxe despois.

Atope o proceso, non a ventá

Reproduza a operación fallida e identifique o proceso ou paquete que posúe a conexión mentres ocorre. En Windows esta é unha pregunta distinta de cal ventá ten o foco, porque unha transferencia en segundo plano pode ser intermediada por un servizo que se executa coa súa propia identidade. En Linux e macOS a mesma división aparece como procesos auxiliares e daemons do sistema.

Anote tres detalles: a identidade do executábel ou do paquete, o destino co que contactaba e o momento do fluxo de traballo en que ocorreu. Unha descarga que falla ao principio adoita ser unha obtención de metadatos dun compoñente distinto da descarga que falla a metade. Esa distinción por si soa adoita abondar para escoller a identidade correcta antes de tocar a regra. Se a identidade resulta ser un servizo e non unha aplicación, ese único feito cambia toda a regra, así que establézao primeiro.

Se non pode observar o proceso porque a operación é demasiado breve, repítaa cunha carga maior ou un destino máis lento. O obxectivo é unha observación reproducible, non unha teoría sobre que axudante intervén.

Trate o DNS como un camiño propio

A resolución de nomes do sistema pode non seguir en absoluto a aplicación excluída, por iso un navegador excluído aínda pode fallar nun nome de host privado mentres o seu tráfico está correctamente fóra do túnel. O navegador estaba excluído; o resolutor non.

Comprobe que fai a plataforma co DNS cando se aplica unha regra por aplicación, e compróbeo por separado da solicitude HTTP. Se o resolutor é un servizo compartido, atende todas as aplicacións do dispositivo, así que a exclusión que está a considerar ten un público moito máis amplo ca a que probou.

Rexistre que resolutor respondeu e a través de que interface. Esa única observación resolve unha boa parte dos informes «a aplicación está excluída pero o nome non se resolve», así que gárdea co ticket.

Non amplíe un axudante compartido

Un servizo compartido realiza traballo para varias aplicacións, así que excluílo para reparar un fluxo de traballo tamén cambia tráfico non relacionado. O Background Intelligent Transfer Service de Windows é un bo exemplo da forma: é infraestrutura que moitas aplicacións poden usar, e a súa identidade non é a identidade da aplicación que solicitou a transferencia.

Comprobe o modelo de regras que admite o cliente e os requisitos da organización antes de engadir esa excepción. Pregunte que máis usa o compoñente e se a regra que está a piques de escribir pode expresarse respecto a destinos en lugar de respecto a un proceso compartido.

Se o requisito non se pode expresar de ningún xeito como límite de aplicación, unha política baseada en destinos ou outro deseño aprobado poden ser máis comprensíbeis e máis seguros ca unha lista crecente de excepcións de axudantes.

Probe todo o fluxo de traballo, non o paso que falla

Despois dun cambio admitido, execute a tarefa prevista cunha solicitude nova de principio a fin. Logo execute outro fluxo de traballo que use o compoñente compartido, porque é aí onde unha evasión ampla se anuncia. Unha corrección que arranxa a primeira e rompe en silencio a segunda non é unha corrección. Garde ambos os resultados no ticket e nomee explicitamente o segundo fluxo de traballo, para que un revisor poida repetilo.

Manteña a proba pequena e repetible: mesmo destino, mesma conta, mesmas condicións. Se o segundo fluxo de traballo non está documentado, pregunte ao seu propietario de que depende antes de decidir que o cambio é seguro.

Deixe un motivo, non unha lista de nomes

Documente o compoñente, o fluxo de traballo ao que serve e o motivo polo que se excluíu. Unha lista de nomes de axudantes sen propósito asociado vólvese insostible en dous ciclos de publicación, e o seguinte enxeñeiro elimina a entrada equivocada mentres a limpa.

Unha liña por excepción é suficiente: que se rompe sen ela, quen posúe ese fluxo de traballo e cando se verificou por última vez. Eses tres campos converten unha lista misteriosa nunha política que alguén pode defender.