Izjeme VPN za posamezne aplikacije se zlomijo, ko skupna storitev pridobi podatke
Okno, ki ste ga izključili, ni vedno proces, ki odpre povezavo. Poiščite pravega prosilca, preden v pravilo VPN za posamezno aplikacijo dodate pomočnika.
Izključite eno aplikacijo iz VPN in prenos, ki ga je potrebovala, še vedno ne uspe ali, še huje, začne delovati in nekaj nepovezanega se ustavi. Vidno okno ni nujno proces, ki odpre vsako povezavo: aplikacija lahko delo preda pomočniku, storitvi za prenos v ozadju ali povsem drugemu paketu. Zato pravilo za posamezno aplikacijo potrebuje resnični model identitete platforme, ne znanega imena zagonske datoteke. Spodnje kontrole se začnejo pri opazovanju in se vrnejo k tistemu, ki je zahtevo dejansko poslal.
V teh zahtevkih se običajno pokvarita dve stvari hkrati: izključena je napačna komponenta in izjema se pozneje nikoli ne zoži.
Poiščite proces, ne okna
Ponovite neuspelo operacijo in ugotovite, kateri proces ali paket ima povezavo, medtem ko poteka. V Windowsu je to drugo vprašanje od tega, katero okno ima fokus, ker lahko prenos v ozadju posreduje storitev, ki teče pod lastno identiteto. V Linuxu in macOS se ista delitev pokaže kot pomožni procesi in sistemski demoni.
Zapišite tri podrobnosti: identiteto izvršljive datoteke ali paketa, cilj, s katerim je komuniciral, in trenutek v delovnem toku, ko se je to zgodilo. Prenos, ki spodleti na začetku, je pogosto pridobivanje metapodatkov z drugo komponento kot prenos, ki spodleti na pol poti. Že ta razlika običajno zadostuje za izbiro prave identitete, preden se dotaknete pravila. Če se identiteta izkaže za storitev in ne aplikacijo, ta en sam podatek spremeni celotno pravilo, zato ga najprej ugotovite.
Če procesa ne morete opazovati, ker je operacija prekratka, jo ponovite z večjo obremenitvijo ali počasnejšim ciljem. Cilj je eno ponovljivo opazovanje, ne teorija o tem, kateri pomočnik sodeluje.
DNS obravnavajte kot lastno pot
Sistemsko razreševanje imen morda sploh ne sledi izključeni aplikaciji, zato izključen brskalnik še vedno lahko spodleti na zasebnem imenu gostitelja, čeprav je njegov promet pravilno zunaj tunela. Brskalnik je bil izključen; razreševalnik ne.
Preverite, kaj platforma počne z DNS, ko velja pravilo za posamezno aplikacijo, in to preverite ločeno od zahteve HTTP. Če je razreševalnik skupna storitev, služi vsaki aplikaciji na napravi, zato ima izjema, ki jo obravnavate, veliko širše občinstvo od tiste, ki ste jo preizkusili.
Zabeležite, kateri razreševalnik je odgovoril in prek katerega vmesnika. To eno opazovanje reši velik del poročil „aplikacija je izključena, vendar ime se ne razreši“, zato ga hranite pri zahtevku.
Ne širite skupnega pomočnika
Skupna storitev opravlja delo za več aplikacij, zato izključitev zaradi popravila enega delovnega toka spremeni tudi nepovezan promet. Background Intelligent Transfer Service v Windowsu je dober primer te oblike: to je infrastruktura, ki jo lahko uporablja veliko aplikacij, in njena identiteta ni identiteta aplikacije, ki je zahtevala prenos.
Preden dodate to izjemo, preverite model pravil, ki ga podpira odjemalec, in zahteve organizacije. Vprašajte, kaj še uporablja komponento, in ali je pravilo, ki ga nameravate napisati, mogoče izraziti glede na cilje namesto glede na skupni proces.
Če zahteve sploh ni mogoče izraziti kot mejo aplikacije, sta politika, ki temelji na ciljih, ali druga odobrena zasnova lahko razumljivejši in varnejši od rastočega seznama izjem za pomočnike.
Preizkusite celoten delovni tok, ne neuspešnega koraka
Po podprti spremembi izvedite predvideno opravilo z novo zahtevo od začetka do konca. Nato izvedite še en delovni tok, ki uporablja skupno komponento, saj se tam široko obhajanje razglasi. Popravek, ki popravi prvo in tiho pokvari drugo, ni popravek. Oba rezultata hranite v zahtevku in drugi delovni tok izrecno poimenujte, da ga lahko pregledovalec ponovi.
Preizkus naj bo majhen in ponovljiv: isti cilj, isti račun, isti pogoji. Če drugi delovni tok ni dokumentiran, vprašajte njegovega lastnika, od česa je odvisen, preden odločite, da je sprememba varna.
Pustite razlog, ne seznama imen
Dokumentirajte komponento, delovni tok, ki mu služi, in razlog za izključitev. Seznam imen pomočnikov brez povezanega namena postane nevzdrževalen v dveh izdajnih ciklih in naslednji inženir pri čiščenju odstrani napačen vnos.
Ena vrstica na izjemo zadostuje: kaj se zlomi brez nje, kdo ima ta delovni tok in kdaj je bil nazadnje preverjen. Ta tri polja spremenijo skrivnostni seznam v politiko, ki jo nekdo lahko brani.