Miksi jaettu tunneling ei kata sovelluksesi päivityksiä

Lisäät sovelluksen jaetun tunnelingin poissulkuluetteloon, sovellus pääsee internetiin suoraan, ja päivitykset silti epäonnistuvat tai silti raahautuvat tunnelin läpi. Poissulkeminen toimi. Se kattoi vain eri prosessin kuin se, joka tekee latauksen, koska nykyaikainen päivittäjä on harvoin sama suoritettava tiedosto kuin sovelluksen ikkuna.

Myytti: sovelluksen poissulkeminen sulkee pois sen liikenteen

Sovelluskohtainen jaettu tunneling sovittaa prosessin, paketin tai sovelluksen polun alustasta riippuen. Se ei sovita brändiä, ominaisuutta eikä käyttäjän aikomusta. Kun sovellus luovuttaa latauksen apuohjelmalle, jaetulle alustapalvelulle tai selaimen komponentille, tuolla apuohjelmalla on oma identiteettinsä ja oma polkunsa tunnelin läpi. Poissulkuluettelolla ei ole aavistustakaan, että kaksi prosessia kuuluu samaan tuotteeseen. Se tietää vain, kumman nimesit.

Sääntö tekee siis täsmälleen sen, mitä sille sanottiin. Oletus siitä, kuka omistaa siirron, oli väärä, ja korjaus alkaa tuon omistajan tunnistamisesta sen sijaan, että lisättäisiin lisää poissulkemisia.

Selvitä siirron omistaja

Androidissa päivityksen voi hakea jaettu palvelupaketti sen sijaintipaketin sijaan, jonka poissuljit, ja sovelluskohtainen VPN-sääntö koskee pakettia, joka avaa pistokkeen. Windowsissa päivityspalvelu voi toimia eri suoritettavan polun alla kuin sovellus, joten sovelluksen polkuun sopiva sääntö ei tavoita sitä. macOSissa etuoikeutettu apuohjelma tai järjestelmän päivitystaustaprosessi voi suorittaa siirron, kun sovellus vain pyytää sitä.

Tunnista omistaja todisteista: alustan verkkoaktiviteettinäkymä, prosessin mukaan suodatettu paketinkaappaus tai toimittajan dokumentaatio, joka nimeää päivityskomponentin. Prosessin nimestä arvaaminen on se tapa, jolla kaksi samannäköistä binaaritiedostoa sekoitetaan ja väärä suljetaan pois.

Päivitysjärjestelmät jakavat usein työn myös. Pieni metatietopyyntö tarkistaa version, ja paljon suurempi paketin lataus menee sisällönjakelun isäntään tai toiseen verkkotunnukseen. Metatietojen tarkistus voi onnistua tunnelin läpi, kun taas paketin siirto juuttuu isäntään, jonka tunneli reitittää eri tavalla. Tämä jakautuminen selittää hämmentävän raportin, jossa päivitykset havaitaan mutta niitä ei koskaan asenneta. Testaa itse paketin latausta samasta laitteesta ja samasta verkosta sen sijaan, että testaisit, avautuuko sovellus.

Vahvistus kestää reitin muutoksen

Reitin muuttaminen ei korvaa TLS:ää, julkaisijan identiteettiä eikä paketin allekirjoituksen vahvistusta. Älä sammuta noita tarkistuksia siksi, että lataus onnistuu vasta, kun olet ohittanut selittämättömän varmennevaroituksen. Varoitus, joka näkyy vain poissuljetulla reitillä, on löydös, ei este. Tutki se ennen kuin laajennat ohitusta.

Hallinnoidulla laitteella pyydä tuettu poikkeus sen sijaan, että lisäisit laajan säännön jokaiselle järjestelmäpalvelulle. Sääntö, joka sulkee pois kaikki jaetut palvelut yhden päivittäjän korjaamiseksi, laajentaa ohitusta paljon alkuperäistä pyyntöä pidemmälle.

Testaa päivitys ja dokumentoi sitten omistaja

Yhdistä uudelleen muutoksen jälkeen ja varmista käytetty sääntö uudelleen, koska jotkut asiakkaat rakentavat reitityksensä uudelleen, kun tunneli yhdistetään uudelleen. Suorita yksi täysi päivityssykli: tarkista, lataa, vahvista ja asenna. Onnistunut tarkistus todistaa vain pienimmän osan polusta.

Kirjaa siirron omistaja, kohdeisännät ja aiottu reitti samaan paikkaan kuin jaetun tunnelingin sääntö. Muuten seuraava päivitysmekanismin muutos mitätöi poikkeuksen äänettömästi, eikä sen perivä henkilö voi mitenkään tietää, mille prosessille sääntö kirjoitettiin.