Hook i klientit apo hook i serverit? Ku ekzekutohet një skript i OpenVPN
Një rrugë skripti në një konfigurim serveri është një rrugë në server. Zgjidhni hook-un sipas makinës që duhet ta bëjë punën dhe ndaloni së prituri që një push të ekzekutojë kod në një laptop.
Detyra është e qartë: kur një laptop lidhet, diçka në laptop duhet të ndryshojë. Konfigurimi që po redaktohet i përket serverit, dhe pikërisht aty thyhet supozimi. Një rrugë në një skedar serveri emërton një skedar në atë server, dhe asnjë sasi push nuk ndryshon se procesi i kujt e ekzekuton atë. Zgjedhja midis dy hook-ëve është kryesisht vendimi se cila makinë zotëron punën dhe pranimi i kufizimeve që vijnë.
Dy makina, dy pyetje që duhen përgjigjur së pari
Pyetni ku duhet të ndodhë ndryshimi i gjendjes, pastaj pyetni cila ngjarje i përket. Nëse ndryshimi është një autorizim për çdo përdorues ose një vendim konfigurimi për çdo klient, ai i përket atje ku drejtoria e përdoruesve është e njohur: serveri. Nëse ndryshimi është një rrugë, një rregullim resolver ose një ndihmës lokal në një pikë fundore, ai i përket pikës fundore, dhe vetëm pika fundore mund ta bëjë atë.
Përgjigjja e këtyre dy pyetjeve në rend të kundërt është mënyra se si njerëzit përfundojnë duke u përpjekur të shtyjnë një skedar batch në një laptop Windows. Serveri e di kush u lidh; laptopi e di si duket staku i vetë rrjetit. Asnjëri nuk i ka informacionet e tjetrit, dhe përpjekja zakonisht dështon në heshtje në vend të një gabimi të qartë.
Para të dyjave ia vlen një pyetje e tretë: a e ofron platforma fare hook-un që dëshironi? Një pajisje që gjeneron vetë konfigurimin e saj mund të mos ofrojë të njëjtat emra ngjarjesh, dhe një klient desktop që importon një skedar .ovpn nuk është domosdoshmërisht i njëjti klient për të cilin u shkrua skedari. Konfirmimi i platformës së pari ju shpëton nga projektimi rreth një hook-u që nuk ekziston atje. Gjithashtu ju tregon se cilat dokumente zbatohen vërtet për makinën përpara jush.
Opsioni nga ana e serverit: një ngjarje për çdo lidhje
Një skript client-connect ekzekutohet në kontekstin e procesit të serverit kur lidhet një klient i autentikuar, dhe merr detaje lidhjeje të dokumentuara si common name dhe adresa e caktuar. Është vendi i duhur për të shkruar një fragment konfigurimi për çdo klient, për të zbatuar një vendim politike ose për të regjistruar gjendjen që zotëron serveri.
Dallimi që njerëzit nuk e vënë re është ndryshimi midis atij hook-u dhe një hook up të serverit. Hook-u up aktivizohet kur serveri hap pajisjen e tij të tunelit, gjë që në një server me shumë klientë ndodh një herë në nisjen e demonit. Nuk është ngjarje për çdo hyrje, dhe kodi i vendosur atje ekzekutohet kur nis shërbimi, jo kur lidhen përdoruesit.
Në një pajisje me ndërfaqe web, përdorni mekanizmin e mbështetur të zgjerimit në vend që të redaktoni skedarët e demonit të gjeneruar. Skedarët e gjeneruar rishkruhen në ruajtjen tjetër, dhe rishkrimi heq në heshtje ndryshimin tuaj në momentin më të keq. Mbani një kopje të tekstit të zgjerimit jashtë pajisjes, që një përditësim firmware të mos humbasë edhe qëllimin.
Opsioni nga ana e klientit: punë që duhet të ekzekutohet lokalisht
Një klient i komunitetit mund të ekzekutojë një skript lokal kur pajisja e tunelit ngrihet dhe përsëri kur instalohen rrugët. Këto janë dy momente të ndryshme, dhe zgjedhja e gabuar prodhon garën klasike ku një ndihmës niset para se të ekzistojë rruga nga e cila varet.
Ndihmësi duhet të ekzistojë në atë klient, të jetë i lexueshëm dhe i ekzekutueshëm nga llogaria që ekzekuton klientin, dhe të lejohet nga një rregullim script-security i qartë. Një skript që funksionon kur e nisni klientin si administrator nuk ju thotë asgjë për një shërbim para hyrjes ose për sesionin e një përdoruesi tjetër.
Edhe emërtimi ka rëndësi. Hook-u up korrespondon me krijimin e pajisjes dhe route-up me instalimin e rrugëve, por një detyrë që kërkon një rrjet privat të arritshëm duhet të verifikojë arritshmërinë në vend që të supozojë se krijimi i pajisjes do të thotë që çdo rrugë, zë resolver dhe aplikacion janë gati.
Pse shtyrja e kodit të ekzekutueshëm nuk është në opsione
Opsionet e shtyra me push janë qëllimisht të kufizuara, dhe opsionet që ekzekutojnë skripte janë ndër kategoritë që serveri nuk lejohet t'i kalojë. Ky kufizim ekziston sepse alternativa do t'i lejonte një serveri të komprometuar ose të konfiguruar gabimisht të ekzekutojë komanda arbitrare në çdo klient që lidhet ndonjëherë.
Aktivizimi i ekzekutimit të skripteve lokalisht nuk e ndryshon atë. Rregullimi juaj script-security lejon skriptet lokale që keni zgjedhur vetë; nuk e autorizon serverin të furnizojë të reja.
Nëse qëllimi është thjesht instalimi i rrugëve VPN, përdorni konfigurimin e mbështetur të rrugëve në vend që të shpikni një skemë ekzekutimi në distancë. Nëse qëllimi kërkon vërtet kod lokal, shpërndajeni përmes mjeteve të organizatës për menaxhimin e pikave fundore dhe shqyrtojeni si çdo software tjetër që ekzekutohet me privilegjet e përdoruesit.
Çfarë të verifikoni përpara se t'i besoni cilësdo hook
Shkruani katër gjëra për çdo hook: makinën, emrin e ngjarjes, llogarinë nën të cilën ekzekutohet dhe ndryshimin e gjendjes që supozohet të prodhojë. Pastaj provoni lidhjen, një rilidhje dhe rrugën e pastrimit, sepse një hook që humb gjendje në rilidhje është më keq se një që nuk u ekzekutua kurrë.
Provoni nën llogarinë që do ta ekzekutojë vërtet, në momentin kur do të ekzekutohet vërtet. Manuali openvpn(8) dokumenton të dy familjet e hook-ëve dhe kufizimet e push; platforma ku vendosni dokumenton nëse i ekspozon fare. Një skript që ka sukses në një terminal administratori interaktiv është hipotezë, jo verifikim.