Waarom gesplete tonnelering nie jou app se opdaterings dek nie

Jy voeg die toepassing by die uitsluitlys van gesplete tonnelering, die app bereik die internet direk, en die opdaterings misluk steeds of kruip steeds deur die tonnel. Die uitsluiting het gewerk. Dit het net ’n ander proses gedek as die een wat die aflaai doen, want ’n moderne opdatering is selde dieselfde uitvoerbare lêer as die toepassingsvenster.

Die mite: om die app uit te sluit, sluit nie sy verkeer uit nie

Gesplete tonnelering per app pas by ’n proses, ’n pakket of ’n toepassingspad, afhangend van die platform. Dit pas nie by ’n handelsmerk, ’n funksie of ’n gebruiker se bedoeling nie. Wanneer die toepassing die aflaai aan ’n helper, ’n gedeelde platformdiens of ’n blaaierkomponent oorhandig, het daardie helper sy eie identiteit en sy eie pad deur die tonnel. Die uitsluitlys het geen idee dat die twee prosesse aan dieselfde produk behoort nie. Dit weet net watter een jy genoem het.

Dus doen die reël presies wat aan hom gesê is. Die aanname oor wie die oordrag besit, was verkeerd, en die oplossing begin met die identifisering van daardie eienaar eerder as om meer uitsluitings by te voeg.

Vind die eienaar van die oordrag

Op Android kan die opdatering deur ’n gedeelde dienspakket eerder as die app-pakket wat jy uitgesluit het, afgelaai word, en ’n VPN-reël per app geld vir die pakket wat die sok oopmaak. Op Windows kan ’n opdateringsdiens onder ’n ander uitvoerbare pad as die toepassing loop, so ’n reël wat by die app-pad pas, mis dit. Op macOS kan ’n bevoorregte helper of ’n stelselopdateringsdaemon die oordrag doen terwyl die app dit net aanvra.

Identifiseer die eienaar uit bewyse: die platform se netwerkaktiwiteitsaansig, ’n pakketopname wat per proses gefiltreer is, of die verskaffer se dokumentasie wat die opdateringskomponent noem. Om uit die prosesnaam te raai, is hoe twee eenders lykende binêre lêers verwar word en die verkeerde een uitgesluit word.

Opdateringstelsels verdeel dikwels ook die werk. ’n Klein metadata-navraag kontroleer vir ’n weergawe, en ’n veel groter pakket-aflaai gaan na ’n inhoudafleweringsgasheer of ’n ander domein. Die metadata-kontrole kan deur die tonnel slaag terwyl die pakket-oordrag vassteek by ’n gasheer wat die tonnel anders roeteer. Daardie verdeling verduidelik die verwarrende verslag waar opdaterings opgespoor maar nooit geïnstalleer word nie. Toets die pakket-aflaai self, vanaf dieselfde toestel en dieselfde netwerk, eerder as om te toets of die toepassing oopmaak.

Verifikasie oorleef ’n roeteverandering

Om ’n roete te verander vervang nie TLS, uitgewersidentiteit of pakket-handtekeningverifikasie nie. Moenie daardie kontroles afskakel omdat ’n aflaai net slaag nadat jy deur ’n onverklaarde sertifikaatwaarskuwing gekliek het nie. ’n Waarskuwing wat net op die uitgeslote pad verskyn, is ’n bevinding, nie ’n hindernis nie. Ondersoek dit voordat jy die omseil uitbrei.

Op ’n bestuurde toestel, vra vir ’n ondersteunde uitsondering eerder as om ’n breë reël vir elke stelseldiens by te voeg. ’n Reël wat alle gedeelde dienste uitsluit om een opdatering reg te maak, verbreed die omseil ver verby die oorspronklike versoek.

Toets die opdatering en dokumenteer dan die eienaar

Herverbind ná die verandering en verifieer die toegepaste reël weer, want sommige kliënte bou hul roetebepaling weer op wanneer die tonnel herverbind. Voer een volle opdateringsiklus uit: kontroleer, laai af, verifieer en installeer. ’n Suksesvolle kontrole bewys die kleinste deel van die pad.

Teken die oordrag-eienaar, die bestemmingsgashere en die beoogde roete op dieselfde plek as die reël vir gesplete tonnelering aan. Die volgende verandering aan die opdateringsmeganisme sal die uitsondering andersins stilweg ongeldig maak, en die persoon wat dit erf, sal geen manier hê om te weet vir watter proses die reël geskryf is nie.