Изключенията на VPN за отделни приложения се чупят, когато споделена услуга извлича данни

Изключвате едно приложение от VPN и изтеглянето, което му е нужно, все още се проваля, или по-лошо, започва да работи, а нещо несвързано спира. Видимият прозорец не е непременно процесът, който отваря всяка връзка: приложението може да предаде работа на помощник, на фонова услуга за трансфер или на напълно друг пакет. Затова правилото за отделно приложение се нуждае от истинския модел на идентичност на платформата, а не от познато име на стартов файл. Проверките по-долу започват от наблюдението и се връщат към този, който действително е направил заявката.

В тези заявки обикновено се объркват две неща наведнъж: изключва се грешният компонент и изключението след това никога не се стеснява.

Намерете процеса, а не прозореца

Възпроизведете неуспешната операция и идентифицирайте процеса или пакета, който притежава връзката, докато тя се случва. В Windows това е различен въпрос от това кой прозорец е на фокус, защото фоновият трансфер може да бъде посредничен от услуга, която работи под собствена идентичност. В Linux и macOS същото разделение се появява като помощни процеси и системни демони.

Запишете три подробности: идентичността на изпълнимия файл или пакета, дестинацията, с която е контактувал, и момента в работния процес, когато се е случило. Изтегляне, което се проваля в началото, често е извличане на метаданни от различен компонент, отколкото изтегляне, което се проваля по средата. Само това разграничение обикновено е достатъчно, за да изберете правилната идентичност, преди да пипате правилото. Ако идентичността се окаже услуга, а не приложение, този единствен факт променя цялото правило, затова го установете първо.

Ако не можете да наблюдавате процеса, защото операцията е твърде кратка, повторете я с по-голям обем данни или по-бавна дестинация. Целта е едно възпроизводимо наблюдение, а не теория за това кой помощник участва.

Третирайте DNS като отделен път

Системното разрешаване на имена може изобщо да не следва изключеното приложение, поради което изключен браузър все още може да се проваля на частно име на хост, докато трафикът му правилно е извън тунела. Браузърът беше изключен; резолверът — не.

Проверете какво прави платформата с DNS, когато се прилага правило за отделно приложение, и го проверете отделно от HTTP заявката. Ако резолверът е споделена услуга, той обслужва всяко приложение на устройството, така че изключението, което обмисляте, има много по-широка публика от това, което сте тествали.

Запишете кой резолвер е отговорил и през кой интерфейс. Това единствено наблюдение решава голям дял от докладите „приложението е изключено, но името не се разрешава“, затова го пазете със заявката.

Не разширявайте споделен помощник

Споделената услуга извършва работа за няколко приложения, така че изключването ѝ, за да поправите един работен процес, променя и несвързан трафик. Background Intelligent Transfer Service в Windows е добър пример за формата: това е инфраструктура, която много приложения могат да използват, и нейната идентичност не е идентичността на приложението, поискало трансфера.

Проверете поддържания от клиента модел на правила и изискванията на организацията, преди да добавите това изключение. Попитайте какво друго използва компонента и дали правилото, което ще напишете, може да бъде изразено спрямо дестинации, а не спрямо споделен процес.

Ако изискването изобщо не може да се изрази като граница на приложение, политика, основана на дестинации или друг одобрен дизайн може да е по-разбираем и по-безопасен от растящ списък с изключения за помощници.

Тествайте целия работен процес, не само неуспешната стъпка

След поддържана промяна изпълнете предвидената задача с нова заявка от начало до край. След това изпълнете друг работен процес, който използва споделения компонент, защото именно там широкото заобикаляне се проявява. Поправка, която оправя първото и тихо чупи второто, не е поправка. Пазете двата резултата в заявката и назовете втория работен процес изрично, за да може рецензентът да го повтори.

Пазете теста малък и повтаряем: същата дестинация, същият акаунт, същите условия. Ако вторият работен процес не е документиран, попитайте собственика му от какво зависи, преди да решите, че промяната е безопасна.

Оставете причина, а не списък с имена

Документирайте компонента, работния процес, на който служи, и причината да бъде изключен. Списък с имена на помощници без прикачена цел става неподдържаем в рамките на два цикъла на издаване и следващият инженер премахва грешния запис, докато го разчиства.

Един ред на изключение е достатъчен: какво се чупи без него, кой притежава този работен процес и кога е проверяван за последно. Тези три полета превръщат загадъчен списък в политика, която някой може да защити.