Mac VPN klientas: Network Extension prieš System Extension
Network Extension yra galimybė, o System Extensions – pristatymo mechanizmas: atskirkite juos, kad pasirinktumėte macOS patvirtinimo veiksmą ir skaitomą žurnalą.
Du „Apple“ terminai vartojami taip, lyg įvardytų tą patį dalyką, ir ši painiava nukreipia žmones į netinkamą nustatymų skydelį. Network Extension apibūdina galimybę: palaikomą būdą įgyvendinti VPN tunelius, tarpinius serverius ir filtrus. System Extensions apibūdina vartotojo erdvės plėtinių pristatymo ir patvirtinimo mechanizmą. Šiuolaikiniam Mac VPN klientui paprastai reikia abiejų, todėl nė viena žymė viena nepaaiškina simptomo. Atskyrus abu, atsakoma, kurį komponentą tikrinti ir kokio patvirtinimo veiksmo tikėtis.
Du klausimai, o ne viena žymė
Klauskite, ką komponentas daro, prieš klausdami, kaip jis įdiegiamas. Galimybė nulemia, kuri tiekėjo klasė egzistuoja ir todėl kuris kodas apdoroja jūsų paketus. Pristatymo mechanizmas nulemia, kaip atvyksta dvejetainis failas, kaip jis patvirtinamas ir kur įrašoma jo būsena. Produktas gali įgyvendinti paketų tunelį nepristatydamas sistemos plėtinio senesnėse versijose, ir gali pristatyti sistemos plėtinį, įgyvendinantį ką nors kita nei tunelis.
Branduolio plėtiniai yra trečiasis terminas, kurį žmonės sumaišo. Jie buvo senesnis būdas vykdyti privilegijuotą tinklo kodą, reikalavo kitokių patvirtinimų, ir „Apple“ jau metus nukreipia kūrėjus nuo jų. Branduolio plėtinio patvirtinimo recepto taikymas šiuolaikiniam klientui eikvoja laiką dialogui, kuris niekada nepasirodys.
Perskaitykite tiekėjo diegimo pastabas apie jūsų naudojamą macOS versiją vietoj ankstesnės versijos forumo įrašo. Architektūra pasikeitė ne vieną kartą, o instrukcijos greitai pasensta. Pastaba, minima branduolio plėtinio patvirtinimą, apibūdina kitą produkto erą.
Ką suteikia Network Extension
Sistema teikia tiekėjo tipus įprastiems tinklo darbams: paketų tunelį VPN srautui, programos tarpinį serverį srautams pagal programą, turinio filtrą srautui tikrinti ir DNS tarpinio serverio tvarkymą sprendėjo elgsenai. Tiekėjo tipas nulemia, ką plėtinys gali daryti, o klientas, pristatantis du tiekėjus, gali atlikti du skirtingus darbus.
Tai svarbu diagnozuojant, nes tas pats ryšio simptomas gali kilti iš tunelio, filtro ar DNS tarpinio serverio. Svetainės blokavimas yra filtro sprendimas, nepasiekimas privataus potinklio paprastai yra tunelio sprendimas, o neteisingo adreso sprendimas paprastai yra sprendėjo sprendimas. Tiekėjo tipo įvardijimas susiaurina paiešką prieš skaitant bet kokį žurnalą.
Niekas sistemoje nereiškia privatumo pozicijos. Vartotojo erdvės plėtinys vis dar turi leidimus, konfigūraciją ir operatorių už jo, todėl architektūrą traktuokite kaip įgyvendinimo detalę, o ne pasitikėjimo signalą. Klauskite, kas valdo galinį tašką ir ką jis sukonfigūruotas rinkti.
Ką keičia System Extensions
Mechanizmas perkelia privilegijuotą kodą iš branduolio į vartotojo erdvę ir keičia tai, kaip operacinė sistema prašo sutikimo. Aktyvinimas yra atskiras veiksmas nuo diegimo, ir vartotojas ar MDM profilis turi jam leisti. Klientas, kuris įdiegiamas, bet niekada neaktyvuojamas atrodo esantis aplanke Applications ir nieko nedaro dėl ryšio.
Būseną įrašo sistema, o ne programa, kas naudinga, nes jos galima paklausti. Toliau pateikta komanda išvardija plėtinius, kuriuos sistema žino, ir jų aktyvinimo būseną.
systemextensionsctl list
scutil --nc list
Pirmoji komanda atsako, ar komponentas įdiegtas ir aktyvuotas. Antroji išvardija VPN konfigūracijas, kurias sistema laiko, o tai yra kitas klausimas ir dažnai tas, kuris svarbus, kai ryšio profilio trūksta, o ne jis sugedęs.
Kurį tikrinti dėl konkretaus simptomo
Suderinkite simptomą su sluoksniu prieš atidarydami nustatymų skydelį. Trūkstama konfigūracija yra profilio klausimas, įdiegtas bet neaktyvus komponentas yra pristatymo klausimas, o aktyvus komponentas, kuris nepraleidžia srauto, yra galimybės klausimas.
| Symptom | First place to look |
|---|---|
| No VPN entry at all | Configuration profile or scutil list |
| Client installed, nothing happens | Extension activation state |
| Tunnel up, private host unreachable | Tunnel provider routes and policy |
| One app blocked, others fine | Filter or app proxy provider |
Žurnalo srautas yra bendras įrodymas dviem paskutinėms eilutėms. Tinklo plėtinio posistemio skaitymas pasako, kuris tiekėjas apdorojo srautą, o filtro sprendimas atrodo kitaip nei tunelio gedimas, net kai vartotojas abu apibūdina kaip sugedusį VPN.
log show --last 10m --predicate 'process == "nesessionmanager"'
Nedarykite išvados, kad plėtinys aktyvus, nes meniu juostoje yra piktograma. Piktogramos išlieka po nepavykusių aktyvinimų, o pasenusi piktograma yra viena dažniausių priežasčių, kodėl palaikymo skambutis prasideda ne ten. Verčiau skaitykite aktyvinimo būseną, nes tai sistema įrašo.
Patvirtinimas, MDM ir branduolio plėtinio mitas
Valdomuose Mac kompiuteriuose patvirtinimo veiksmas priklauso MDM profiliui, o vartotojas, paspaudęs Allow sistemoje System Settings, vis tiek gali būti blokuojamas neatnaujintos politikos. Paklauskite darbalaukio komandos, kuris mechanizmas patvirtina plėtinį tam parkui, prieš prašydami vartotojo ką nors spustelėti.
Nevaldomame Mac patvirtinimo užklausa pasirodo vieną kartą, o atmetimas gali būti nuolatinis, kol plėtinys nebus įdiegtas iš naujo. Toks elgesys paaiškina mašiną, kurioje klientas veikė prieš OS atnaujinimą, o dabar praneša apie ryšį, kuris niekada neužmezgamas.
Užsirašykite tiekėjo tipą, aktyvinimo būseną ir patvirtinimo mechanizmą diegiamam klientui. Šie trys faktai atsako į daugumą būsimų klausimų apie Mac VPN ne vėl atidarant galimybės prieš pristatymą ginčą.