Tətbiq üzrə VPN istisnaları ortaq xidmət məlumat götürəndə pozulur

Bir tətbiqi VPN-dən istisna edirsiniz və ona lazım olan yükləmə yenə də uğursuz olur, ya da daha pisi, işləməyə başlayır və əlaqəsiz bir şey dayanır. Görünən pəncərə hər bağlantını açan proses deyil: tətbiq işi köməkçiyə, fon ötürmə xidmətinə və ya tamamilə başqa paketə verə bilər. Buna görə tətbiq üzrə qayda tanış başlatma faylı adına deyil, platformanın əsl kimlik modelinə ehtiyac duyur. Aşağıdakı yoxlamalar müşahidədən başlayır və sorğunu həqiqətən kimin etdiyinə qayıdır.

Bu biletlərdə adətən iki şey birlikdə səhv gedir: yanlış komponent istisna edilir və istisna sonradan heç vaxt daraldılmır.

Pəncərəni deyil, prosesi tapın

Uğursuz əməliyyatı təkrarlayın və bağlantıya sahib olan prosesi və ya paketi baş verərkən müəyyən edin. Windows-da bu, hansı pəncərənin fokusda olmasından fərqli bir sualdır, çünki fon ötürməsinə öz kimliyi ilə işləyən xidmət vasitəçilik edə bilər. Linux və macOS-da eyni bölünmə köməkçi proseslər və sistem demonları kimi görünür.

Üç detal yazın: icra olunan faylın və ya paketin kimliyi, əlaqə saxladığı təyinat və iş axınında bunun baş verdiyi an. Başlanğıcda uğursuz olan yükləmə çox vaxt yarıda uğursuz olan yükləmədən fərqli komponentin metadata götürməsidir. Yalnız bu fərq adətən qaydaya toxunmazdan əvvəl düzgün kimliyi seçmək üçün kifayətdir. Əgər kimlik tətbiq deyil, xidmət olarsa, bu tək fakt bütün qaydanı dəyişir, ona görə əvvəlcə onu müəyyənləşdirin.

Əməliyyat çox qısa olduğu üçün prosesi müşahidə edə bilmirsinizsə, onu daha böyük yüklə və ya daha yavaş təyinatla təkrarlayın. Məqsəd hansı köməkçinin iştirak etdiyinə dair nəzəriyyə deyil, bir təkrarlana bilən müşahidədir.

DNS-i ayrı yol kimi qəbul edin

Sistem adı həlli istisna edilmiş tətbiqə heç izləməyə bilər, buna görə istisna edilmiş brauzer şəxsi host adında yenə də uğursuz ola bilər, halbuki onun trafiki tunnelin xaricində düzgündür. Brauzer istisna edildi; həlledici yox.

Tətbiq üzrə qayda tətbiq olunanda platformanın DNS ilə nə etdiyini yoxlayın və bunu HTTP sorğusundan ayrı yoxlayın. Əgər həlledici ortaq xidmətdirsə, cihazdakı hər tətbiqə xidmət edir, buna görə nəzərdən keçirdiyiniz istisnanın auditoriyası sınaqdan keçirdiyinizdən qat-qat genişdir.

Hansı həlledicinin cavab verdiyini və hansı interfeysdən keçdiyini qeyd edin. Bu tək müşahidə «tətbiq istisna edilib, amma ad həll olunmur» hesabatlarının böyük hissəsini həll edir, ona görə onu biletlə birlikdə saxlayın.

Ortaq köməkçini genişləndirməyin

Ortaq xidmət bir neçə tətbiq üçün iş görür, buna görə bir iş axınını təmir etmək üçün onu istisna etmək əlaqəsiz trafiki də dəyişir. Windows-dakı Background Intelligent Transfer Service bu formanın yaxşı nümunəsidir: o, bir çox tətbiqin istifadə edə biləcəyi infrastrukturdur və kimliyi ötürməni tələb edən tətbiqin kimliyi deyil.

Bu istisnanı əlavə etməzdən əvvəl müştərinin dəstəklənən qayda modelini və təşkilatın tələblərini yoxlayın. Komponentdən başqa nəyin istifadə etdiyini və yazmaq üzrə olduğunuz qaydanın ortaq prosesə deyil, təyinatla ifadə oluna biləcəyini soruşun.

Tələb ümumiyyətlə tətbiq sərhədi kimi ifadə oluna bilmirsə, təyinat əsaslı siyasət və ya başqa təsdiqlənmiş dizayn böyüyən köməkçi istisnaları siyahısından daha başa düşülən və daha təhlükəsiz ola bilər.

Bütün iş axınını sınayın, uğursuz addımı deyil

Dəstəklənən dəyişiklikdən sonra nəzərdə tutulan tapşırığı yeni sorğu ilə əvvəldən axıra qədər işlədin. Sonra ortaq komponentdən istifadə edən başqa bir iş axını işlədin, çünki geniş yan keçid özünü orada bəyan edir. Birincini təmir edib ikincini səssizcə pozan düzəliş düzəliş deyil. Hər iki nəticəni biletdə saxlayın və ikinci iş axınını açıq şəkildə adlandırın ki, rəyçi onu təkrarlaya bilsin.

Testi kiçik və təkrarlana bilən saxlayın: eyni təyinat, eyni hesab, eyni şərtlər. İkinci iş axını sənədləşdirilməyibsə, dəyişikliyin təhlükəsiz olduğuna qərar verməzdən əvvəl sahibindən nədən asılı olduğunu soruşun.

Ad siyahısı deyil, səbəb qoyun

Komponenti, xidmət etdiyi iş axınını və istisna edilmə səbəbini sənədləşdirin. Məqsəd bağlanmayan köməkçi adları siyahısı iki buraxılış dövrü ərzində idarəolunmaz olur və növbəti mühəndis onu təmizləyərkən yanlış qeydi silir.

Hər istisna üçün bir sətir kifayətdir: onsuz nə pozulur, o iş axınına kim sahibdir və ən son nə vaxt yoxlanılıb. Bu üç sahə sirli siyahını kiminsə müdafiə edə biləcəyi siyasətə çevirir.