Váš skript spouští VPN, ale nezřizuje ji

Napíšete skript, který spouští scutil --nc start s názvem připojení, funguje na vašem Macu a selže na každém čerstvě nainstalovaném stroji v kanceláři. Skript není rozbitý. Žádá se od něj něco, co nikdy nedokázal: spuštění existujícího připojení není stejná operace jako vytvoření nového.

Zřizování a správa relace jsou dvě práce se dvěma vlastníky a pracovní postup, který předpokládá opak, projde každým testem na stroji, kde vznikl.

S čím příkaz pro spuštění skutečně mluví

Příkaz pro správu relace se obrací na konfiguraci, která už existuje a už je schválená. Žádá systém, aby toto pojmenované připojení zvedl, s použitím nastavení serveru, odkazů na identitu a zásad uložených dříve. Pokud se ty nikdy nenainstalovaly, není co spouštět.

Proto se selhání objevuje na novém hardwaru a ne na notebooku správce. Notebook byl zřízen před měsíci člověkem, který na to mezitím zapomněl. Berte příkaz pro spuštění jako zvonek, který někdo zapojil v minulém čtvrtletí. Stisknout ho není totéž jako položit rozvody.

Tři vlastníci konfigurace VPN

Profil spravovaný organizací pochází ze správy zařízení. Profil nese adresy serveru, uspořádání ověřování a zásady, které organizace vyžaduje, a správce VPN je člověk, který je dodává. Skript by neměl tyto údaje rekonstruovat ze zobrazovaného názvu nalezeného v seznamu.

Nativní osobní konfigurace VPN se vytváří přes Network Extension API od Applu, které pokrývá vestavěné protokoly IPsec a IKEv2. To je rozhraní aplikace s krokem uložení a schválením uživatele, ne příkaz shellu, který tiše vytvoří jakýkoli typ tunelu, který dodavatel dodá.

Klient třetí strany je třetí případ s vlastním formátem importu, vlastním nástrojem správy a často vlastním privilegovaným pomocníkem. Jeho relaci vlastní proces daného dodavatele. Nalézt systémovou službu s podobným názvem není důkaz, že systémový příkaz ovládá tunel, a takový předpoklad vytváří skripty, které vypadají funkčně, dokud dodavatel neaktualizuje klienta.

Nativní zřizování má uložení a schválení

Model Applu je načíst, upravit, uložit. Aplikace načte existující předvolby před prvním uložením po spuštění, změní konfiguraci a poté ji uloží. Uložení hlásí chybu, když nemůže zapsat, a ignorování tohoto výsledku promění selhání zřizování v selhání připojení o tři kroky dál.

První uložení také vyžaduje, aby uživatel aplikaci schválil. Je to záměrná bezpečnostní hranice a znamená, že první spuštění na novém Macu je interaktivní, i když každé další připojení a odpojení lze automatizovat. Naplánujte první spuštění jako lidský úkol s přítomným člověkem. Automatizujte druhé spuštění a další a napište to do runbooku, aby nikdo nesliboval nemožné. Plán nasazení, který slibuje plně bezobslužné první spuštění, slibuje něco, co platforma nenabízí.

Apple také doporučuje ověřit kompatibilitu serveru pomocí konfiguračního profilu, než se na API spolehnete. Když tuto kontrolu uděláte první, oddělí «server tohoto klienta nepřijme» od «klient nikdy neuložil nastavení», což jsou různé tikety pro různé týmy.

Co může opakovatelný příkaz pro spuštění předpokládat

Po zřízení se skript může bezpečně zaměřit na existující připojení přes rozhraní jeho vlastníka. Předejte mu stabilní identitu připojení plus akci, kterou chcete, a nic jiného. Neměl by číst odhadovanou cestu k předvolbám a neměl by předpokládat, že název v nabídce je v celém systému jedinečný.

U nativních připojení je pojmenovaný požadavek na relaci, jako scutil --nc start, řídicí operace. Neinstaluje nastavení serveru, neimportuje přihlašovací údaje a neprovádí autorizaci prvního uložení. Berte ho jako poslední krok řetězu, nikdy jako celý řetěz.

Udržujte tajemství mimo argumenty příkazové řádky a mimo běžný diagnostický výstup. Ať nasazení zvolí jakýkoli mechanismus identity, příkaz pro spuštění se má spolehnout právě na něj, a heslo vložené do historie shellu je nálezem v každé revizi.

Dvě přejímací kontroly

První kontrola je zřízení: vezměte čerstvě nainstalovaný Mac a prokažte, že konfigurace existuje, patří správnému správci a je plně schválená. Udělejte to před testem konektivity, protože test připojení na nezřízeném stroji o skriptu nic nedokazuje.

Druhá kontrola je relace: připojte se, dosáhněte autorizovaného zdroje a čistě se odpojte. Každé selhání má nyní vlastníka, což je praktický přínos rozdělení obou prací. Chybějící profil je problém doručení, chyba uložení je problém schválení, odmítnuté přihlášení je problém ověřování a časový limit po úspěšném spuštění je vrstva relace. Ani jedno z nich není «skript je rozbitý».