Miks jaotatud tunnel ei kata sinu rakenduse värskendusi

Lisad rakenduse jaotatud tunneli välistuste nimekirja, rakendus pääseb internetti otse, ning värskendused ikka ebaõnnestuvad või ikka roomavad läbi tunneli. Välistus toimis. See kattis lihtsalt teist protsessi kui see, mis allalaadimise teeb, sest kaasaegne värskendaja on harva seesama käivitatav fail, mis rakenduse aken.

Müüt: rakenduse välistamine välistab selle liikluse

Rakendusepõhine jaotatud tunnel sobitab protsessi, paketi või rakenduse tee, olenevalt platvormist. See ei sobita brändi, funktsiooni ega kasutaja kavatsust. Kui rakendus annab allalaadimise üle abiprogrammile, jagatud platvormiteenusele või brauseri komponendile, on sellel abiprogrammil oma identiteet ja oma tee läbi tunneli. Välistuste nimekirjal pole aimugi, et kaks protsessi kuuluvad sama toote juurde. Ta teab ainult, millise sa nimetasid.

Nii et reegel teeb täpselt seda, mida talle öeldi. Eeldus selle kohta, kellele ülekanne kuulub, oli vale, ja parandus algab selle omaniku tuvastamisest, mitte täiendavate välistuste lisamisest.

Leia ülekande omanik

Androidis võib värskenduse hankida jagatud teenusepakett, mitte rakenduse pakett, mille sa välistasid, ja rakendusepõhine VPN-reegel kehtib paketile, mis pistiku avab. Windowsis võib värskendusteenus töötada rakendusest erineva käivitatava tee all, nii et rakenduse teega sobiv reegel jätab selle vahele. macOS-is võib ülekande teha privilegeeritud abiprogramm või süsteemi värskendusdeemon, samal ajal kui rakendus ainult küsib seda.

Tuvasta omanik tõendite põhjal: platvormi võrguaktiivsuse vaade, protsessi järgi filtreeritud paketipüük või tarnija dokumentatsioon, mis nimetab värskenduskomponenti. Protsessi nimest oletamine on viis, kuidas kaks sarnast binaarfaili segi aetakse ja vale välistatakse.

Värskendussüsteemid jagavad sageli ka tööd. Väike metaandmete päring kontrollib versiooni, ja palju suurem paketi allalaadimine läheb sisu kohaletoimetamise hosti või teise domeeni. Metaandmete kontroll võib tunnelist läbi minna, samal ajal kui paketi ülekanne takerdub hostis, mida tunnel teisiti marsruudib. See jagunemine selgitab segadust tekitavat aruannet, kus värskendused avastatakse, kuid neid ei paigaldada kunagi. Testi paketi allalaadimist ennast, samast seadmest ja samast võrgust, mitte seda, kas rakendus avaneb.

Kontroll elab marsruudimuudatuse üle

Marsruudi muutmine ei asenda TLS-i, avaldaja identiteeti ega paketi allkirja kontrolli. Ära lülita neid kontrolle välja sellepärast, et allalaadimine õnnestub alles siis, kui klõpsad läbi seletamatu sertifikaadihoiatuse. Hoiatus, mis ilmub ainult välistatud teel, on leid, mitte takistus. Uuri seda enne, kui möödapääsu laiendad.

Haldatud seadmes küsi toetatud erandit, selle asemel et lisada lai reegel iga süsteemiteenuse jaoks. Reegel, mis välistab kõik jagatud teenused, et parandada üks värskendaja, laiendab möödapääsu palju kaugemale algupärasest taotlusest.

Testi värskendust ja dokumenteeri seejärel omanik

Pärast muudatust ühendu uuesti ja kontrolli rakendatud reeglit veel kord, sest mõned kliendid ehitavad marsruutimise uuesti üles, kui tunnel uuesti ühendub. Tee üks täielik värskendustsükkel: kontrolli, laadi alla, kontrolli ja paigalda. Edukas kontroll tõestab ainult tee väikseimat osa.

Kirjuta ülekande omanik, sihthostid ja kavandatud marsruut samasse kohta nagu jaotatud tunneli reegel. Vastasel juhul muudab järgmine värskendusmehhanismi muudatus erandi vaikselt kehtetuks ja selle pärija ei saa kuidagi teada, millise protsessi jaoks reegel kirjutati.