Dy nisës hapin të njëjtin profil në një makinë, dhe vetëm GUI lidhet. Skedari është i paprekur dhe instaluesi me gjasë është në rregull; ajo që ndryshon është konteksti që secili nisës i jep openvpn.exe. Drejtoria e punës, identiteti i llogarisë dhe atributet e skedarit udhëtojnë të gjitha me atë kontekst. Kontrollojini në atë rend dhe ndaloni te i pari që shpjegon gabimin.

Konfirmoni cili nisës dështon

Filloni duke vërtetuar ndarjen. Nëse GUI lidhet dhe shërbimi jo, me të njëjtën shteg profili, skedari është i lexueshëm nga dikush dhe pyetja bëhet kush e lexon dhe nga ku. Nëse të dy dështojnë, profili është i prishur dhe asgjë nga kjo nuk vlen. Shkruani emrin e shërbimit dhe profilin e saktë që iu kërkua të ngarkojë.

Një shërbim i drejtuar drejt drejtorisë së vet të nisjes automatike mund të mos ngarkojë skedarin që keni të hapur në një editor. Krahasoni shtegun në konfigurimin e shërbimit me shtegun në GUI, karakter për karakter, sepse një emër dosjeje në fund ose një shkronjë tjetër njësie mjafton për t’ju dërguar në degën e gabuar.

Ku zgjidhen shtigjet relative

Një profil që referon ca.crt ose një skript ndihmës vetëm me emër kërkon një kërkim relativ me vendin ku ndodhet procesi. GUI nis në dosjen e konfigurimit, prandaj ato emra zgjidhen. Një shërbim i nisur nga menaxheri i shërbimeve nuk ka një pikënisje të tillë, dhe kërkimi dështon përpara se të lexohet çdo certifikatë. Kjo është arsyeja pse i njëjti profil funksionon në një nisës dhe jo në tjetrin.

Jepini mbështjellësit një drejtori ku të nisë, ose bëni absolute çdo referencë. Riprodhimi i kontekstit të GUI në një rresht komande duket kështu:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

Rritja e hollësisë në atë komandë tregon shtegun e saktë që u provua. Bëjeni këtë përpara se të ndryshoni lejet, sepse një skedar që mungon dhe një lexim i refuzuar kërkojnë rregullime të ndryshme. Regjistri i parazgjedhur nuk i dallon. Një flamur shtesë kursen një orë hamendjeje.

Kur identiteti i shërbimit nuk mund të lexojë

Një shërbim ekzekutohet si identitet sistemi, jo si ju. Një ACL që i jep përdoruesit tuaj kontroll të plotë dhe askujt tjetër dështon atje, ndërsa funksionon në mënyrë të përsosur në sesionin tuaj. Një profil i mbajtur në një njësi të mapuar ose në një ndarje të autentikuar dështon për të njëjtën arsye. Konfirmoni lejet e skedarit përpara se të shikoni çdo gjë tjetër.

Kontrolli është një lexim i lejeve efektive plus një lexim i provuar si identiteti i shërbimit. Ekzekutoni pjesën e parë nga një prompt i ngritur:

icacls "C:\VPN\profiles\office\office.ovpn"

Më pas provoni të njëjtin lexim si identiteti i shërbimit, për shembull me psexec -s -i nga Sysinternals, dhe vëzhgoni nëse skedari hapet. Nëse nuk hapet, asnjë rregullim shtegu nuk do të ndihmojë. Rregulloni ACL-në ose zhvendosni profilin në një vend që identiteti i shërbimit mund ta lexojë.

Kriptimi në nivel skedari është rasti i dytë, më i rrallë. Një profil i shënuar me atributin Encrypting File System dekriptohet në mënyrë transparente për përdoruesin që e kriptoi dhe mbetet i palexueshëm për një llogari shërbimi. Kjo është arsyeja pse i njëjti skedar hapet në editorin tuaj dhe jo nën shërbim.

Atributi është i dukshëm nga një prompt i ngritur, dhe kontrollimi i tij nuk e hap profilin. Ekzekutoni të dy komandat dhe lexoni daljen:

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

Fshirja e atributit e bën skedarin të lexueshëm, dhe gjithashtu heq mbrojtjen që mbante. Nëse profili duhet të mbetet i mbrojtur, vendosni materialin sekret atje ku identiteti i shërbimit ka një dhënie të qartë, në vend që të mbështeteni në kriptim për përdorues. Një rregullim i tillë i mbijeton një ndryshimi të fjalëkalimit, dhe e bën aksesin të rishikueshëm nga dikush tjetër përveç personit që kriptoi skedarin.

Vendosja se kujt i përket tuneli

GUI mund të kërkojë një fjalëkalim dhe mund të lexojë një certifikatë nga depoja e përdoruesit tuaj. Shërbimi nuk mund të bëjë asnjërën, kështu që një profil që varet nga një sekret interaktiv nuk do të nisë kurrë pa mbikëqyrje, pavarësisht se si rregullohen shtigjet. Ky kufi është një vendim dizajni, jo një defekt për t’u anashkaluar. Zgjidhni një pronar përpara se të ndryshoni çdo gjë tjetër.

Nëse tuneli duhet të jetë lart përpara identifikimit, jepini shërbimit një burim kredencialesh pa mbikëqyrje dhe kopjen e vet të profilit. Nëse duhet të ekzistojë vetëm sa kohë që jeni në tavolinë, mbajeni në GUI dhe hiqni kopjen e shërbimit. Të dyja njëkohësisht është konfigurimi që prodhon konflikte përshtatësi dhe rrugë të dyfishta.

Ai konflikt zakonisht diagnostikohet si gabim konfigurimi dhe jo si dy pronarë që luftojnë për një përshtatës. Regjistri i ngjarjeve do të tregojë një proces që dështon të hapë pajisjen TAP, gjë që duket si problem lejeje dhe nuk është. Numëroni së pari pronarët.

Çfarë nis në të vërtetë mbështjellësi i shërbimit

Pika e hyrjes së shërbimit është një mbështjellës i vogël që lexon parametrat e vet të ruajtur dhe pastaj nis openvpn.exe. Kur rreshti i komandës në regjistrin e ngjarjeve nuk përputhet me pritshmërinë tuaj, pikërisht ato vlera janë ajo që duhet inspektuar. Riinstalimi i kthen ato në parazgjedhje dhe shkatërron provat. Lexojini së pari.

Vlerat jetojnë në regjistrin e sistemit nën çelësin e vet të shërbimit, dhe sc qc tregon shtegun binar që do të nisë menaxheri i shërbimeve. Krahasoni atë shteg me konfigurimin e ruajtur të mbështjellësit përpara se të redaktoni ndonjërin prej tyre.

Zëvendësimi i mbështjellësit me një skript që ju kontrolloni është më invaziv, por e palos rreshtin e komandës efektive në një skedar të lexueshëm. Përfundoni me një rinisje, pastaj lexoni regjistrin për çdo profil derisa të shfaqet rreshti i parë i suksesshëm i nisjes. Një status shërbimi në punë do të thotë vetëm se mbështjellësi nuk ka dalë, gjë që është e vërtetë edhe kur fëmija i tij vdiq menjëherë.

Artikuj të ngjashëm