A megosztott alagút továbbra is kizár egy alkalmazást, amelyet eltávolítottál

A régi alkalmazás eltűnt, a megosztott alagút listáján mégis ott van a bejegyzése. Semmi sem látszik eltörni, ezért hónapokig ott marad. Aztán valaki egy másik programot telepít ugyanabba a mappába, vagy egy felügyelt profil minden újracsatlakozáskor visszaállítja a szabályt, és a forgalom olyan útra tér, amelyet senki sem tervezett. A kizárás túlélte azt az okot, amelyért létezett.

Ennek a tisztítása főként identitás kérdése: mire mutat most a szabály, és kié a lista.

A tünet: egy kizárás, amely semmihez nem illeszkedik

Az elavult bejegyzés normál használatban láthatatlan. Három módon válik láthatóvá: egy alkalmazás, amelyről azt vártad, hogy az alagúton megy, közvetlenül megy, egy új program örököl egy régi kivételt, vagy a kliens megtagadja a szerkesztés mentését, mert a felügyelt profil felülírja. Mindhárom külön hibának tűnik, és mindhárom ugyanaz a nyilvántartási probléma. Mindegyiket olcsó ellenőrizni és drága rosszul diagnosztizálni.

Kezdd a szabály elolvasásával, ne a törlésével.

Derítsd ki, mit azonosít a szabály

A megosztott alagút megvalósításai különböző dolgokra alapozzák a kizárásokat: egy futtatható fájl útvonalára, egy csomagnévre, egy csomagazonosítóra vagy egy útvonalra. Az útvonalalapú szabály olyan fájlra mutat, amely már nem létezhet, vagy amely most már más fájl lehet. A csomagalapú szabály olyan identitásra mutat, amelyet egy új telepítés újra felhasználhat. Olvasd el a kliens dokumentációját ahhoz a mezőhöz, amelyet nézel, mert ugyanaz a szövegmező terméktől függően mást jelent. Az Android VpnService-útmutatója a csomagalapú eset referenciája.

A megjelenített név a bejegyzés legkevésbé megbízható része, és éppen ezt olvassák az emberek.

Az útvonalszabályok és a csomagszabályok eltérően viselkednek

Az eltávolítást túlélő útvonalszabály általában hatástalanná válik, és a hatástalanság a jó eredmény. A rossz eredmény egy újra felhasznált útvonal, mert az új futtatható fájl csendesen örökli a kivételt. A csomagszabályok megint másként viselkednek: egy termék figyelmen kívül hagyhat egy nem elérhető csomagot, elutasíthatja, vagy továbbra is név szerint egyeztethet, amikor valami új igényt tart erre a névre.

Ne vigyél át egy feltételezést egyik kliensről a másikra. Ellenőrizd, hogy a tiéd valójában mit tesz egy hiányzó céllal, ideális esetben úgy, hogy szándékosan létrehozod a feltételt egy tesztgépen, és figyeled, melyik folyamat örökli a kivételt.

Távolítsd el a tulajdonoson keresztül

Ha a lista felügyelt profilból származik, a helyi szerkesztés ideiglenes változás, amely a következő újracsatlakozáskor visszaáll. Módosítsd a profilt, vagy kérdezd meg azt, akié, és erősítsd meg, hogy a szerkesztés túléli az újracsatlakozást. Ha a lista helyi, távolítsd el a bejegyzést, és ellenőrizd, hogy a kliens újraírta-e a konfigurációját ahelyett, hogy a régit a memóriában tartaná.

Az üres lista nem cél. Az a cél, hogy a lista bejegyzései még mindig valódi követelményeknek feleljenek meg.

Utána teszteld mindkét irányt

A tisztítás után tesztelj egy alkalmazást, amelynek még mindig kizártnak kell lennie, és egy alkalmazást, amelynek most az alagúton kell mennie. Külön erősítsd meg a DNS viselkedését, mert a feloldó házirendje más szabályozás, mint a kizárási lista. Ezután csatlakozz újra egyszer, és teszteld újra, mivel a visszaállított profil a leggyakoribb módja annak, hogy egy tisztítás csendesen visszavonja önmagát.

Tarts egy egysoros célt minden fennmaradó kivétel mellett. Ez a sor az, ami megakadályozza, hogy a lista múzeummá váljon, és ötperces munkává teszi a következő tisztítást.