Mac VPN-kliens: Network Extension kontra System Extension

Két Apple-kifejezést használnak úgy, mintha ugyanazt jelölnék, és ez a zavar rossz beállítási panelre küldi az embereket. A Network Extension egy képességet ír le: a VPN-alagutak, proxyk és szűrők támogatott megvalósítási módját. A System Extensions a felhasználói térben futó kiterjesztések szállítási és jóváhagyási mechanizmusát írja le. Egy modern Mac VPN-kliensnek általában mindkettőre szüksége van, ezért egyik címke sem magyaráz meg egyedül egy tünetet. A kettő szétválasztása megválaszolja, melyik összetevőt kell vizsgálni és melyik jóváhagyási lépésre kell számítani.

Két kérdés, nem egy címke

Kérdezze meg, mit tesz az összetevő, mielőtt azt kérdezné, hogyan telepítik. A képesség dönti el, melyik szolgáltatóosztály létezik, és ezáltal melyik kód kezeli a csomagjait. A szállítási mechanizmus dönti el, hogyan érkezik a bináris, hogyan hagyják jóvá, és hol rögzítik az állapotát. Egy termék megvalósíthat csomagalagutat anélkül, hogy rendszerkiterjesztést szállítana a régebbi kiadásokon, és szállíthat olyan rendszerkiterjesztést, amely nem alagutat valósít meg.

A kernelfejlesztések a harmadik kifejezés, amit az emberek összekevernek. Ezek voltak a kiemelt hálózati kód futtatásának régebbi módja, más jóváhagyásokat igényeltek, és az Apple évek óta eltereli tőlük a fejlesztőket. Egy kernelfejlesztési jóváhagyási recept alkalmazása egy modern kliensre olyan párbeszédre pazarol időt, amely soha nem fog megjelenni.

Olvassa el a szállító telepítési megjegyzéseit az Ön által futtatott macOS-verzióhoz a korábbi kiadásból származó fórumbejegyzés helyett. Az architektúra többször is megváltozott, és az utasítások gyorsan elavulnak. A kernelfejlesztés jóváhagyását említő megjegyzés a termék egy másik korszakát írja le.

Mit nyújt a Network Extension

A keretrendszer szolgáltatótípusokat kínál a szokásos hálózati feladatokhoz: csomagalagutat a VPN-forgalomhoz, alkalmazásproxyt az alkalmazásonkénti folyamokhoz, tartalomszűrőt a forgalom vizsgálatához és DNS-proxykezelést a feloldó viselkedéséhez. A szolgáltatótípus határozza meg, mit tehet a kiterjesztés, és egy két szolgáltatót szállító kliens két különböző feladatot láthat el.

Ez a diagnózis során számít, mert ugyanaz a kapcsolódási tünet jöhet alagútból, szűrőből vagy DNS-proxyból. Egy webhely blokkolása szűrődöntés, egy privát alhálózat elérésének hiánya általában alagútdöntés, a rossz cím feloldása pedig általában feloldódöntés. A szolgáltatótípus megnevezése leszűkíti a keresést, mielőtt bármilyen naplót olvasnának.

A keretrendszerben semmi sem utal adatvédelmi álláspontra. A felhasználói térben futó kiterjesztésnek továbbra is vannak engedélyei, konfigurációja és mögötte egy üzemeltető, ezért tekintse az architektúrát megvalósítási részletnek, nem bizalmi jelzésnek. Kérdezze meg, ki üzemelteti a végpontot, és mit gyűjtésre állítottak be.

Mit változtat a System Extensions

A mechanizmus a kiemelt kódot a kernelből a felhasználói térbe helyezi, és megváltoztatja, hogyan kér hozzájárulást az operációs rendszer. Az aktiválás az telepítéstől külön lépés, és a felhasználónak vagy egy MDM-profilnak engedélyeznie kell. Kliens, amely települ, de soha nem aktiválódik jelenlévőnek tűnik az Applications mappában, és semmit sem tesz a kapcsolódásért.

Az állapotot a rendszer rögzíti, nem az alkalmazás, ami hasznos, mert lekérdezhető. Az alábbi parancs felsorolja a rendszer által ismert kiterjesztéseket és aktiválási állapotukat.

systemextensionsctl list
scutil --nc list

Az első parancs megválaszolja, hogy az összetevő telepítve és aktiválva van-e. A második felsorolja a rendszer által tárolt VPN-konfigurációkat, ami más kérdés, és gyakran ez a fontos, amikor a kapcsolati profil hiányzik, nem pedig törött.

Melyiket vizsgáljuk egy adott tünetnél

Párosítsa a tünetet a réteghez, mielőtt beállítási panelt nyitna. A hiányzó konfiguráció profilkérdés, a telepített de inaktív összetevő szállítási kérdés, és az aktív összetevő, amely nem engedi át a forgalmat, képesség kérdése.

A naplófolyam a közös bizonyíték az utolsó két sorhoz. A hálózatikiterjesztés-alrendszer olvasása megmondja, melyik szolgáltató kezelte a folyamot, és egy szűrődöntés másképp néz ki, mint egy alagúthiba, még akkor is, ha a felhasználó mindkettőt törött VPN-ként írja le.

log show --last 10m --predicate 'process == "nesessionmanager"'

Ne következtessen arra, hogy egy kiterjesztés aktív, mert van egy ikon a menüsorban. Az ikonok túlélik a sikertelen aktiválásokat, és az elavult ikon az egyik leggyakoribb oka annak, hogy egy támogatási hívás rossz helyen kezdődik. Olvassa inkább az aktiválási állapotot, mert a rendszer azt rögzíti.

Jóváhagyás, MDM és a kernelfejlesztés mítosza

Kezelt Maceken a jóváhagyási lépés az MDM-profilhoz tartozik, és egy felhasználó, aki a System Settingsben az Allow gombra kattint, továbbra is blokkolható egy nem frissített szabályzat által. Kérdezze meg az asztali csapatot, melyik mechanizmus hagyja jóvá a kiterjesztést ahhoz a flottához, mielőtt arra kérné a felhasználót, hogy kattintson valamire.

Nem kezelt Macen a jóváhagyási kérés egyszer jelenik meg, és az elutasítás végleges lehet, amíg a kiterjesztést újra nem telepítik. Ez a viselkedés magyarázza azt a gépet, ahol a kliens az operációs rendszer frissítése előtt működött, és most olyan kapcsolatot jelent, amely soha nem jön létre.

Jegyezze fel a szolgáltatótípust, az aktiválási állapotot és a jóváhagyási mechanizmust a telepített klienshez. Ez a három tény megválaszolja a Mac VPN-ről szóló legtöbb jövőbeli kérdést anélkül, hogy újranyitná a képesség kontra szállítás vitát.