OpenVPN પ્રથમ લીટી નકારે છે? ફાઇલ સંભવતઃ UTF-16 છે

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

દંતકથા: એડિટર તમને ફાઇલ બતાવે છે

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

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

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

પ્રથમ બાઇટ ખરેખર શું કહે છે

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

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

તમે જે પેટર્ન શોધો છો તે શરૂઆતના બે બાઇટની જોડ છે, જે પછી એવું લખાણ આવે છે જેમાં દર બીજો બાઇટ શૂન્ય હોય. FF FE UTF-16 લિટલ-એન્ડિયન દર્શાવે છે, FE FF બિગ-એન્ડિયન દર્શાવે છે, અને EF BB BF બાઇટ-ક્રમ ચિહ્ન સાથે UTF-8 દર્શાવે છે. ચિહ્ન વગરની સામાન્ય UTF-8 ફાઇલ સીધી પ્રથમ અક્ષરના બાઇટથી શરૂ થાય છે.

અક્ષરો વચ્ચેના શૂન્ય બાઇટ એ મુખ્ય સંકેત છે. UTF-16 લિટલ-એન્ડિયનમાં client શબ્દ છ નહીં પણ બાર બાઇટ લે છે, કારણ કે દરેક ASCII અક્ષર પછી શૂન્ય આવે છે. એ રચના એડિટરનું દર્શન તમને બતાવી શકતું નથી, અને બે બાઇટ ભૂંસવાથી પણ તે દૂર થતી નથી.

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

સુધારેલું એન્કોડિંગ શું સુધારતું નથી

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

પછી ખરેખર એન્કોડિંગ રૂપાંતરણ કરો, કાં તો એડિટરના સ્પષ્ટ એન્કોડિંગ મેનૂ દ્વારા, અથવા એવા કન્વર્ટર દ્વારા જે તેનું ઇનપુટ અને આઉટપુટ એન્કોડિંગ જણાવે છે:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

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

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

સુધારેલું એન્કોડિંગ શું સુધારતું નથી તે વિશે

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

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

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