Mac-VPN verbindt zichzelf opnieuw direct nadat je op Verbreken drukt

Op Verbreken drukken werkt, en tien seconden later is de tunnel er toch weer. Die lus is zelden de VPN-client die zich misdraagt; het is een herstelscript dat altijd maar één vraag stelde, „is hij omlaag?“, en die beantwoordde door te verbinden. Zodra je de vraag die de gebruiker beantwoordde scheidt van de vraag die het systeem meldt, wordt de oplossing een kleine hoeveelheid toestand in plaats van een langere slaap.

Twee vragen, niet één

Moet dit profiel nu verbonden zijn, en wat meldt het systeem op dit moment? Dat zijn verschillende vragen met verschillende eigenaren, en een herstelbeleid heeft beide nodig voordat het handelt. Intentie is iets wat je tool beslist en onthoudt. Waargenomen toestand is iets wat het platform je vertelt.

Lees de rijen als een beleid en niet als een lijst met gevallen. De tweede rij is degene die de meeste scripts weglaten, en het is de enige rij die een monitor onderscheidt van een machine die erop staat gelijk te hebben.

Waargenomen status is geen voorkeur

Apple's Network Extension-statusmodel meldt de toestanden connecting, connected, disconnecting, disconnected en recovery. Alle vijf beschrijven de verbinding. Geen ervan zegt „de gebruiker vroeg om dit profiel gepauzeerd te houden“, want dat is helemaal geen verbindingstoestand. Clients die niet op dat raamwerk zijn gebouwd, bieden hun eigen ondersteunde bediening en statusaanroepen, en ze trekken dezelfde grens in hun eigen vocabulaire.

Het gevolg is dat een verbroken status nooit op zichzelf kan worden geïnterpreteerd. Hij betekent een van ten minste drie dingen: de tunnel viel weg, de gebruiker stopte hem, of het systeem zit tussen pogingen. Alleen je eigen registratie van de intentie kan die uit elkaar houden. Schrijf die registratie op, bewaar haar over herstarts heen als ze een herstart moet overleven, en werk haar bij op het moment dat de gebruiker handelt in plaats van haar later uit een logregel af te leiden.

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

Wie mag dit profiel nog meer starten

Een pauze die je helper belooft, is alleen zo sterk als de andere eigenaren van hetzelfde profiel. Een On Demand-regel, een beheerde configuratie of een tweede client kunnen allemaal een verbinding aanvragen, en je helper zal kapot lijken terwijl hij zich precies gedraagt zoals beschreven.

Vind elk mechanisme dat het profiel kan starten voordat je belooft een pauze te respecteren, en schrijf op welke wint. Wanneer een beheerde dienst bewust een persoonlijke pauzeoptie onthoudt, is dat een beslissing van de beheerder over beleid, geen gat dat een script moet vullen door tegen het beheer te vechten.

Maak de nieuwe pogingen saai

Beperk het aantal pogingen en maak elke poging gevoelig voor iets dat veranderde: het netwerk kwam terug, de gateway antwoordde, de inlogvraag werd voltooid. Een niet-beschikbare gateway, een verlopen identiteit en een geweigerde tweede factor vragen drie verschillende reacties, en een strakke lus geeft alle drie dezelfde.

Kijk wat een snelle nieuwe poging echt op het scherm oplevert. Herhaalde dialogen die de gebruiker wegklikt zijn erger dan één duidelijke foutmelding, en ze leren mensen door prompts heen te klikken zonder ze te lezen.

Pauze en verkeersbeleid zijn aparte beloften

Een door de gebruiker gepauzeerde tunnel laat verkeer vaak expres geblokkeerd, en dat is precies het punt van een beleid in kill switch-stijl. Dat betekent dat Pauze precies één ding moet beloven: herstel stopt. Het mag niet stil veranderen wat het netwerk toestaat.

Bepaal het verkeersgedrag apart, documenteer het naast de Pauze-bediening, en houd het consistent of de tunnel nu gepauzeerd, mislukt of afwezig is. Anders leert de gebruiker dat op Verbreken drukken iets onvoorspelbaars doet, en de volgende supportticket gaat over een netwerk dat „soms stopt met werken“ zonder zichtbare reden.