Kial dividita tunelado ne kovras la ĝisdatigojn de via apo

Vi aldonas la aplikaĵon al la ekskluda listo de dividita tunelado, la apo atingas la interreton rekte, kaj la ĝisdatigoj ankoraŭ malsukcesas aŭ ankoraŭ rampas tra la tunelo. La ekskludo funkciis. Ĝi nur kovris alian procezon ol tiu, kiu faras la elŝuton, ĉar moderna ĝisdatigilo malofte estas la sama plenumebla dosiero kiel la aplikaĵa fenestro.

La mito: ekskludi la apon ekskludas ĝian trafikon

Dividita tunelado laŭ apo kongruigas procezon, pakaĵon aŭ aplikaĵan vojon, depende de la platformo. Ĝi ne kongruigas markon, funkcion aŭ intencon de uzanto. Kiam la aplikaĵo transdonas la elŝuton al helpanto, al komuna platforma servo aŭ al retumila komponanto, tiu helpanto havas sian propran identecon kaj sian propran vojon tra la tunelo. La ekskluda listo tute ne scias, ke la du procezoj apartenas al la sama produkto. Ĝi nur scias, kiun vi nomis.

Do la regulo faras ĝuste tion, kion oni diris al ĝi. La supozo pri tio, kiu posedas la transdonon, estis malĝusta, kaj la korekto komenciĝas per identigo de tiu posedanto anstataŭ per aldono de pli da ekskludoj.

Trovu la posedanton de la transdono

En Android, la ĝisdatigon povas elŝuti komuna serva pakaĵo anstataŭ la apa pakaĵo, kiun vi ekskludis, kaj VPN-regulo laŭ apo validas por la pakaĵo, kiu malfermas la ingon. En Windows, ĝisdatiga servo povas funkcii sub alia plenumebla vojo ol la aplikaĵo, do regulo, kiu kongruas kun la apa vojo, maltrafas ĝin. En macOS, privilegiita helpanto aŭ sistema ĝisdatiga demono povas plenumi la transdonon, dum la apo nur petas ĝin.

Identigu la posedanton per pruvoj: la reta aktiveca vido de la platformo, paketa kapto filtrita laŭ procezo, aŭ la vendista dokumentaro, kiu nomas la ĝisdatigan komponanton. Diveni laŭ la proceza nomo estas kiel du simile aspektaj binaraj dosieroj konfuziĝas kaj la malĝusta ekskludiĝas.

Ĝisdatigaj sistemoj ofte ankaŭ dividas la laboron. Malgranda metadatenpetaĵo kontrolas version, kaj multe pli granda pakaĵa elŝuto iras al enhavotransdona gastiganto aŭ al alia domajno. La metadatenkontrolo povas sukcesi tra la tunelo, dum la pakaĵa transdono haltas ĉe gastiganto, kiun la tunelo enkursigas alimaniere. Tiu divido klarigas la konfuzan raporton, kie ĝisdatigoj estas trovitaj sed neniam instalitaj. Testu la pakaĵan elŝuton mem, de la sama aparato kaj la sama reto, anstataŭ testi, ĉu la aplikaĵo malfermiĝas.

La kontrolo postvivas vojan ŝanĝon

Ŝanĝi vojon ne anstataŭigas TLS, eldonanto-identecon aŭ pakaĵan subskribokontrolon. Ne malŝaltu tiujn kontrolojn ĉar elŝuto sukcesas nur post kiam vi klakas preter neklarigita atestila averto. Averto, kiu aperas nur sur la ekskludita vojo, estas trovaĵo, ne obstaklo. Esploru ĝin antaŭ ol vi larĝigos la pretervojon.

Sur administrata aparato, petu subtenatan escepton anstataŭ aldoni larĝan regulon por ĉiu sistema servo. Regulo, kiu ekskludas ĉiujn komunajn servojn por ripari unu ĝisdatigilon, larĝigas la pretervojon multe preter la origina peto.

Testu la ĝisdatigon, poste dokumentu la posedanton

Rekonektu post la ŝanĝo kaj denove kontrolu la aplikitan regulon, ĉar iuj klientoj rekonstruas sian enkursigon kiam la tunelo rekonektiĝas. Plenumu unu plenan ĝisdatigan ciklon: kontroli, elŝuti, kontroli kaj instali. Sukcesa kontrolo pruvas nur la plej malgrandan parton de la vojo.

Skribu la posedanton de la transdono, la celajn gastigantojn kaj la celatan vojon en la sama loko kiel la regulo de dividita tunelado. Alie, la sekva ŝanĝo de la ĝisdatiga mekanismo silente malvalidigos la escepton, kaj la persono, kiu ĝin heredas, havos neniun manieron scii, por kiu procezo la regulo estis skribita.