0x કે 0s? ipsec.secrets માં PSK ફોર્મેટ સમજવું

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

લક્ષણ એન્કોડિંગ તરફ ઇશારો કરે છે, સાઇફર તરફ નહીં

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

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

એક રહસ્ય, ફાઇલ તેને વાંચી શકે તેવી ત્રણ રીતો

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

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

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

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

Base64 લખાણ ક્યાંથી આવે છે

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

બંને દિશા એક-એક આદેશ છે, અને જે ચોક્કસ ક્રિયાએ સંગ્રહિત મૂલ્ય બનાવ્યું તે તરીકે તેમને ટિકિટમાં રાખવા યોગ્ય છે. તેમને આ ક્રમમાં ચલાવો:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

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

દરેક સાથી ખરેખર કયા બાઇટ વાપરે છે તેની ખાતરી કરો

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

ફાઇલ સાચી થયા પછી ફરી શરૂ કરવાને બદલે ફરી લોડ કરો. ipsec rereadsecrets IKE ડેમનની નકલ તાજી કરે છે, અને swanctl સેટઅપ તેના પોતાના આદેશથી ક્રેડેન્શિયલ લોડ કરે છે. ફરી શરૂ કરવાથી દરેક સ્થાપિત સંગઠન છોડી દેવાય છે અને તમે કરવા માગતી સરખામણી નષ્ટ થાય છે.

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

પરિણામ છુપાવ્યા વિના ફાઇલ બદલો

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

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