A VPN-kliens jelszókérései egyformának tűnnek, és nem azok. Négy különböző művelet bújik meg egy hasonló párbeszédablak mögött: fájlok írása védett helyre telepítés közben, hálózati beállítás hozzáadása vagy módosítása, a forgalmat vivő rendszerkiterjesztés aktiválása, és a felügyeleti kiszolgáló által már beállított házirend betartása. Mindegyiknek más a gazdája, más a hatóköre és más a módja annak ellenőrzésére, hogy működött-e. A látott üzenet és a négy közül az egyik összepárosítása az egész gyakorlat.

Három különböző jóváhagyás ugyanúgy néz ki

A telepítői engedélyezés a legegyszerűbb eset: a csomag olyan könyvtárakba ír, amelyeket szokásos felhasználó nem módosíthat, és a macOS rendszergazdai hitelesítő adatokat kér ehhez. A rendszer nem arról dönt, hogy a szoftver biztonságos-e; arról dönt, hogy írhat-e oda. Ezért lehet egy csomagot tisztán telepíteni és mégis haszontalannak lenni: a telepítés jóváhagyása semmit sem mond arról, hogy a kód később futhat-e. Telepítés után az alkalmazásnak még egy második jóváhagyásra lehet szüksége, mielőtt hatással lehet a hálózatra.

A hálózati beállítás engedélyezése a rendszer kapcsolatlistájának változásait fedi le. VPN-szolgáltatás hozzáadása, vagy hálózati rendszergazda által beállított értékek módosítása emelést igényel, mert ezek a meghatározások a gép minden fiókjára hatnak. Ez a jóváhagyás beállítási jogosultságot ad, nem forgalmi jogosultságot.

A kiterjesztés jóváhagyása az, ami a csomagok útvonala szempontjából számít. A modern kliens olyan rendszerkiterjesztést telepít, amelyet a macOS betölt a rendszerbe, és a macOS az aktiválás előtt kifejezett döntést kér az Adatvédelem és biztonság vagy a Bejelentkezési elemek és kiterjesztések alatt. Negyedik eset a felügyelt Mac, ahol egy házirend már előre jóváhagyja a kiterjesztést, és a felhasználó egyáltalán nem lát párbeszédablakot.

Mit változtat valójában az egyes jóváhagyások

A telepítő fájlokat változtat a lemezen, és következményei a fájlok eltávolításával véget érnek, a maradékoktól eltekintve. A hálózati beállítás szolgáltatásdefiníciót ad hozzá, amely megjelenik a kapcsolatlistán, és igény szerinti szabályok újra aktiválhatják. A kiterjesztés jóváhagyása megváltoztatja, milyen kódot tölt be és tart futva a rendszer, ezért bizonyos munkafolyamatokban túléli a látható alkalmazás eltávolítását. Az alkalmazáscsomag eltávolítása nem mindig távolítja el a kiterjesztését, és a hátrahagyott kiterjesztés megtartja hálózati kiváltságait.

A megkülönböztetés előre jelzi a tünetet. Telepítve, de soha nem csatlakozik: általában azt jelenti, hogy a kiterjesztés sehol nincs jóváhagyva; csatlakozik, de a beállítások a következő változtatásnál visszaállnak: általában azt jelenti, hogy a definíció egy felügyeleti házirend tulajdona.

Az aláírás és a kiadó dönti el a választ

Jóváhagyás előtt olvassa el, ki írta alá a dolgot, ne azt, amit a párbeszédablak ikonja sugall. Két helyi ellenőrzés elég ahhoz, hogy lássa az aláíró hatóságot, és hogy a rendszer értékelése átmegy-e ezen a gépen.

codesign -dv --verbose=2 /Applications/ExampleVPN.app
spctl -a -vv /Applications/ExampleVPN.app

Az aláírás nélküli vagy notarizálatlan csomag nem automatikusan rosszindulatú, de más döntést érdemel, mint a szándékolt szállító aláírt csomagja. Az üzenetben érkezett, nem a szállító saját oldaláról származó csomag az az eset, amikor a válasz egyszerűen nem.

Hasonlítsa össze a csapatazonosítót a szállító közzétett identitásával, ahelyett hogy az alkalmazás megjelenített nevében bízna, mert a neveket könnyű újrahasználni, az azonosítókat nem. Ha a szállító közzéteszi az azonosítót a telepítési útmutatójában, az az oldal az összehasonlítás referenciája, és egyben az a hely, ahol az eltérést jelenteni kell. A viszonteladótól, újracsomagolt buildből vagy fórumról származó hordozható másolat több gyanút érdemel, mint ugyanazon szállító aláírt letöltése.

Amikor egy házirend birtokolja a döntést

Vállalati Macen a rendszergazda már dönthetett. A felügyeleti profil szállíthatja a VPN-definíciót, előre jóváhagyhatja a kiterjesztést és zárolhatja a kapcsolatot, hogy ne lehessen eltávolítani. Ebben a felállásban a jelszó megadására vonatkozó kérés gyakran egy olyan döntés felülírása, amely soha nem volt az öné.

Az indítási biztonság csökkentése vagy a felügyelet leválasztása a telepítés kikényszerítéséhez véglegesen megváltoztatja a gép fenyegetési modelljét egy ideiglenes probléma megoldásáért. Ez a csere ritkán tudatos; általában egy fórumbejegyzés követése közben történik. Kérje inkább a támogatott utat a rendszergazdától, ami olyan egyszerű is lehet, mint a profil újraküldése vagy a kiterjesztés jóváhagyása a kiszolgálón. Ha a rendszergazda nem tudja jóváhagyni, az a válasz a lelet, nem pedig megkerülendő akadály.

Erősítse meg az állapotot a jóváhagyás után

Miután megtörtént a jogosult jóváhagyás, ellenőrizze, mit gondol a rendszer, ne azt, amit a kliens állít. A kiterjesztéslista harmadik féltől származó eszköz nélkül jelenti az aktiválási állapotot.

systemextensionsctl list

Az aktiváltként megjelenő bejegyzés ahhoz a csapatazonosítóhoz tartozik, amelyet korábban ellenőrzött; a felhasználói jóváhagyásra váró, leállítottként megjelenő bejegyzés olyan klienst magyaráz, amely elindul és soha nem visz forgalmat. Ha a kérés minden kísérlet után visszatér, rögzítse a pontos üzenetet és a kliens verzióját, mert az ismétlődő jóváhagyás általában azt jelenti, hogy a kiterjesztést az előző deaktiválása nélkül cserélik, és ez támogatási eset, nem jelszóprobléma. Jegyezze fel a verziót a támogatás hívása előtt, mert a javítás már lehet újabb buildben, és a beszélgetés ott fog kezdődni.

Kapcsolódó cikkek