OpenVPN પ્રોફાઇલમાંથી key-method દૂર કરવાથી કંઈ બદલાતું નથી

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

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

લક્ષણ પાર્સ ભૂલ છે, હેન્ડશેક નિષ્ફળતા નહીં

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

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

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

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

નિર્દેશ અને વાયર ફોર્મેટ બે અલગ વસ્તુઓ છે

જૂનો key-method વિકલ્પ પસંદ કરતો કે TLS કી-એક્સચેન્જ કેવી રીતે ફ્રેમ થાય, અને આધુનિક એક્સચેન્જ એ બહુ-પેકેટ પદ્ધતિ છે જે તે વિકલ્પ પહેલાં માંગતો હતો. વિકલ્પ ચાલ્યો ગયો કારણ કે તે હવે કંઈ પસંદ કરતો ન હતો; જે ફોર્મેટનું તે નામ આપતો તે એકમાત્ર બની ગયું. તેથી લીટી દૂર કરવાથી સેશન પહેલાં જેવી જ ફ્રેમિંગ સાથે રહે છે. ટેક્સ્ટ સંપાદન કોઈ પણ દિશામાં તેને બદલી શકતું નથી.

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

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

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

શું દૂર કરવું, અને કઈ ફાઇલમાંથી

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

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

પછી ઇચ્છિત ઇન્સ્ટન્સ શરૂ કરો અને તેનું સ્ટાર્ટઅપ આઉટપુટ વાંચો. શ્રોતા હાજર હોય તેવી સ્વચ્છ શરૂઆત એ આ તબક્કો પૂરો થયાની પુષ્ટિ છે; પછીની ક્લાયન્ટ કસોટી બીજા પ્રશ્નનો જવાબ આપે છે.

નકારેલી પ્રોફાઇલ અને નકારેલો ક્લાયન્ટ એકસરખા દેખાય છે

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

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

સુસંગતતાના એ પ્રશ્નો જેનો લીટીએ કદી જવાબ આપ્યો નહીં

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

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

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