Bumabagsak ang mga pagbubukod sa VPN bawat app kapag kumukuha ng data ang shared na serbisyo

Inihuhukod mo ang isang aplikasyon sa VPN at nabibigo pa rin ang download na kailangan nito o, mas malala, nagsisimula itong gumana at may hindi kaugnay na tumitigil. Ang nakikitang window ay hindi laging ang prosesong nagbubukas ng bawat koneksyon: maaaring ipasa ng aplikasyon ang gawain sa isang helper, sa serbisyo ng paglilipat sa background o sa ganap na ibang pakete. Kaya ang panuntunan bawat app ay nangangailangan ng tunay na modelo ng pagkakakilanlan ng plataporma, hindi ng pamilyar na pangalan ng launcher file. Ang mga pagsusuri sa ibaba ay nagsisimula sa obserbasyon at bumabalik sa aktwal na nagpadala ng kahilingan.

Sa mga ticket na ito, karaniwang dalawang bagay ang sabay na nagkakamali: ang maling komponente ang inihuhukod, at hindi kailanman pinapaliit ang pagbubukod pagkatapos.

Hanapin ang proseso, hindi ang window

Ulitin ang nabigong operasyon at tukuyin ang proseso o pakete na may hawak ng koneksyon habang nangyayari ito. Sa Windows, ibang tanong ito kaysa sa kung aling window ang may focus, dahil ang paglilipat sa background ay maaaring pamagitan ng serbisyong tumatakbo sa sarili nitong pagkakakilanlan. Sa Linux at macOS, lumilitaw ang parehong paghahati bilang mga helper na proseso at system daemon.

Isulat ang tatlong detalye: ang pagkakakilanlan ng executable o pakete, ang destinasyong kinokontak nito, at ang sandali sa workflow nang mangyari ito. Ang download na nabibigo sa simula ay madalas na pagkuha ng metadata ng ibang komponente kaysa sa download na nabibigo sa kalagitnaan. Ang pagkakaibang iyon lamang ay karaniwang sapat upang piliin ang tamang pagkakakilanlan bago mo hipuin ang panuntunan. Kung ang pagkakakilanlan ay lumabas na serbisyo at hindi app, binabago ng nag-iisang katotohanang iyon ang buong panuntunan, kaya itatag muna ito.

Kung hindi mo maobserbahan ang proseso dahil masyadong maikli ang operasyon, ulitin ito gamit ang mas malaking payload o mas mabagal na destinasyon. Ang layunin ay isang obserbasyong maaaring ulitin, hindi isang teorya kung aling helper ang sangkot.

Ituring ang DNS bilang sarili nitong landas

Maaaring hindi sundan ng resolution ng pangalan ng system ang inihukod na aplikasyon, kaya nabibigo pa rin ang inihukod na browser sa isang pribadong hostname habang ang trapiko nito ay tama sa labas ng tunnel. Ang browser ay inihukod; ang resolver ay hindi.

Tingnan kung ano ang ginagawa ng plataporma sa DNS kapag nalalapat ang panuntunan bawat app, at tingnan ito nang hiwalay sa kahilingang HTTP. Kung ang resolver ay shared na serbisyo, pinaglilingkuran nito ang bawat aplikasyon sa device, kaya ang pagbubukod na isinasaalang-alang mo ay may mas malawak na madla kaysa sa sinubukan mo.

Itala kung aling resolver ang sumagot at sa anong interface. Ang nag-iisang obserbasyong iyon ay lumulutas sa malaking bahagi ng mga ulat na «inihukod ang app ngunit hindi naresolba ang pangalan», kaya itabi ito kasama ng ticket.

Huwag palawakin ang shared na helper

Ang shared na serbisyo ay gumagawa ng trabaho para sa ilang aplikasyon, kaya ang paghukod dito upang ayusin ang isang workflow ay nagbabago rin ng hindi kaugnay na trapiko. Ang Background Intelligent Transfer Service sa Windows ay magandang halimbawa ng hugis: ito ay imprastrukturang maaaring gamitin ng maraming aplikasyon, at ang pagkakakilanlan nito ay hindi pagkakakilanlan ng app na humiling ng paglilipat.

Tingnan ang sinusuportahang modelo ng panuntunan ng kliyente at ang mga pangangailangan ng organisasyon bago idagdag ang pagbubukod na iyon. Itanong kung ano pa ang gumagamit ng komponente, at kung ang panuntunang isusulat mo ay maaaring ipahayag laban sa mga destinasyon sa halip na laban sa isang shared na proseso.

Kung ang pangangailangan ay hindi maipahayag bilang hangganan ng aplikasyon, ang patakarang nakabatay sa destinasyon o ibang aprubadong disenyo ay maaaring mas mauunawaan at mas ligtas kaysa sa lumalaking listahan ng mga pagbubukod ng helper.

Subukan ang buong workflow, hindi ang nabigong hakbang

Pagkatapos ng sinusuportahang pagbabago, patakbuhin ang nilalayong gawain gamit ang bagong kahilingan mula simula hanggang wakas. Pagkatapos ay patakbuhin ang isa pang workflow na gumagamit ng shared na komponente, dahil doon nagpapahayag ng sarili ang malawak na pag-iwas. Ang pagbabagong nag-aayos sa una at tahimik na sumisira sa pangalawa ay hindi pagbabago. Itabi ang parehong resulta sa ticket at pangalanan nang tuwiran ang ikalawang workflow, upang maulit ito ng tagasuri.

Panatilihing maliit at nauulit ang pagsubok: parehong destinasyon, parehong account, parehong kondisyon. Kung ang ikalawang workflow ay hindi nakadokumento, itanong sa may-ari nito kung saan ito umaasa bago magpasya na ligtas ang pagbabago.

Mag-iwan ng dahilan, hindi listahan ng pangalan

Idokumento ang komponente, ang workflow na pinaglilingkuran nito at ang dahilan ng paghukod dito. Ang listahan ng mga pangalan ng helper na walang kaugnay na layunin ay nagiging hindi mapapamahalaan sa loob ng dalawang siklo ng release, at tinatanggal ng susunod na inhinyero ang maling entry habang nililinis ito.

Sapat ang isang linya sa bawat pagbubukod: ano ang nasisira kung wala ito, sino ang may-ari ng workflow na iyon, at kailan huling na-verify. Ang tatlong field na iyon ay ginagawang patakarang maipagtatanggol ng kahit sino ang mahiwagang listahan.