Исклучоците на VPN по апликација се кршат кога заедничка служба ги зема податоците

Исклучувате една апликација од VPN, а преземањето што ѝ требаше и понатаму не успева, или полошо, почнува да работи и нешто неповрзано запира. Видливиот прозорец не е нужно процесот што ја отвора секоја врска: апликацијата може да ја предаде работата на помошник, на служба за пренос во позадина или на сосема друг пакет. Затоа правилото по апликација бара вистинскиот модел на идентитет на платформата, а не познато име на стартна датотека. Проверките подолу започнуваат од набљудувањето и се враќаат кај тој што навистина го испратил барањето.

Во овие тикети обично две работи се расипуваат заедно: се исклучува погрешната компонента, а исклучокот потоа никогаш не се стеснува.

Најдете го процесот, не прозорецот

Репродуцирајте ја неуспешната операција и идентификувајте го процесот или пакетот што ја поседува врската додека таа се случува. На Windows ова е различно прашање од тоа кој прозорец има фокус, бидејќи преносот во позадина може да го посредува служба што работи под сопствен идентитет. На Linux и macOS истата поделба се појавува како помошни процеси и системски демони.

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

Ако не можете да го набљудувате процесот затоа што операцијата е премногу кратка, повторете ја со поголем товар или со побавна дестинација. Целта е едно повторливо набљудување, а не теорија за тоа кој помошник е вклучен.

Третирајте го DNS како своја патека

Системското разрешување на имиња може воопшто да не ја следи исклучената апликација, поради што исклучен прелистувач и понатаму може да не успее на приватно име на домаќин, додека неговиот сообраќај правилно е надвор од тунелот. Прелистувачот беше исклучен; разрешувачот не.

Проверете што прави платформата со DNS кога се применува правило по апликација и проверете го тоа одделно од HTTP барањето. Ако разрешувачот е заедничка служба, таа служи на секоја апликација на уредот, па исклучокот што го разгледувате има многу поширока публика од тој што сте го тестирале.

Забележете кој разрешувач одговори и преку кој интерфејс. Тоа единствено набљудување решава голем дел од извештаите „апликацијата е исклучена, но името не се разрешува“, затоа чувајте го со тикетот.

Не го проширувајте заедничкиот помошник

Заедничката служба врши работа за неколку апликации, па нејзиното исклучување за да се поправи еден работен тек менува и неповрзан сообраќај. Background Intelligent Transfer Service на Windows е добар пример за формата: тоа е инфраструктура што многу апликации можат да ја користат, а нејзиниот идентитет не е идентитетот на апликацијата што го побарала преносот.

Проверете го моделот на правила што клиентот го поддржува и барањата на организацијата пред да го додадете тој исклучок. Прашајте што друго ја користи компонентата и дали правилото што ќе го напишете може да се изрази во однос на дестинации, а не во однос на заеднички процес.

Ако барањето воопшто не може да се изрази како граница на апликација, политика заснована на дестинации или друг одобрен дизајн може да биде поразбирлив и побезбеден од растечка листа на исклучоци за помошници.

Тестирајте го целиот работен тек, а не чекорот што не успева

По поддржана промена, извршете ја предвидената задача со свежо барање од почеток до крај. Потоа извршете уште еден работен тек што ја користи заедничката компонента, зашто токму таму широкото заобиколување се објавува. Поправка што го поправа првото и тивко го крши второто не е поправка. Чувајте ги двата резултата во тикетот и изречно наведете го вториот работен тек, за да може рецензентот да го повтори.

Чувајте го тестот мал и повторлив: иста дестинација, иста сметка, исти услови. Ако вториот работен тек не е документиран, прашајте го неговиот сопственик од што зависи пред да одлучите дека промената е безбедна.

Оставете причина, а не листа на имиња

Документирајте ја компонентата, работниот тек што го служи и причината за нејзиното исклучување. Листата со имиња на помошници без поврзана цел станува неодржлива во два циклуси на издавање, а следниот инженер го отстранува погрешниот запис додека ја чисти.

Еден ред по исклучок е доволен: што се крши без него, кој го поседува тој работен тек и кога последен пат бил проверен. Тие три полиња претвораат мистериозна листа во политика што некој може да ја одбрани.