Pse tunelimi i ndarë nuk i mbulon përditësimet e aplikacionit tënd

Shton aplikacionin në listën e përjashtimeve të tunelimit të ndarë, aplikacioni arrin internetin direkt, dhe përditësimet ende dështojnë ose ende zvarriten përmes tunelit. Përjashtimi funksionoi. Ai mbuloi vetëm një proces tjetër nga ai që bën shkarkimin, sepse një përditësues modern rrallë është i njëjti skedar ekzekutues si dritarja e aplikacionit.

Miti: përjashtimi i aplikacionit përjashton trafikun e tij

Tunelimi i ndarë sipas aplikacionit përputh një proces, një paketë ose një shteg aplikacioni, në varësi të platformës. Nuk përputh një markë, një veçori ose një qëllim të përdoruesit. Kur aplikacioni ia dorëzon shkarkimin një ndihmësi, një shërbimi të përbashkët platforme ose një komponenti shfletuesi, ai ndihmës ka identitetin e vet dhe shtegun e vet përmes tunelit. Lista e përjashtimeve nuk e ka idenë që dy proceset i përkasin të njëjtit produkt. Di vetëm se cilën emërove.

Pra rregulli po bën saktësisht atë që i është thënë. Supozimi se kush e zotëron transferimin ishte i gabuar, dhe rregullimi fillon me identifikimin e atij pronari, jo me shtimin e më shumë përjashtimeve.

Gjej pronarin e transferimit

Në Android, përditësimin mund ta sjellë një paketë shërbimi e përbashkët dhe jo paketa e aplikacionit që përjashtove, dhe një rregull VPN për çdo aplikacion zbatohet për paketën që hap soketin. Në Windows, një shërbim përditësimi mund të ekzekutohet nën një shteg ekzekutues të ndryshëm nga aplikacioni, kështu që një rregull që përputhet me shtegun e aplikacionit nuk e kap. Në macOS, një ndihmës i privilegjuar ose një demon përditësimi i sistemit mund ta kryejë transferimin ndërsa aplikacioni vetëm e kërkon.

Identifiko pronarin nga provat: pamja e aktivitetit të rrjetit të platformës, një kapje paketash e filtruar sipas procesit ose dokumentacioni i furnizuesit që e emërton komponentin e përditësimit. Të hamendësosh nga emri i procesit është mënyra se si dy binare të ngjashme ngatërrohen dhe përjashtohet ai i gabuari.

Sistemet e përditësimit shpesh e ndajnë edhe punën. Një kërkesë e vogël metadatash kontrollon një version, dhe një shkarkim pakete shumë më i madh shkon te një host shpërndarjeje përmbajtjeje ose te një domen tjetër. Kontrolli i metadatës mund të ketë sukses përmes tunelit ndërsa transferimi i paketës ngec në një host që tuneli e drejton ndryshe. Kjo ndarje shpjegon raportin konfuz ku përditësimet zbulohen por nuk instalohen kurrë. Testo vetë shkarkimin e paketës, nga i njëjti pajisje dhe i njëjti rrjet, në vend që të testosh nëse hapet aplikacioni.

Verifikimi mbijeton një ndryshim të shtegut

Ndryshimi i një shtegu nuk zëvendëson TLS, identitetin e botuesit ose verifikimin e nënshkrimit të paketës. Mos i fik ato kontrolle sepse një shkarkim ka sukses vetëm pasi kalon një paralajmërim certifikate të pashpjeguar. Një paralajmërim që shfaqet vetëm në shtegun e përjashtuar është një gjetje, jo një pengesë. Hulumtoje para se të zgjerosh anashkalimin.

Në një pajisje të menaxhuar, kërko një përjashtim të mbështetur në vend që të shtosh një rregull të gjerë për çdo shërbim sistemi. Një rregull që përjashton të gjitha shërbimet e përbashkëta për të rregulluar një përditësues e zgjeron anashkalimin shumë përtej kërkesës fillestare.

Testo përditësimin, pastaj dokumento pronarin

Rilidhu pas ndryshimit dhe verifiko përsëri rregullin e aplikuar, sepse disa klientë rindërtojnë drejtimin e tyre kur tuneli rilidhet. Ekzekuto një cikël të plotë përditësimi: kontrollo, shkarko, verifiko dhe instalo. Një kontroll i suksesshëm provon vetëm pjesën më të vogël të shtegut.

Regjistro pronarin e transferimit, hostet e destinacionit dhe shtegun e synuar në të njëjtin vend ku është rregulli i tunelimit të ndarë. Përndryshe ndryshimi i ardhshëm i mekanizmit të përditësimit do ta bëjë përjashtimin të pavlefshëm në heshtje, dhe personi që e trashëgon nuk do të ketë asnjë mënyrë të dijë për cilin proces u shkrua rregulli.