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

પગલું 1: આ સંખ્યાનો અર્થ શું છે તે વાંચો

ભૂલ 77 સ્થાનિક CA ઇનપુટ વિશે છે: curl એ પ્રમાણપત્ર સામગ્રી વાંચી કે લોડ કરી શક્યું નહીં જેનાં પર ભરોસો કરવાનું કહેવાયું હતું. ભૂલ 60 સામેની બાજુ વિશે છે, જ્યારે સર્વરની શૃંખલા માન્ય થતી નથી. ટ્યુટોરિયલમાં બંને એકબીજાની બાજુમાં આવે છે અને વિરોધી અર્થ ધરાવે છે.

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

પગલું 2: તમે કોપી કરેલો આદેશ વાંચો

કોપી કરેલા આદેશ અક્ષરો છુપાવે છે. નાનો -l એટલે --list-only, જે પ્રોટોકોલની યાદી માટે લાગુ પડે છે. મોટો -L એટલે --location, જે HTTP રીડાયરેક્ટને અનુસરે છે. આ વૈકલ્પિક જોડણી નથી, અને જે ટ્યુટોરિયલ એક લખે છે જ્યારે બીજાનું વર્ણન કરે છે તે લોકોને એવા રીડાયરેક્ટ માર્ગે મોકલે છે જે ક્યારેય ઇરાદાપૂર્વક ન હતો.

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

પગલું 3: તે બિલ્ડ કયું CA ઇનપુટ વાપરે છે તે શોધો

બાઇનરી ઓળખીને શરૂ કરો, કારણ કે જવાબ તે કેવી રીતે કમ્પાઇલ થયું તેના પર આધાર રાખે છે:

curl --version

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

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

પગલું 4: ઇનપુટ સુધારો, ચકાસણી નહીં

સમર્થિત ટ્રસ્ટ કન્ફિગરેશન તેના માલિક દ્વારા પુનઃસ્થાપિત કરો: ડિસ્ટ્રિબ્યુશન પેકેજ, તમારું કન્ફિગરેશન મેનેજમેન્ટ, અથવા દસ્તાવેજીકૃત એન્વાયર્નમેન્ટ ચલ. ધ્યેય તે બાઇનરી માટે વાંચી શકાય તેવું અને સાચું CA ઇનપુટ છે.

URL ને HTTP માં બદલશો નહીં, --insecure ઉમેરશો નહીં, અને અસ્પષ્ટ ડાઉનલોડમાંથી કોપી કરેલા પ્રમાણપત્ર પર ભરોસો કરશો નહીં. આમાંનો દરેક ફેરફાર curl વાંચી ન શક્યું તે સુધારવાને બદલે તમે શું સ્વીકારવા તૈયાર છો તે બદલે છે, અને ફેરફાર સામાન્ય રીતે ઘટનાથી વધુ ટકે છે.

સંખ્યાઓ માટે સંદર્ભ છે curl ભૂલોની સૂચિ, અને તે એક વાર ધ્યાનથી વાંચવા માટે પૂરતી ટૂંકી છે.

પગલું 5: ડાઉનલોડ કરો, જુઓ, પછી ચલાવો

ઇન્સ્ટોલરને એક જ આદેશમાં shell માં પાઇપ કરવાને બદલે ફાઇલમાં લાવો. એક જ ફેરફાર તમે તપાસી શકો તેવા સ્થાનાંતરણને તમારા વિશેષાધિકારો સાથે ચાલતા કોડથી અલગ કરે છે.

curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.sh

ચકાસો કે પ્રતિસાદ તમે અપેક્ષા રાખેલી સ્ક્રિપ્ટ છે, HTML ભૂલ પૃષ્ઠ, રીડાયરેક્ટ સૂચના કે ખાલી ફાઇલ નથી. જો પ્રકાશક ચેકસમ કે સહી આપે છે, તો તેને તેમની દસ્તાવેજીકૃત રિલીઝ પ્રક્રિયા દ્વારા ચકાસો, તે જ ફોરમ થ્રેડમાં ટાંકવામાં આવેલા મૂલ્ય દ્વારા નહીં.

HTTPS એ શું કર્યું અને શું નહીં તે યાદ રાખો. તેણે તમે સંપર્ક કરેલા હોસ્ટ સુધીના પરિવહનને પ્રમાણિત કર્યું; તેણે સ્ક્રિપ્ટની સામગ્રીની સમીક્ષા કરી નથી, અને તે તમને કહેતું નથી કે પ્રકાશક ભરોસાપાત્ર છે કે નહીં.

પગલું 6: ઇન્સ્ટોલના પગલાં અલગ રાખો

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

જો ઇન્સ્ટોલ સફળ થાય અને ટનલ ઉપર આવે, તો ટિકિટ બંધ કરતા પહેલાં રૂટ અને એક વાસ્તવિક ગંતવ્ય ચકાસો. curl ભૂલ ત્યારે સુધરે છે જ્યારે સાદું curl -I https://example.invalid ફરી કામ કરે, જ્યારે ઇન્સ્ટોલર ફરિયાદ કરવાનું બંધ કરે ત્યારે નહીં.

સંબંધિત લેખો