Mac VPN-client: Network Extension versus System Extension

Twee Apple-termen worden gebruikt alsof ze hetzelfde benoemen, en die verwarring stuurt mensen naar het verkeerde instellingenpaneel. Network Extension beschrijft een capaciteit: een ondersteunde manier om VPN-tunnels, proxy's en filters te implementeren. System Extensions beschrijft een leverings- en goedkeuringsmechanisme voor uitbreidingen in de gebruikersruimte. Een moderne Mac VPN-client heeft meestal beide nodig, waardoor geen van beide labels alleen een symptoom verklaart. Het scheiden van de twee beantwoordt welke component je moet inspecteren en welke goedkeuringsstap je kunt verwachten.

Twee vragen, niet één label

Vraag wat de component doet voordat je vraagt hoe hij wordt geïnstalleerd. De capaciteit bepaalt welke providerklasse bestaat en dus welke code je pakketten verwerkt. Het leveringsmechanisme bepaalt hoe de binary aankomt, hoe hij wordt goedgekeurd en waar zijn status wordt vastgelegd. Een product kan een pakkettunnel implementeren zonder een systeemextensie te leveren op oudere releases, en het kan een systeemextensie leveren die iets anders dan een tunnel implementeert.

Kernelextensies zijn de derde term die mensen erbij halen. Ze waren de oudere manier om bevoorrechte netwerkcode uit te voeren, ze vereisten andere goedkeuringen, en Apple stuurt ontwikkelaars er al jaren van weg. Een goedkeuringsrecept voor kernelextensies op een moderne client toepassen kost tijd aan een dialoog die nooit verschijnt.

Lees de implementatienotities van de leverancier voor de macOS-versie die je gebruikt in plaats van een forumpost uit een eerdere release. De architectuur veranderde meer dan eens, en instructies verouderen snel. Een notitie die goedkeuring van kernelextensies noemt, beschrijft een ander tijdperk van het product.

Wat Network Extension biedt

Het framework biedt providertypes voor de gebruikelijke netwerktaken: een pakkettunnel voor VPN-verkeer, een app-proxy voor stromen per toepassing, een inhoudsfilter om verkeer te inspecteren en DNS-proxyafhandeling voor het gedrag van de resolver. Het providertype bepaalt wat de extensie kan doen, en een client die twee providers levert, kan twee verschillende taken uitvoeren.

Dat maakt uit bij diagnose omdat hetzelfde connectiviteitssymptoom van een tunnel, een filter of een DNS-proxy kan komen. Een website blokkeren is een filterbeslissing, een privé-subnet niet bereiken is meestal een tunnelbeslissing, en het verkeerde adres oplossen is meestal een resolverbeslissing. Het providertype benoemen vernauwt de zoektocht voordat er een logboek wordt gelezen.

Niets aan het framework impliceert een privacyhouding. Een extensie in de gebruikersruimte heeft nog steeds machtigingen, configuratie en een operator erachter, dus behandel de architectuur als een implementatiedetail en niet als een vertrouwenssignaal. Vraag wie het eindpunt beheert en wat het is geconfigureerd om te verzamelen.

Wat System Extensions verandert

Het mechanisme verplaatst bevoorrechte code uit de kernel naar de gebruikersruimte, en het verandert hoe het besturingssysteem om toestemming vraagt. Activering is een aparte stap van installatie, en de gebruiker of een MDM-profiel moet die toestaan. Een client die installeert maar nooit activeert lijkt aanwezig in de map Applications en doet niets voor de connectiviteit.

De status wordt door het systeem vastgelegd en niet door de app, wat handig is omdat erom gevraagd kan worden. De opdracht hieronder somt de extensies op die het systeem kent en hun activeringsstatus.

systemextensionsctl list
scutil --nc list

De eerste opdracht beantwoordt of de component is geïnstalleerd en geactiveerd. De tweede somt de VPN-configuraties op die het systeem heeft, wat een andere vraag is en vaak degene die ertoe doet wanneer een verbindingsprofiel ontbreekt in plaats van stuk is.

Welke je moet inspecteren voor een bepaald symptoom

Koppel het symptoom aan de laag voordat je een instellingenpaneel opent. Een ontbrekende configuratie is een profielvraag, een geïnstalleerde maar inactieve component is een leveringsvraag, en een actieve component die geen verkeer doorlaat is een capaciteitsvraag.

De logstroom is het gedeelde bewijs voor de laatste twee rijen. Het lezen van het subsysteem voor netwerkextensies vertelt welke provider de stroom heeft verwerkt, en een filterbeslissing ziet er anders uit dan een tunnelfout, zelfs wanneer de gebruiker beide als kapotte VPN beschrijft.

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

Concludeer niet dat een extensie actief is omdat er een pictogram in de menubalk staat. Pictogrammen overleven mislukte activeringen, en een verouderd pictogram is een van de meest voorkomende redenen waarom een supportoproep op de verkeerde plek begint. Lees in plaats daarvan de activeringsstatus, want dat is wat het systeem vastlegt.

Goedkeuring, MDM en de mythe van de kernelextensie

Op beheerde Macs hoort de goedkeuringsstap bij het MDM-profiel, en een gebruiker die in System Settings op Allow klikt, kan nog steeds worden geblokkeerd door een beleid dat niet is bijgewerkt. Vraag het desktopteam welk mechanisme de extensie voor die vloot goedkeurt voordat je de gebruiker vraagt ergens op te klikken.

Op een niet-beheerde Mac verschijnt de goedkeuringsprompt één keer en een afwijzing kan permanent zijn tot de extensie opnieuw wordt geïnstalleerd. Dat gedrag verklaart de machine waarop de client werkte vóór een OS-upgrade en nu een verbinding meldt die nooit tot stand komt.

Noteer het providertype, de activeringsstatus en het goedkeuringsmechanisme voor de client die je uitrolt. Die drie feiten beantwoorden de meeste toekomstige vragen over een Mac VPN zonder de discussie capaciteit tegenover levering opnieuw te openen.