Mac VPN-klient: Network Extension kontra System Extension
Network Extension er ei evne og System Extensions ein leveringsmekanisme: skil dei for å velje macOS-godkjenningstrinnet og loggen du les.
To Apple-omgrep vert brukte som om dei namngjev det same, og denne forvirringa sender folk til feil innstillingspanel. Network Extension skildrar ei evne: ein støtta måte å implementere VPN-tunnelar, proxyar og filter på. System Extensions skildrar ein leverings- og godkjenningsmekanisme for utvidingar i brukarrommet. Ein moderne Mac VPN-klient treng vanlegvis begge, og difor forklarer ingen av etikettene åleine eit symptom. Å skilje dei to svarar på kva komponent som skal undersøkjast og kva godkjenningstrinn som kan ventast.
To spørsmål, ikkje éi etikett
Spør kva komponenten gjer før du spør korleis han blir installert. Evna avgjer kva leverandørklasse som finst og dermed kva kode som handterer pakkane dine. Leveringsmekanismen avgjer korleis binæren kjem, korleis han blir godkjend og kvar tilstanden blir registrert. Eit produkt kan implementere ein pakketunnel utan å levere ei systemutviding på eldre versjonar, og det kan levere ei systemutviding som implementerer noko anna enn ein tunnel.
Kjerneutvidingar er det tredje uttrykket folk blandar inn. Dei var den eldre måten å køyre privilegert nettverkskode på, dei kravde andre godkjenningar, og Apple har i årevis styrt utviklarar bort frå dei. Å bruke ein oppskrift for godkjenning av kjerneutvidingar på ein moderne klient kastar bort tid på ein dialog som aldri blir vist.
Les distribusjonsnotata frå leverandøren for macOS-versjonen du køyrer i staden for eit foruminnlegg frå ein tidlegare versjon. Arkitekturen endra seg meir enn éin gong, og instruksjonane blir fort utdaterte. Eit notat som nemner godkjenning av kjerneutvidingar, skildrar ein annan æra av produktet.
Kva Network Extension tilbyr
Rammeverket tilbyr leverandørtypar for dei vanlege nettverksoppgåvene: ein pakketunnel for VPN-trafikk, ein app-proxy for straumar per applikasjon, eit innhaldsfilter for å inspisere trafikk og DNS-proxyhandtering for åtferda til resolvaren. Leverandørtypen avgjer kva utvidinga kan gjere, og ein klient som leverer to leverandørar, kan utføre to ulike jobbar.
Det betyr noko under diagnostikk fordi det same tilkoplingssymptomet kan kome frå ein tunnel, eit filter eller ein DNS-proxy. Å blokkere eit nettstad er ei filteravgjerd, å ikkje nå eit privat subnett er vanlegvis ei tunellavgjerd, og å løyse feil adresse er vanlegvis ei resolveravgjerd. Å namngje leverandørtypen snevrar inn søket før nokon logg blir lesen.
Ingenting i rammeverket antydar ei personvernhaldning. Ei utviding i brukarrommet har framleis løyve, konfigurasjon og ein operatør bak seg, så handsam arkitekturen som ein implementasjonsdetalj og ikkje som eit tillitssignal. Spør kven som driv endepunktet og kva det er konfigurert til å samle inn.
Kva System Extensions endrar
Mekanismen flyttar privilegert kode ut av kjernen og inn i brukarrommet, og han endrar korleis operativsystemet ber om samtykke. Aktivering er eit eige trinn frå installasjon, og brukaren eller ein MDM-profil må tillate det. Ein klient som blir installert, men aldri aktivert ser ut til å vere i mappa Applications og gjer ingenting for tilkoplinga.
Tilstanden blir registrert av systemet og ikkje av appen, noko som er nyttig fordi han kan spørjast. Kommandoen nedanfor viser utvidingane systemet kjenner og aktiveringstilstanden deira.
systemextensionsctl list
scutil --nc list
Den første kommandoen svarar på om komponenten er installert og aktivert. Den andre viser VPN-konfigurasjonane systemet har, noko som er eit anna spørsmål og ofte det som betyr noko når ein tilkoplingsprofil manglar i staden for å vere øydelagd.
Kva for ein som skal undersøkjast for eit gitt symptom
Kopla symptomet til laget før du opnar eit innstillingspanel. Ein manglande konfigurasjon er eit profilspørsmål, ein installert men inaktiv komponent er eit leveringsspørsmål, og ein aktiv komponent som ikkje slepp trafikken gjennom, er eit evnespørsmål.
| 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 |
Loggstraumen er det felles beviset for dei to siste radene. Å lese nettverksutvidings-delsystemet fortel kva leverandør som handterte straumen, og ei filteravgjerd ser annleis ut enn ein tunellfeil sjølv når brukaren skildrar begge som øydelagd VPN.
log show --last 10m --predicate 'process == "nesessionmanager"'
Ikkje konkluder med at ei utviding er aktiv fordi det finst eit ikon i menylinja. Ikon overlever mislukka aktiveringar, og eit utdatert ikon er ein av dei vanlegaste årsakene til at ein supporthenvending startar på feil stad. Les aktiveringstilstanden i staden, fordi det er den systemet registrerer.
Godkjenning, MDM og myten om kjerneutvidingar
På styrte Mac-ar høyrer godkjenningstrinnet til MDM-profilen, og ein brukar som klikkar Allow i System Settings kan framleis bli blokkert av ein policy som ikkje er oppdatert. Spør skrivebordsteamet kva mekanisme som godkjenner utvidinga for den flåten, før du ber brukaren klikke på noko.
På ein ikkje-styrt Mac blir godkjenningsførespurnaden vist éin gong, og ein avvising kan vere permanent til utvidinga blir installert på nytt. Den åtferda forklarer maskinen der klienten fungerte før ein OS-oppgradering og no rapporterer ei tilkopling som aldri blir etablert.
Skriv ned leverandørtypen, aktiveringstilstanden og godkjenningsmekanismen for klienten du distribuerer. Desse tre fakta svarar på dei fleste framtidige spørsmål om ein Mac VPN utan å opne debatten om evne kontra levering på nytt.