કાર્ય સ્પષ્ટ છે: લેપટોપ કનેક્ટ થાય ત્યારે લેપટોપ પર કંઈક બદલાવું જોઈએ. જે કન્ફિગરેશન સંપાદિત થાય છે તે સર્વરનું છે, અને ત્યાં જ આ ધારણા તૂટે છે. સર્વર ફાઇલમાંનો પાથ તે સર્વર પરની ફાઇલ દર્શાવે છે, અને કેટલું પણ push કરો, કઈ પ્રક્રિયા તેને ચલાવે છે તે બદલાતું નથી. બે હૂક વચ્ચે પસંદગી મુખ્યત્વે એ નક્કી કરવાની બાબત છે કે કામ કઈ મશીનનું છે, અને તેમાંથી આવતી મર્યાદાઓ સ્વીકારવાની.

બે મશીન, પહેલા જવાબ આપવાના બે પ્રશ્નો

પૂછો કે સ્ટેટ ફેરફાર ક્યાં થવો જોઈએ, પછી પૂછો કે કઈ ઘટના તેને અનુરૂપ છે. જો ફેરફાર પ્રતિ-વપરાશકર્તા અધિકૃતિ હોય કે પ્રતિ-ક્લાયન્ટ કન્ફિગરેશન નિર્ણય હોય, તો તે ત્યાં જ જાય જ્યાં વપરાશકર્તા ડિરેક્ટરી જાણીતી છે: સર્વર પર. જો ફેરફાર રૂટ હોય, રિઝોલ્વર સેટિંગ હોય કે એન્ડપોઇન્ટ પરનું સ્થાનિક સહાયક હોય, તો તે એન્ડપોઇન્ટ પર જાય, અને ફક્ત એન્ડપોઇન્ટ જ તે કરી શકે.

આ બે પ્રશ્નોનો ઉલટા ક્રમમાં જવાબ આપવો એ જ રીતે લોકો Windows લેપટોપ પર બેચ ફાઇલ push કરવાનો પ્રયાસ કરે છે. સર્વર જાણે છે કોણ કનેક્ટ થયું; લેપટોપ જાણે છે તેનો પોતાનો નેટવર્ક સ્ટેક કેવો દેખાય છે. બંનેમાંથી કોઈ પાસે બીજાની માહિતી નથી, અને પ્રયાસ સામાન્ય રીતે સ્પષ્ટ ભૂલને બદલે શાંતિથી નિષ્ફળ જાય છે.

બંને પહેલાં ત્રીજો પ્રશ્ન પૂછવો યોગ્ય છે: શું પ્લેટફોર્મ તમે ઈચ્છો તે હૂક આપે પણ છે? જે ઉપકરણ પોતાનું કન્ફિગરેશન જનરેટ કરે છે તે સમાન ઘટના નામો આપે ન પણ શકે, અને .ovpn ફાઇલ આયાત કરતો ડેસ્કટોપ ક્લાયન્ટ જે ક્લાયન્ટ માટે ફાઇલ લખાઈ હતી તે જ હોવો જરૂરી નથી. પ્લેટફોર્મ પહેલા ખાતરી કરવાથી ત્યાં ન હોય એવા હૂકની આસપાસ ડિઝાઇન કરવાથી બચો છો. તે એ પણ જણાવે છે કે તમારી સામેના મશીન પર કયું દસ્તાવેજીકરણ ખરેખર લાગુ પડે છે.

સર્વર બાજુનો વિકલ્પ: દરેક કનેક્શન માટે એક ઘટના

client-connect સ્ક્રિપ્ટ પ્રમાણિત ક્લાયન્ટ કનેક્ટ થાય ત્યારે સર્વરની પ્રક્રિયા સંદર્ભમાં ચાલે છે, અને તે common name તથા ફાળવેલું સરનામું જેવી દસ્તાવેજીકૃત કનેક્શન વિગતો મેળવે છે. પ્રતિ-ક્લાયન્ટ કન્ફિગરેશન ટુકડો લખવા, નીતિ નિર્ણય લાગુ કરવા કે સર્વરની માલિકીનું સ્ટેટ નોંધવા માટે તે યોગ્ય જગ્યા છે.

લોકો જે ભેદ ચૂકી જાય છે તે આ હૂક અને સર્વર up હૂક વચ્ચેનો ફરક છે. up હૂક ત્યારે સક્રિય થાય છે જ્યારે સર્વર તેનું ટનલ ઉપકરણ ખોલે છે, જે બહુ-ક્લાયન્ટ સર્વર પર ડેમન શરૂ થાય ત્યારે એક વાર બને છે. તે પ્રતિ-લોગિન ઘટના નથી, અને ત્યાં મૂકેલો કોડ વપરાશકર્તાઓ કનેક્ટ થાય ત્યારે નહીં, પણ સેવા શરૂ થાય ત્યારે ચાલે છે.

વેબ ઇન્ટરફેસવાળા ઉપકરણ પર, જનરેટ થયેલી ડેમન ફાઇલો સંપાદિત કરવાને બદલે સમર્થિત એક્સ્ટેન્શન પદ્ધતિ વાપરો. જનરેટ થયેલી ફાઇલો આગલી વખતે સાચવતી વખતે ફરી લખાય છે, અને એ પુનર્લેખન તમારો ફેરફાર સૌથી ખરાબ ક્ષણે શાંતિથી દૂર કરે છે. એક્સ્ટેન્શન ટેક્સ્ટની નકલ ઉપકરણની બહાર રાખો, જેથી ફર્મવેર અપડેટ પણ ઉદ્દેશ ગુમાવે નહીં.

ક્લાયન્ટ બાજુનો વિકલ્પ: સ્થાનિક રીતે ચાલવું જ પડે એવું કામ

સમુદાય ક્લાયન્ટ ટનલ ઉપકરણ ઉપર આવે ત્યારે અને ફરી રૂટ ઇન્સ્ટોલ થાય ત્યારે સ્થાનિક સ્ક્રિપ્ટ ચલાવી શકે છે. આ બે અલગ ક્ષણો છે, અને ખોટી પસંદગી એ પ્રખ્યાત રેસ ઉભી કરે છે જેમાં સહાયક જે રૂટ પર આધાર રાખે છે તેના અસ્તિત્વ પહેલાં જ શરૂ થઈ જાય છે.

સહાયક તે ક્લાયન્ટ પર હોવો જોઈએ, ક્લાયન્ટ ચલાવતા ખાતા માટે વાંચનીય અને ચલાવવા યોગ્ય હોવો જોઈએ, અને સ્પષ્ટ script-security સેટિંગ દ્વારા મંજૂર હોવો જોઈએ. એડમિનિસ્ટ્રેટર તરીકે ક્લાયન્ટ ચલાવો ત્યારે કામ કરતી સ્ક્રિપ્ટ લોગિન પહેલાંની સેવા કે બીજા વપરાશકર્તાના સેશન વિશે કંઈ જ કહેતી નથી.

નામકરણ પણ મહત્વનું છે. up હૂક ઉપકરણ બનાવવાને અનુરૂપ છે અને route-up રૂટ ઇન્સ્ટોલ કરવાને, પણ જે કાર્ય માટે ખાનગી નેટવર્ક પહોંચી શકાય એવું હોવું જરૂરી છે તેને ઉપકરણ બનાવવું એટલે દરેક રૂટ, રિઝોલ્વર એન્ટ્રી અને એપ્લિકેશન તૈયાર છે એમ ધારી લેવાને બદલે પહોંચવાની ક્ષમતા ચકાસવી જોઈએ.

કેમ ચલાવી શકાય એવો કોડ push કરવો વિકલ્પોમાં નથી

push કરાયેલા વિકલ્પો જાણી જોઈને મર્યાદિત છે, અને સ્ક્રિપ્ટ ચલાવતા વિકલ્પો એ શ્રેણીઓમાં છે જે સર્વરને આપવાની પરવાનગી નથી. એ મર્યાદા એટલા માટે છે કે વૈકલ્પિક રીતે સમાધાન થયેલું કે ખોટી રીતે કન્ફિગર કરેલું સર્વર ક્યારેય કનેક્ટ થતા દરેક ક્લાયન્ટ પર મનસ્વી આદેશો ચલાવી શકે.

સ્થાનિક રીતે સ્ક્રિપ્ટ ચલાવવાનું સક્ષમ કરવાથી તે બદલાતું નથી. તમારું script-security સેટિંગ તમે પસંદ કરેલી સ્થાનિક સ્ક્રિપ્ટોને મંજૂરી આપે છે; તે સર્વરને નવી પૂરી પાડવાનો અધિકાર આપતું નથી.

જો ધ્યેય ફક્ત VPN રૂટ ઇન્સ્ટોલ કરવાનો હોય, તો દૂરસ્થ એક્ઝિક્યુશન યોજના શોધવાને બદલે સમર્થિત રૂટ કન્ફિગરેશન વાપરો. જો ધ્યેયને ખરેખર સ્થાનિક કોડની જરૂર હોય, તો સંસ્થાના એન્ડપોઇન્ટ મેનેજમેન્ટ સાધનો દ્વારા તેનું વિતરણ કરો અને વપરાશકર્તાના અધિકારો સાથે ચાલતા અન્ય કોઈપણ સોફ્ટવેરની જેમ તેની સમીક્ષા કરો.

બંનેમાંથી કોઈ પણ હૂક પર ભરોસો કરતા પહેલાં શું ચકાસવું

દરેક હૂક માટે ચાર વસ્તુઓ લખો: મશીન, ઘટનાનું નામ, જે ખાતા હેઠળ તે ચાલે છે, અને જે સ્ટેટ ફેરફાર તે ઉત્પન્ન કરવાનો છે. પછી કનેક્શન, પુનઃકનેક્શન અને સફાઈનો માર્ગ ચકાસો, કારણ કે પુનઃકનેક્શન વખતે સ્ટેટ લીક કરતો હૂક ક્યારેય ન ચાલ્યા હૂક કરતાં પણ ખરાબ છે.

ખરેખર તેને ચલાવનારા ખાતા હેઠળ, ખરેખર ચાલશે તે ક્ષણે ચકાસો. openvpn(8) મેન્યુઅલ બંને હૂક પરિવારો અને push મર્યાદાઓનું દસ્તાવેજીકરણ કરે છે; તમે જે પ્લેટફોર્મ પર તૈનાત કરો છો તે દસ્તાવેજીકરણ કરે છે કે તે એ બિલકુલ આપે છે કે નહીં. ઇન્ટરેક્ટિવ એડમિનિસ્ટ્રેટર ટર્મિનલમાં સફળ થતી સ્ક્રિપ્ટ એ ધારણા છે, ચકાસણી નહીં.

સંબંધિત લેખો