Att trycka på Koppla från fungerar, och tio sekunder senare är tunneln tillbaka ändå. Den loopen är sällan VPN-klienten som beter sig fel; det är ett återställningsskript som alltid bara ställde en enda fråga, ”är den nere?”, och svarade på den genom att ansluta. När du skiljer frågan som användaren svarade på från frågan som systemet rapporterar, blir rättelsen en liten mängd tillstånd i stället för en längre väntan.

Två frågor, inte en

Ska den här profilen vara ansluten just nu, och vad rapporterar systemet för tillfället? Det är olika frågor med olika ägare, och en återställningspolicy behöver båda innan den agerar. Avsikt är något som ditt verktyg bestämmer och kommer ihåg. Observerat tillstånd är något som plattformen berättar för dig.

IntentWhat you observeWhat to do
WantedDropped unexpectedlyAllow one supported recovery attempt
Paused by the userDisconnectedDo nothing until intent changes
WantedAlready connectingWait instead of starting a rival attempt
WantedAuthentication needs a personPrompt, then stop replaying credentials

Läs raderna som en policy och inte som en lista av fall. Den andra raden är den som de flesta skript utelämnar, och det är den enda raden som skiljer en övervakare från en maskin som insisterar på att ha rätt.

Observerat tillstånd är inte en preferens

Apples Network Extension-statusmodell rapporterar tillstånden connecting, connected, disconnecting, disconnected och recovery. Alla fem beskriver anslutningen. Ingen av dem säger ”användaren bad om att den här profilen skulle förbli pausad”, eftersom det inte är ett anslutningstillstånd alls. Klienter som inte är byggda på det ramverket exponerar sina egna stödda kontroller och statusanrop, och de drar samma gräns i sin egen vokabulär.

Konsekvensen är att ett frånkopplat tillstånd aldrig kan tolkas på egen hand. Det betyder en av minst tre saker: tunneln föll, användaren stoppade den, eller systemet är mellan försök. Bara din egen registrering av avsikten kan skilja dem åt. Skriv ner den registreringen, behåll den mellan omstarter om den måste överleva en omstart, och uppdatera den i det ögonblick användaren agerar i stället för att härleda den senare från en loggrad.

scutil --nc list
scutil --nc status "Office VPN"

Vem mer får starta den här profilen

En paus som din hjälpare lovar är bara så stark som de andra ägarna av samma profil. En On Demand-regel, en hanterad konfiguration eller en andra klient kan alla begära en anslutning, och din hjälpare kommer att se trasig ut medan den beter sig exakt som skrivet.

Hitta varje mekanism som kan starta profilen innan du lovar att respektera en paus, och skriv ner vilken som vinner. När en hanterad tjänst medvetet håller tillbaka ett personligt pausalternativ, är det ett administratörsbeslut om policy, inte en lucka som ett skript ska fylla genom att kämpa mot hanteringen.

Gör återförsöken tråkiga

Begränsa antalet försök och gör varje försök lyhört för något som förändrades: nätverket kom tillbaka, gatewayen svarade, inloggningsprompten slutfördes. En otillgänglig gateway, en utgången identitet och en avvisad andra faktor behöver tre olika svar, och en stram loop ger alla tre samma.

Titta på vad ett snabbt återförsök faktiskt producerar på skärmen. Upprepade dialoger som användaren stänger är värre än ett enda tydligt felmeddelande, och de lär människor att klicka sig igenom promptar utan att läsa dem.

Paus och trafikpolicy är separata löften

En tunnel som användaren har pausat lämnar ofta trafiken blockerad med avsikt, och det är hela poängen med en policy i kill switch-stil. Det betyder att Paus bör lova exakt en sak: återställningen stoppar. Den bör inte tyst ändra vad nätverket tillåter.

Bestäm trafikbeteendet separat, dokumentera det bredvid Paus-kontrollen och håll det konsekvent oavsett om tunneln är pausad, misslyckad eller frånvarande. Annars lär sig användaren att det att trycka på Koppla från gör något oförutsägbart, och nästa supportärende handlar om ett nätverk som ”ibland slutar fungera” utan synlig anledning.

Relaterade artiklar