VPN në Mac gjatë nisjes: launchd mbikëqyr punën, jo tunelin
Një plist që kalon lint nuk provon asgjë për kredencialet ose gatishmërinë. Përshtat punën me sesionin e saj, mbaj klientin në plan të parë dhe testojeni në atë kontekst.
Puna ekzekutohet gjatë hyrjes, regjistri tregon klientin duke nisur, por tuneli nuk ngrihet kurrë. Ose ngrihet dhe zhduket disa sekonda më vonë. Në të dyja rastet lista e vetive ishte ndoshta në rregull. launchd dha dy premtime kur pranoi punën: do të mbikëqyrë një proces, dhe ai proces do të vazhdojë të ekzekutohet. VPN-ja ka nevojë për të dyja, dhe një skedar XML i saktë nuk ofron asnjërën.
Një listë e vlefshme vetive nuk është shërbim që punon
plutil -lint kontrollon strukturën. Nuk mund të të thotë nëse binari ekziston, nëse argumentet mbështeten nga ky version i klientit, ose nëse puna nis në një kontekst ku kredencialet janë të disponueshme. Këto janë pyetje semantike, dhe ato shpjegojnë shumicën e dështimeve që duken si probleme të launchd.
plutil -lint /Library/LaunchDaemons/com.example.vpn.plist
launchctl print system/com.example.vpn
Lexo daljen e komandës së dytë në vend që të supozosh se puna u ngarkua. Ajo raporton statusin e fundit të daljes dhe nëse shërbimi po ekzekutohet, gjë që dallon "nuk nisi kurrë" nga "nisi dhe vdiq" përpara se të prekësh profilin.
Agjentët trashëgojnë një sesion përdoruesi, demonët jo
Dokumentacioni i Apple për launchd i ndan agjentët për përdorues nga demonët e sistemit. Një agjent ekzekutohet në kontekstin e përdoruesit të hyrë, me vargun e tij të çelësave dhe mjedisin. Një demon ekzekutohet pa atë sesion, dhe zhvendosja e punës në një drejtori sistemi nuk rikrijon kredencialet interaktive të përdoruesit.
Është ky dallim që vendos modelin. Nëse lidhja kërkon që një person të hyjë ose të miratojë një kërkesë MFA, rregullimi i mbështetur është një punë në sesionin e përdoruesit që ekzekutohet pas hyrjes. Nëse duhet të funksionojë pa askënd të hyrë, klienti ka nevojë për një identitet të miratuar pa mbikëqyrje, me procesin e vet të rinovimit dhe revokimit. Zgjedhja e rreshtit të gabuar prodhon një punë që nis pastër dhe dështon në hapin e parë të vërtetimit.
Mos e mbuloj dallimin me një fjalëkalim në vargun e argumenteve ose duke çaktivizuar kontrollet e certifikatave. Të dyja e kthejnë një kërkesë vërtetimi në një sekret të përhershëm në një skedar të lexueshëm, dhe e dyta do të thotë që tuneli vërteton gjithçka që përgjigjet.
Mbikëqyrja funksionon vetëm nëse procesi qëndron përpara
Një klient që e bën vetë demon kthen kontrollin te launchd menjëherë, dhe mbikëqyrësi shikon atëherë një proces që ka përfunduar tashmë. Tuneli mund të jetë lart, por launchd mendon se puna dështoi, dhe politika e rinisjes do të bëjë diçka që nuk e kishe ndërmend.
Përdor modalitetin e dokumentuar të planit të parë ose të shërbimit. Nëse produkti ka funksionin e vet të mbështetur të nisjes, ai funksion tashmë e di si të qëndrojë përpara dhe si t'i dorëzojë stakut të rrjetit; një punë e personalizuar është model i veçantë, jo përmirësim i tij.
Jepi punës një etiketë unike, ekzekutuesin e synuar dhe një varg argumentesh të qëllimshëm. Një varg nuk është rresht komande i shell-it, prandaj tubat dhe ridrejtimet nuk punojnë atje, dhe thonjëzat sillen ndryshe. Një komandë që ka sukses në terminalin e administratorit është më së shumti një kontroll paraprak.
Kredencialet duhet të punojnë pa kërkesë
Operimi pa mbikëqyrje e zhvendos problemin e kredencialeve në vend që ta heqë. Dikush duhet ta zotërojë identitetin, të vendosë sa jeton dhe të dokumentojë si zëvendësohet. Një certifikatë pa monitorim të skadimit bëhet një ndërprerje me një datë në kalendar.
Mbaj sekretet jashtë argumenteve dhe jashtë daljes standarde të punës. Nëse klienti mbështet leximin e një kredenciali nga një depo e mbrojtur, përdor atë rrugë, dhe kontrollo nëse konteksti i ekzekutimit të punës mund të arrijë në depo. Një demon që ekzekutohet si root zakonisht nuk mund të lexojë një element të vargut të çelësave të hyrjes, dhe ky është lloji i detajit që shfaqet vetëm në kontekstin e sistemit.
Përcakto çfarë do të thotë gati, pastaj testo atje
Një nisje e suksesshme provon që procesi filloi. Nuk provon që rrjeti është lart, që porta pranoi identitetin ose që aplikacioni privat është i arritshëm. Nëse diçka tjetër varet nga tuneli, i duhet një sinjal gatishmërie që pasqyron lidhjen, jo orën e nisjes së punës.
Riprovat duhet të jenë të kufizuara dhe duhet të dallojnë një rrjet që mungon nga një kredencial i refuzuar. Rinisja në çdo dështim nuk mund të rregullojë një certifikatë të skaduar dhe prodhon një regjistër plot prova identike që fsheh atë të vërtetën.
Prano punën në kontekstin ku do të ekzekutohet vërtet: pa rrjet gjatë nisjes, një hyrje normale, një zgjim nga gjumi dhe një ndalim i kontrolluar. Pastaj regjistro bashkë etiketën e punës, versionin e klientit dhe rishikimin e profilit, që personi tjetër të trashëgojë një shërbim të atribueshëm dhe jo një skedar që funksionoi dikur.