De Mac afsluiten na het VPN-werk, niet ervoor

Twee mensen sluiten na het werk dezelfde Mac af en krijgen verschillende resultaten. De een verliest een upload die voor negentig procent klaar was; de ander klapt twintig seconden later de klep dicht met alles weggeschreven. Het verschil is geen geluk of schijfsnelheid. Het zit in de volgorde waarin ze de privésessie, de share en de tunnel sluiten, en of iets op die stappen wacht.

De vergelijking hieronder gaat tussen ‘tunnel eerst’ en ‘werk eerst’, want die ene keuze verklaart de meeste slechte uitkomsten.

Twee afsluitorders, twee uitkomsten

Tunnel eerst ziet er netjes uit: het VPN-menu zegt Verbinding verbreken, het pictogram verdwijnt en dan sluit de gebruiker documenten en zet de Mac uit. Het probleem is dat het verbreken de routes en de gekoppelde share kan weghalen voordat de toepassing klaar is met schrijven, en een upload die onderweg is nergens meer heen kan. De gebruiker ziet een schone verbreking en neemt aan dat de rest veilig is. Een pictogram dat verdwijnt zegt niets over of de toepassing klaar is. Het afsluiten gaat daarna gewoon door over een netwerkpad dat het verkeer dat de toepassing nodig had niet meer draagt.

Werk eerst is een paar seconden langzamer en veel rustiger. De privébewerking rondt af, de share wordt bewust ontkoppeld en pas dan gaat de tunnel weg. Het afsluiten dat volgt heeft niets meer te onderbreken.

Waarom de share weg moet voor de tunnel

Een gekoppelde netwerkshare is een levende afhankelijkheid, geen map. De client houdt handles open, de server volgt leases en een schrijfactie die nog in de wachtrij staat hoort bij die sessie. De tunnel eronder wegrukken levert de klassieke verouderde mount op: de Finder toont de share, elke toegang hangt en het enige middel is geforceerd ontkoppelen en soms uitloggen.

Ontkoppel via de ondersteunde actie nadat de bestandsactiviteit is gestopt. Op macOS is dat het uitwerpbesturingselement in de Finder of een bewuste diskutil unmount voor het koppelpunt, geen verbreking van het onderliggende netwerk. Bevestig daarna in de zijbalk dat de share weg is voordat je de VPN aanraakt.

Als de share weigert te ontkoppelen, houdt iets nog een bestand open. Zoek het, sluit het en probeer opnieuw. Een weigering is informatie; geforceerd ontkoppelen maakt er gegevensverlies van.

Stop de client die de sessie bezit

Een VPN-sessie heeft een eigenaar, en alleen die eigenaar kan hem netjes stoppen. Tunnelblick-verbindingen stoppen via Tunnelblick. Een native configuratie stopt via de besturing van het systeem zelf of via de app die hem beheert. Een aparte OpenVPN-binary tegen een profiel met een vergelijkbare naam draaien stopt de door de app beheerde sessie niet en kan twee processen achterlaten die het oneens zijn over wie het tunnelapparaat bezit.

Let op automatisch herstel. Een On Demand-regel of een beheerd profiel kan de verbinding seconden na een bewuste stop opnieuw starten, wat lijkt alsof de client het commando negeert. Dat gedrag is beleid, geen bug, en het moet worden opgelost met wie het beleid bezit in plaats van te worden bevochten met een helper die blijft verbreken.

Sommige clients scheiden ‘verbreking aangevraagd’ van ‘afbouw voltooid’. Als de workflow op voltooiing wacht, lees de eigen status van de client en geef hem een begrensde termijn. Een willekeurige slaap van één seconde is geen wachttijd, en elk proces met een VPN-achtige naam doden is geen afbouw.

Laat het afsluiten van het besturingssysteem met rust

De laatste stap moet een gewone afsluiting zijn: Apple-menu, sneltoets of een geplande shutdown-opdracht. Dat pad laat toepassingen opslaan, vraagt de gebruiker naar niet-opgeslagen werk en ontkoppelt volumes in de verwachte volgorde. Het is ook het pad waarvan fouten zo worden gemeld dat iemand ze kan debuggen.

Geforceerd uitzetten slaat dat allemaal over. Het is het juiste gereedschap als de machine echt vastzit, en het verkeerde gereedschap als routinemiddel om een deadline te halen. Een geforceerde afsluiting die een upload weggooit is niet sneller dan wachten; het verplaatst de kosten alleen naar de volgende ochtend.

Apples richtlijnen voor afsluiten trekken die grens en beschrijven het geforceerde geval apart. Lees ze als een reden om de volgorde te repareren, niet als toestemming om geforceerd stoppen deel van de dagelijkse routine te maken.

Bouw de deadline in het plan in

Als de Mac op een vast tijdstip uit moet zijn, begin de voorbereiding terwijl de gebruikerssessie nog leeft. Tot de laatste minuut wachten met opruimen is hoe een MFA-vraag, een onvoltooide schrijfactie of een koppige mount een incident wordt. Geef de reeks een begintijd, niet alleen een eindtijd.

Bepaal wat er gebeurt als een stap zijn budget overschrijdt. De opties zijn de gebruiker waarschuwen, de afsluiting annuleren of een andere goedgekeurde procedure volgen. Stil ‘het opruimen duurde te lang’ escaleren naar een geforceerde uitzetting is de ene optie die de uitkomst garandeert die iedereen wilde vermijden.

Opgeschreven is de regel kort: rond het privéwerk af, sluit de afhankelijke sessie, stop de tunnel via zijn eigenaar en sluit dan normaal af. Vier stappen, in die volgorde, met aan elke stap een deadline gekoppeld.