કેમ બૂટ વખતે શરૂ થતી VPN સેવા તમારી કીરિંગ વાંચી શકતી નથી

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

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

બૂટ માર્ગ ખરેખર શું માંગે છે

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

નિષ્ફળતા કીરિંગમાં છુપાયેલી નથી, કનેક્શનમાં જ લખાયેલી છે.

કનેક્શન પરના સિક્રેટ ફ્લેગ વાંચવા

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

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

nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
nmcli connection show "Work VPN" | grep -i -E "password|secret|key"
journalctl -b -u NetworkManager --grep "secret"

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

કેમ કનેક્શનને સિસ્ટમ સ્કોપમાં ખસેડવાથી જવાબ બદલાય છે

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

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

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

શું ન કરવું, અને તેના બદલે શું કરવું

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

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

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