Mac VPN hou vas op Ontkoppel: wat eintlik aan die gang is

“Ontkoppel” is 'n toestand wat die kliënt rapporteer terwyl dit 'n tonnel afbreek, nie 'n uitspraak dat verkeer gestop het nie. Op 'n Mac verloop daardie afbreek as 'n kort reeks, en die etiket verander eers nadat die komponent wat die verbinding besit terugrapporteer. Wanneer een stap op 'n helper, 'n inprop of 'n beleidsbeslissing wag, kan die etiket daar bly nadat die koppelvlak weg is, of die tonnel kan aanhou deurstuur terwyl die kieslys dit nog wys. Behandel die teks as “afbreek aan die gang, uitkoms onbekend” en bepaal watter helfte waar is.

Twee foute lyk dieselfde vanaf die kieslysbalk en verg teenoorgestelde reaksies. In die een dra die tonnel nog pakkette en is net die vertoning verouderd. In die ander is die tonnel weg, maar hou 'n aparte beleid verkeer geblokkeer, wat dikwels doelbewus is. Roetes en DNS-toestand skei hulle vinniger as enige kieslysinteraksie.

Waaroor die etiket gaan

'n VPN-kliënt hou 'n klein toestandmasjien by, en die kieslysbalk is 'n projeksie daarvan. Vir 'n verbinding wat macOS self bestuur, sit daardie masjien in die stelsel se VPN-raamwerk. Vir 'n tonnel wat deur 'n app bestuur word, sit dit in die app en sy bevoorregte helper. Die laaste stap van 'n stop is nie om 'n sok te sluit nie. Dit is om vry te laat wat die tonnel laat werk het: die utun-koppelvlak, die roetes wat daarheen gewys het, die resolveerder-inskrywings wat die kliënt ingespan het, en enige firewall-reël of beleid wat verkeer geblokkeer het terwyl daar verbind was.

Daardie stappe is apart, so 'n stop kan op enige een daarvan vashaak. 'n Helper wat ophou antwoord, 'n roete wat 'n tweede koppelvlak ook opeis, of 'n resolveerder-inskrywing wat 'n ander profiel besit, kan almal die kliënt laat wag. Die etiket is 'n verslag oor die kliënt se eie vordering, wat dit gesaghebbend maak oor die bedoeling en onbetroubaar oor die netwerk.

Vind die komponent wat die verbinding besit

Vir inheemse konfigurasies druk scutil --nc list die dienste wat die stelsel ken en hulle status uit, en scutil --nc status "Work VPN" gee besonderhede vir een diens. 'n Tonnel wat deur 'n derdeparty-app gehou word, verskyn dalk glad nie in daardie lys nie, so 'n leë resultaat is nie bewys dat niks verbind is nie.

Wanneer die profiel aan 'n app behoort, vertrou op daardie app se statusaansig en sy gedokumenteerde Ontkoppel-beheer. Om die venster te sluit is nie 'n stopversoek as 'n agtergrondhelper die tonnel besit nie; die ikoon verdwyn en die helper hou die koppelvlak lewendig. Apple se VPN-instellingsverwysing dek die inheemse beheers en waar bestuurde instellings vandaan kom.

Lees koppelvlakke, roetes en DNS

Drie kontroles beantwoord die meeste van die vraag sonder om aan die verbinding te raak. Dit is belangrik om hulle saam te interpreteer, want enige een alleen is misleidend.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30

• utun-koppelvlak teenwoordig, verstek- of gesplete roete daardeur, resolveerder wat na die verskaffer wys: die tonnel is nog op en die etiket is verouderd.
• Geen utun, gewone verstekroete, DNS van DHCP, geen internet: 'n beleid wat verkeer blokkeer terwyl daar ontkoppel is, doen sy werk.
• Geen utun, geen roete, resolveerder wys nog na die verskaffer: die afbreek het halfpad gestop, en DNS is die oorblyfsel om skoon te maak.

Stuur dan een versoek na 'n interne gasheer wat net deur die tonnel behoort te antwoord en een na 'n openbare gasheer. Bereikbaarheid skei beleid van oorblywende toestand sonder om die kontrole in 'n meetoefening te verander. Stoor eers afgeleide werk as die pad nog reageer, en reël 'n tweede toegang voordat jy netwerkinstellings verander op 'n masjien wat jy op afstand bestuur.

Waarom breë doodmaak en profielverwydering mislei

Prosesname soos pppd, racoon en configd behoort aan bepaalde implementasies. Om hulle dood te maak kan ander verbindings raak, laat roetes en utun-koppelvlakke agter en gee jou geen rekord van watter stap vasgehaak het nie. 'n Ou prosesnaam is ook nie bewys dat dit die huidige profiel besit nie.

Om die profiel te verwyder en weer te skep is 'n groter verandering as om 'n vasgehaakte oorgang skoon te maak. Dit kan bestuurde instellings en plaaslike identiteitsmateriaal weggooi sonder om te verduidelik wat misluk het, en op 'n Mac onder toesig word dit dalk bloot herstel. Hou verwydering vir 'n konfigurasie wat werklik verouderd is en diagnoseer eerder die oorgang.

'n Stopreeks wat 'n spoor los

Die volgorde hieronder laat die verbinding se eie beheers in beheer en lewer 'n rekord as die vasdraai terugkeer. Dit verhoed ook dat jy 'n vertoonprobleem in 'n netwerkverandering omskep.

1. Stoor afgeleide werk, en bevestig dat jy die Mac op 'n ander manier kan bereik as dit op afstand is.
2. Noteer die kliënt se naam, weergawe en profiel. Vang 'n kort tydvenster met log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; ouer weergawes hou minder geskiedenis, so hardloop dit gou nadat die vasdraai plaasgevind het.
3. Gebruik die gedokumenteerde Ontkoppel-beheer, wag, en herhaal dan die koppelvlak- en roetekontroles.
4. As die etiket verouderd is maar die tonnel is af, laat dit staan en laat die kliënt verfris eerder as om prosesse te dwing.
5. As die afbreek werklik vasgehaak het, herbegin die kliënt en beplan dan 'n herbegin van die Mac sodra werk gestoor is. Bestuurde masjiene vereis die administrateur se prosedure.

Bevestig ná herstel dat die gewone verstekroete en DHCP-resolveerder terug is, en dat geblokkeerde verkeer óf herstel is óf doelbewus steeds geblokkeer word. Teken die profiel en kliëntweergawe saam met die simptoom aan, sodat die volgende geval by bewyse begin eerder as by 'n raaiskoot uit die kieslysbalk.