OpenVPN ને પ્રોફાઇલ લોડ થવા છતાં ca.crt મળતું નથી

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

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

પ્રોફાઇલનો પાથ બેઝ ડિરેક્ટરી નથી

/tmp માં શરૂ થતી અને /etc/vpn/prod/tenant-a.ovpn મેળવતી પ્રક્રિયાની કલ્પના કરો. તે પ્રોફાઇલની અંદર, ca ca.crt લાઇન સાપેક્ષ પાથ દર્શાવે છે. પ્રોફાઇલ શોધનારા આર્ગ્યુમેન્ટમાં કંઈ પણ તે નામ ફરી લખતું નથી, તેથી પ્રક્રિયા /tmp/ca.crt શોધે છે અને ખૂટતી ફાઇલની જાણ કરે છે.

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

મેન્યુઅલ શું અલગ પાડે છે: --config અને --cd

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

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

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

સેવા બીજે જ ઠેકાણે શરૂ થાય છે

પ્રોફાઇલ ડિરેક્ટરીમાંનો ઇન્ટરેક્ટિવ શેલ પેકેજ થયેલી unit વિશે કંઈ સાબિત કરતો નથી. મેનેજરો પોતાની કાર્યકારી ડિરેક્ટરી નક્કી કરે છે, અને રેપર સ્ક્રિપ્ટ બાઇનરી ચાલે તે પહેલાં તેને ફરી બદલી શકે છે. નિષ્ફળ જતી unit એ જ એકમાત્ર લોન્ચ છે જેના વિશે વિચારવા યોગ્ય છે.

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

બીજો આદેશ જીવંત પ્રક્રિયા ખરેખર જે ડિરેક્ટરી પકડી રાખે છે તે દર્શાવે છે, અને રેપર સંડોવાયેલું હોય ત્યારે તે unit ફાઇલ કરતાં વધુ ભરોસાપાત્ર છે. જો બંને મળતા ન હોય, તો જવાબ રેપર છે અને unit ભ્રામક નિશાન છે.

શોધ પછી: પરવાનગીઓ, chroot અને સેન્ડબોક્સ

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

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

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

તમારા પોતાના લોન્ચ સાથે સુધારો સાબિત કરો

પ્રોફાઇલ સાથે સંબંધ ન ધરાવતી ડિરેક્ટરીમાંથી સાચી unit ફરી શરૂ કરો અને એ જ સ્ટાર્ટઅપ લાઇન જુઓ. પછી ખાતરી કરો કે પ્રક્રિયા ચાલતી વખતે ઇચ્છિત ડિરેક્ટરી પકડી રાખે છે અને તેણે લોડ કરેલું પ્રમાણપત્ર તમે અપેક્ષા રાખો છો તે જ છે.

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

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

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