Les exclusions de VPN per aplicació es trenquen quan un servei compartit fa la petició

Excloeu una aplicació de la VPN i la baixada que necessitava continua fallant o, pitjor encara, comença a funcionar i una cosa no relacionada s’atura. La finestra visible no és necessàriament el procés que obre cada connexió: una aplicació pot lliurar la feina a un auxiliar, a un servei de transferència en segon pla o a un paquet completament diferent. Per tant, una regla per aplicació necessita el model d’identitat real de la plataforma i no un nom de fitxer d’inici conegut. Les comprovacions següents comencen per l’observació i tornen a qui va fer la petició de debò.

En aquests tiquets solen fallar dues coses alhora: s’exclou el component equivocat i l’exclusió no s’estreny mai després.

Trobeu el procés, no la finestra

Reproduïu l’operació fallida i identifiqueu el procés o paquet que posseeix la connexió mentre passa. A Windows aquesta és una pregunta diferent de quina finestra té el focus, perquè una transferència en segon pla pot ser intermediada per un servei que s’executa amb la seva pròpia identitat. A Linux i macOS la mateixa divisió apareix com a processos auxiliars i dimonis del sistema.

Anoteu tres detalls: la identitat de l’executable o del paquet, la destinació amb què contactava i el moment del flux de treball en què va passar. Una baixada que falla al començament sovint és una obtenció de metadades d’un component diferent de la baixada que falla a mitges. Aquesta distinció sola sol ser suficient per triar la identitat correcta abans de tocar la regla. Si la identitat resulta ser un servei i no una aplicació, aquest únic fet canvia tota la regla, així que establiu-lo primer.

Si no podeu observar el procés perquè l’operació és massa breu, repetiu-la amb una càrrega més gran o una destinació més lenta. L’objectiu és una observació reproduïble, no una teoria sobre quin auxiliar hi intervé.

Tracteu el DNS com un camí propi

La resolució de noms del sistema pot no seguir gens l’aplicació exclosa, i per això un navegador exclòs encara pot fallar en un nom d’amfitrió privat mentre el seu trànsit és correctament fora del túnel. El navegador estava exclòs; el resolutor no.

Comproveu què fa la plataforma amb el DNS quan s’aplica una regla per aplicació, i comproveu-ho per separat de la petició HTTP. Si el resolutor és un servei compartit, serveix totes les aplicacions del dispositiu, així que l’exclusió que esteu considerant té un públic molt més ampli que la que heu provat.

Registreu quin resolutor va respondre i per quina interfície. Aquesta única observació resol una bona part dels informes «l’aplicació està exclosa però el nom no es resol», així que conserveu-la amb el tiquet.

No amplieu un auxiliar compartit

Un servei compartit fa feina per a diverses aplicacions, així que excloure’l per reparar un flux de treball també canvia trànsit no relacionat. El Background Intelligent Transfer Service de Windows n’és un bon exemple de la forma: és infraestructura que moltes aplicacions poden usar, i la seva identitat no és la identitat de l’aplicació que va demanar la transferència.

Comproveu el model de regles que admet el client i els requisits de l’organització abans d’afegir aquesta excepció. Pregunteu què més usa el component i si la regla que esteu a punt d’escriure es pot expressar respecte a destinacions en lloc de respecte a un procés compartit.

Si el requisit no es pot expressar de cap manera com a frontera d’aplicació, una política basada en destinacions o un altre disseny aprovat poden ser més comprensibles i més segurs que una llista creixent d’excepcions d’auxiliars.

Proveu tot el flux de treball, no el pas que falla

Després d’un canvi admès, executeu la tasca prevista amb una petició nova de principi a fi. Després executeu un altre flux de treball que usi el component compartit, perquè és allà on un bypass ampli s’anuncia. Una correcció que arregla la primera i trenca en silenci la segona no és una correcció. Guardeu tots dos resultats al tiquet i anomeneu explícitament el segon flux de treball, perquè un revisor el pugui repetir.

Mantingueu la prova petita i repetible: mateixa destinació, mateix compte, mateixes condicions. Si el segon flux de treball no està documentat, pregunteu al seu propietari de què depèn abans de decidir que el canvi és segur.

Deixeu un motiu, no una llista de noms

Documenteu el component, el flux de treball a què serveix i el motiu pel qual es va excloure. Una llista de noms d’auxiliars sense cap propòsit associat es torna impossible de mantenir a dos cicles de publicació, i el següent enginyer elimina l’entrada equivocada mentre la neteja.

Una línia per excepció és suficient: què es trenca sense ella, qui posseeix aquell flux de treball i quan es va verificar per última vegada. Aquests tres camps converteixen una llista misteriosa en una política que algú pot defensar.