Ditt skript startar VPN:et; det etablerar det inte

Du skriver ett skript som kör scutil --nc start med anslutningens namn, det fungerar på din Mac, och det misslyckas på varje nyinstallerad maskin på kontoret. Skriptet är inte trasigt. Det ombeds göra något det aldrig kunde: att starta en befintlig anslutning är inte samma operation som att skapa en ny.

Etablering och sessionsstyrning är två arbeten med två ägare, och ett arbetsflöde som antar motsatsen klarar varje test på maskinen där det skrevs.

Vad startkommandot egentligen talar med

Ett sessionsstyrningskommando vänder sig till en konfiguration som redan finns och redan är godkänd. Det ber systemet att resa den namngivna anslutningen, med de serverinställningar, identitetsreferenser och den policy som sparades tidigare. Om de aldrig installerades finns det inget att starta.

Därför dyker felet upp på ny hårdvara och inte på administratörens bärbara dator. Den bärbara datorn etablerades för månader sedan av en person som sedan glömt det. Tänk på startkommandot som en dörrklocka som någon drog ledningar till förra kvartalet. Att trycka på den är inte detsamma som att dra ledningarna.

Tre ägare av en VPN-konfiguration

En profil som organisationen hanterar kommer från enhetshantering. Profilen bär serveradresserna, autentiseringsordningen och den policy organisationen kräver, och VPN-administratören är personen som levererar dem. Ett skript bör inte återskapa de inställningarna från ett visningsnamn som det hittade i en lista.

En inbyggd personlig VPN-konfiguration skapas via Apples Network Extension API, som täcker de inbyggda protokollen IPsec och IKEv2. Det är ett programgränssnitt med ett sparsteg och ett användargodkännande, inte ett shell-kommando som tyst skapar vilken tunneltyp en leverantör än levererar.

En tredjepartsklient är ett tredje fall med eget importformat, eget hanteringsverktyg och ofta egen privilegierad hjälpare. Dess session ägs av den leverantörens process. Att hitta en systemtjänst med liknande namn är inte bevis för att ett systemkommando styr tunneln, och att anta det ger skript som ser ut att fungera tills leverantören uppdaterar klienten.

Inbyggd etablering har en sparning och ett godkännande

Apples modell är läs in, ändra, spara. Ett program läser in de befintliga inställningarna före sin första sparning efter start, ändrar konfigurationen och sparar den sedan. Sparningen rapporterar ett fel när den inte kan bestå, och att ignorera det resultatet gör ett etableringsfel till ett anslutningsfel tre steg senare.

Den första sparningen kräver också att användaren godkänner programmet. Det är en avsiktlig säkerhetsgräns, och det innebär att den första körningen på en ny Mac är interaktiv även när varje senare anslutning och frånkoppling kan automatiseras. Planera den första körningen som en mänsklig uppgift med en människa närvarande. Automatisera den andra körningen och framåt, och skriv det i runbooken så att ingen lovar det omöjliga. En utrullningsplan som lovar en helt obevakad första körning lovar något som plattformen inte erbjuder.

Apple rekommenderar också att validera serverns kompatibilitet med en konfigurationsprofil innan man förlitar sig på API:et. Att göra den kontrollen först skiljer «servern accepterar inte den här klienten» från «klienten sparade aldrig inställningarna», vilket är olika ärenden för olika team.

Vad ett upprepbart startkommando får anta

Efter etableringen kan ett skript säkert rikta sig mot den befintliga anslutningen via ägarens gränssnitt. Ge det anslutningens stabila identitet plus den åtgärd du vill ha, och inget annat. Det bör inte läsa en gissad inställningssökväg, och det bör inte anta att namnet i menyn är unikt i hela systemet.

För inbyggda anslutningar är en namngiven sessionsbegäran som scutil --nc start en styrningsoperation. Den installerar inga serverinställningar, importerar inga inloggningsuppgifter och utför ingen auktorisering av den första sparningen. Behandla den som det sista steget i en kedja, aldrig som hela kedjan.

Håll hemligheter utanför kommandoradsargument och utanför vanlig diagnostisk utdata. Vilken identitetsmekanism utrullningen än valde är det den startkommandot ska lita på, och ett lösenord inklistrat i shell-historiken är en iakttagelse i varje granskning.

Två acceptanskontroller

Den första kontrollen är etableringen: ta en nyinstallerad Mac och bevisa att konfigurationen finns, ägs av rätt administratör och är fullt godkänd. Gör det innan du testar anslutningen, för ett anslutningstest på en icke etablerad maskin bevisar inget om skriptet.

Den andra kontrollen är sessionen: anslut, nå den auktoriserade resursen och koppla från rent. Varje fel har nu en ägare, och det är den praktiska nyttan med att dela de två arbetena. En saknad profil är ett leveransproblem, ett sparningsfel är ett godkännandeproblem, en avvisad inloggning är ett autentiseringsproblem, och en timeout efter en lyckad start är sessionslagret. Ingen av dem är «skriptet är trasigt».