Mac-VPN blijft hangen op 'Verbreken': wat er werkelijk draait

'Verbreken' is een toestand die de client meldt terwijl hij een tunnel afbreekt, geen oordeel dat het verkeer is gestopt. Op een Mac verloopt dat afbreken als een korte reeks, en het label verandert pas nadat de component die de verbinding bezit terugmeldt. Wanneer een stap wacht op een hulpprogramma, een plug-in of een beleidsbeslissing, kan het label blijven staan nadat de interface weg is, of kan de tunnel blijven doorsturen terwijl het menu hem nog toont. Behandel de tekst als 'afbreken gaande, uitkomst onbekend' en zoek uit welke helft waar is.

Twee storingen zien er in de menubalk hetzelfde uit en vragen tegengestelde reacties. Bij de ene draagt de tunnel nog pakketten en is alleen de weergave verouderd. Bij de andere is de tunnel weg, maar houdt een apart beleid het verkeer geblokkeerd, wat vaak opzettelijk is. Routes en DNS-status scheiden ze sneller dan welke menuactie dan ook.

Wat het label volgt

Een VPN-client houdt een kleine toestandsmachine bij, en de menubalk is daarvan een projectie. Voor een verbinding die macOS zelf beheert, zit die machine in het systeem-VPN-framework. Voor een door een app beheerde tunnel zit hij in de app en haar bevoorrechte helper. De laatste stap van een stop is niet het sluiten van een socket. Het is het vrijgeven van wat de tunnel liet werken: de utun-interface, de routes die erheen wezen, de resolver-vermeldingen die de client invoegde, en elke firewallregel of elk beleid dat verkeer blokkeerde terwijl de verbinding actief was.

Die stappen zijn afzonderlijk, dus een stop kan op elk daarvan blijven hangen. Een helper die niet meer antwoordt, een route waar ook een tweede interface aanspraak op maakt, of een resolver-vermelding die een ander profiel bezit, kunnen de client laten wachten. Het label is een verslag over de voortgang van de client zelf, wat het gezaghebbend maakt over de bedoeling en onbetrouwbaar over het netwerk.

Vind de component die de verbinding bezit

Bij native configuraties drukt scutil --nc list de diensten af die het systeem kent en hun status, en scutil --nc status "Work VPN" geeft details over één dienst. Een tunnel die door een app van derden wordt vastgehouden, staat misschien helemaal niet in die lijst, dus een leeg resultaat is geen bewijs dat er niets is verbonden.

Hoort het profiel bij een app, vertrouw dan op de statusweergave en de gedocumenteerde knop 'Verbreken'. Het venster sluiten is geen stopverzoek als een achtergrondhelper de tunnel bezit; het pictogram verdwijnt en de helper houdt de interface in leven. Apples naslag over VPN-instellingen behandelt de native bedieningselementen en waar beheerde instellingen vandaan komen.

Lees interfaces, routes en DNS

Drie controles beantwoorden het grootste deel van de vraag zonder de verbinding aan te raken. Ze samen interpreteren is wat telt, want elk afzonderlijk misleidt.

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

• utun-interface aanwezig, standaard- of gesplitste route erdoorheen, resolver wijst naar de provider: de tunnel staat nog en het label is verouderd.
• geen utun, gewone standaardroute, DNS via DHCP, geen internet: een beleid dat blokkeert bij verbreken doet zijn werk.
• geen utun, geen route, resolver wijst nog naar de provider: het afbreken stopte halverwege, en DNS is de rest die opgeruimd moet worden.

Stuur dan één verzoek naar een interne host die alleen via de tunnel zou moeten antwoorden en één naar een openbare host. Bereikbaarheid scheidt beleid van resttoestand zonder de controle in een meetoefening te veranderen. Sla eerst extern werk op als het pad nog antwoordt, en zorg voor een tweede toegang voordat je netwerk wijzigt op een machine die je op afstand beheert.

Waarom breed doden en profielverwijdering misleiden

Procesnamen zoals pppd, racoon en configd horen bij bepaalde implementaties. Ze doden kan andere verbindingen raken, laat routes en utun-interfaces achter en geeft je geen verslag van welke stap vastliep. Een oude procesnaam is ook geen bewijs dat hij het huidige profiel bezit.

Het profiel verwijderen en opnieuw aanmaken is een grotere wijziging dan het opruimen van een vastgelopen overgang. Het kan beheerde instellingen en lokaal identiteitsmateriaal weggooien zonder te verklaren wat er misging, en op een Mac onder toezicht wordt het misschien gewoon hersteld. Bewaar verwijderen voor een configuratie die echt verouderd is en diagnostiseer in plaats daarvan de overgang.

Een stopreeks die een spoor achterlaat

De volgorde hieronder laat de eigen bediening van de verbinding verantwoordelijk en levert een verslag op als het vastlopen terugkomt. Het voorkomt ook dat je een weergaveprobleem in een netwerkwijziging verandert.

1. Sla extern werk op, en bevestig dat je de Mac op een andere manier bereikt als hij op afstand staat.
2. Noteer de naam van de client, de versie en het profiel. Leg een kort venster vast met log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; oudere releases bewaren minder geschiedenis, dus voer dit snel na het vastlopen uit.
3. Gebruik de gedocumenteerde knop 'Verbreken', wacht en herhaal daarna de interface- en routecontroles.
4. Als het label verouderd is maar de tunnel ligt, laat het staan en laat de client verversen in plaats van processen te forceren.
5. Als het afbreken echt vastliep, herstart de client en plan daarna een herstart van de Mac zodra werk is opgeslagen. Beheerde machines vereisen de procedure van de beheerder.

Bevestig na het herstel dat de gewone standaardroute en de DHCP-resolver terug zijn, en dat geblokkeerd verkeer ofwel is hersteld ofwel opzettelijk nog geblokkeerd is. Noteer het profiel en de clientversie bij het symptoom, zodat de volgende keer begint met bewijs in plaats van een gok uit de menubalk.