Mac VPN-klient: Network Extension kontra System Extension
Network Extension er en evne, og System Extensions er en leveringsmekanisme: adskil dem for at vælge macOS-godkendelsestrinet og den log, du skal læse.
To Apple-termer bruges, som om de navngiver det samme, og den forvirring sender folk til den forkerte indstillingsrude. Network Extension beskriver en evne: en understøttet måde at implementere VPN-tunneler, proxyer og filtre på. System Extensions beskriver en leverings- og godkendelsesmekanisme for udvidelser i brugerrummet. En moderne Mac VPN-klient har normalt brug for begge, og derfor forklarer ingen af etiketterne alene et symptom. At adskille de to svarer på, hvilken komponent der skal undersøges, og hvilket godkendelsestrin der kan forventes.
To spørgsmål, ikke én etiket
Spørg, hvad komponenten gør, før du spørger, hvordan den installeres. Evnen afgør, hvilken udbyderklasse der findes, og dermed hvilken kode der håndterer dine pakker. Leveringsmekanismen afgør, hvordan binæren ankommer, hvordan den godkendes, og hvor dens tilstand registreres. Et produkt kan implementere en pakketunnel uden at levere en systemudvidelse på ældre versioner, og det kan levere en systemudvidelse, der implementerer noget andet end en tunnel.
Kerneudvidelser er det tredje udtryk, folk blander ind. De var den ældre måde at køre privilegeret netværkskode på, de krævede andre godkendelser, og Apple har i årevis styret udviklere væk fra dem. At anvende en opskrift til godkendelse af kerneudvidelser på en moderne klient spilder tid på en dialog, der aldrig vises.
Læs leverandørens udrulningsnotater for den macOS-version, du kører i stedet for et forumindlæg fra en tidligere version. Arkitekturen ændrede sig mere end én gang, og instruktioner ældes hurtigt. Et notat, der nævner godkendelse af kerneudvidelser, beskriver en anden æra af produktet.
Hvad Network Extension tilbyder
Rammen leverer udbydertyper til de almindelige netværksopgaver: en pakketunnel til VPN-trafik, en app-proxy til strømme per applikation, et indholdsfilter til at inspicere trafik og DNS-proxyhåndtering til resolveradfærd. Udbydertypen bestemmer, hvad udvidelsen kan gøre, og en klient, der leverer to udbydere, kan udføre to forskellige opgaver.
Det betyder noget under diagnostik, fordi det samme forbindelsessymptom kan komme fra en tunnel, et filter eller en DNS-proxy. Blokering af et websted er en filterbeslutning, manglende adgang til et privat subnet er normalt en tunnelbeslutning, og opløsning af den forkerte adresse er normalt en resolverbeslutning. At navngive udbydertypen indsnævrer søgningen, før nogen log læses.
Intet i rammen antyder en holdning til privatliv. En udvidelse i brugerrummet har stadig tilladelser, konfiguration og en operatør bag sig, så behandl arkitekturen som en implementeringsdetalje frem for et tillidssignal. Spørg, hvem der driver slutpunktet, og hvad det er konfigureret til at indsamle.
Hvad System Extensions ændrer
Mekanismen flytter privilegeret kode ud af kernen og ind i brugerrummet, og den ændrer, hvordan operativsystemet beder om samtykke. Aktivering er et separat trin fra installation, og brugeren eller en MDM-profil skal tillade det. En klient, der installeres, men aldrig aktiveres ser til stede ud i mappen Applications og gør intet for forbindelsen.
Tilstanden registreres af systemet i stedet for appen, hvilket er nyttigt, fordi den kan forespørges. Kommandoen nedenfor viser de udvidelser, systemet kender, og deres aktiveringstilstand.
systemextensionsctl list
scutil --nc list
Den første kommando svarer på, om komponenten er installeret og aktiveret. Den anden viser de VPN-konfigurationer, systemet har, hvilket er et andet spørgsmål og ofte det, der betyder noget, når en forbindelsesprofil mangler i stedet for at være i stykker.
Hvilken skal undersøges for et givet symptom
Match symptomet med laget, før du åbner en indstillingsrude. En manglende konfiguration er et profilspørgsmål, en installeret men inaktiv komponent er et leveringsspørgsmål, og en aktiv komponent, der ikke kan føre trafik, er et evnespørgsmå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 |
Logstrømmen er det fælles bevis for de sidste to rækker. Læsning af netværksudvidelses-subsystemet fortæller, hvilken udbyder der håndterede strømmen, og en filterbeslutning ser anderledes ud end en tunnelfejl, selv når brugeren beskriver begge som VPN'et, der er i stykker.
log show --last 10m --predicate 'process == "nesessionmanager"'
Konkluder ikke, at en udvidelse er aktiv, fordi der er et ikon i menulinjen. Ikoner overlever mislykkede aktiveringer, og et forældet ikon er en af de mest almindelige årsager til, at et supportopkald starter det forkerte sted. Læs i stedet aktiveringstilstanden, fordi det er den, systemet registrerer.
Godkendelse, MDM og myten om kerneudvidelser
På administrerede Macs tilhører godkendelsestrinet MDM-profilen, og en bruger, der klikker Allow i System Settings, kan stadig blive blokeret af en politik, der ikke er opdateret. Spørg desktop-teamet, hvilken mekanisme der godkender udvidelsen for den flåde, før du beder brugeren om at klikke på noget.
På en ikke-administreret Mac vises godkendelsesprompten én gang, og en afvisning kan være permanent, indtil udvidelsen geninstalleres. Den adfærd forklarer maskinen, hvor klienten virkede før en OS-opgradering og nu rapporterer en forbindelse, der aldrig etableres.
Skriv udbydertypen, aktiveringstilstanden og godkendelsesmekanismen ned for den klient, du udruller. De tre fakta besvarer de fleste fremtidige spørgsmål om en Mac VPN uden at genåbne diskussionen om evne kontra levering.