OpenVPN client-connect હૂક: તમારું સરનામું ખરેખર ક્યાં જાય છે

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

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

હૂક ફાઇલ લખે છે, પરત મૂલ્ય નહીં

ઘોષણા બે લીટીની છે: કૉલને મંજૂરી આપવા script-security 2, પછી client-connect /etc/openvpn/server/assign-address.sh. જ્યારે ક્લાયંટ પ્રમાણીકરણ કરે છે, ત્યારે સર્વર તે સ્ક્રિપ્ટને જનરેટ કરેલ ફાઇલ પાથ છેલ્લા આર્ગ્યુમેન્ટ તરીકે ઉમેરીને ચલાવે છે, જે $1 ત્યારે જ હોય છે જ્યારે ઘોષણા પોતાના કોઈ વધારાના આર્ગ્યુમેન્ટ પાસ ન કરે. તે ક્લાયંટ પર લાગુ થતું બધું તે ફાઇલમાં સામાન્ય નિર્દેશો તરીકે, દરેક લીટીમાં એક, બરાબર એવી જ રીતે જાય છે જેવા તે કન્ફિગરેશનમાં દેખાયા હોત. પોતાના પરિમાણો ઉમેરતું રેપર સ્થાન ખસેડે છે, અને લાક્ષણિક લક્ષણ એવી સ્ક્રિપ્ટ છે જે --verbose જેવા દેખાતા પાથ પર લખે છે.

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

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

ઇનપુટ પર્યાવરણ ચલો દ્વારા આવે છે: common_name, trusted_ip, ifconfig_pool_remote_ip અને બાકીના. તેમને બધાને સર્વરની બહારની શબ્દમાળાઓ તરીકે ગણો, ક્યારેય શેલના ટુકડા તરીકે નહીં.

સરનામા મેપિંગ એ નીતિ છે, ગણિત નહીં

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

જે નામ નિયંત્રિત કરે છે તે સરનામું નિયંત્રિત કરે છે, તેથી આ ડિપ્લોયમેન્ટમાં common_name ખરેખર શું રજૂ કરે છે તે નક્કી કરો. username-as-common-name સક્ષમ હોય ત્યારે ઓળખ લોગિન છે, સર્ટિફિકેટ સબ્જેક્ટ નહીં. તે મૂલ્ય ક્યારેય શેલ મૂલ્યાંકનમાં પાસ કરશો નહીં, અને ક્લાયંટને ક્યારેય ફાઇલ પાથ પર પ્રભાવ પાડવા દેશો નહીં.

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

ટોપોલોજી નક્કી કરે છે કે ifconfig-push નો અર્થ શું છે

10.77.0.0/24 પર topology subnet સાથે, ifconfig-push 10.77.0.20 255.255.255.0 એ સરનામું અને તેનો નેટમાસ્ક છે. topology net30 હેઠળ બીજું આર્ગ્યુમેન્ટ નેટમાસ્ક જ નથી પણ પીઅર સરનામું છે, તેથી સબનેટ સ્વરૂપને net30 સર્વર પર કૉપિ કરવાથી તમને જોડાય છે પણ ટ્રાફિક પસાર કરી શકતું નથી એવું ક્લાયંટ મળે છે. ટોપોલોજી જાણી જોઈને બદલો, ક્યારેય ઉદાહરણ સુસંગત દેખાય તે માટે નહીં. જે સર્વર પહેલેથી net30 પર ચાલે છે તેની પાસે જૂના એડ્રેસિંગ પર જીવંત ક્લાયંટ છે, તેથી સ્વિચ એ જાળવણી વિન્ડો સાથેનું સ્થળાંતર છે, એક લીટીનું સંપાદન નહીં.

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

તેના પર ભરોસો કરતા પહેલાં ચાર કેસ ચકાસો

સમાન ચકાસણીઓ મેપ કરેલી ઓળખ, મેપ ન કરેલી, પુનઃજોડાણ અને અનુકરણ કરેલી રજિસ્ટ્રી નિષ્ફળતા સામે ચલાવો. openvpn --config client.ovpn --verb 4 પુશ જવાબમાં ફાળવેલું સરનામું બતાવે છે, અને સર્વર પર grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log ખરેખર શું મોકલાયું તેની પુષ્ટિ કરે છે. મેપ ન કરેલી ઓળખ માટે અપેક્ષિત પરિણામ નકારાયેલું કનેક્શન છે, પૂલનું સરનામું નહીં.

પછી જે ડિરેક્ટરીમાં ડીમન તે કામચલાઉ ફાઇલો લખે છે તેની તપાસ કરો. સ્ક્રિપ્ટ નીચે ઉતારેલી સેવા સંદર્ભમાં ચાલે છે, તેથી root લખી શકે પણ ડીમન ન લખી શકે એવો પાથ દરેક કનેક્શનને લોગમાં ઘણી લીટી નીચે દટાયેલી પરવાનગી ભૂલ સાથે નકારમાં ફેરવે છે.

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