VPN લોગ માટે journalctl: કયું યુનિટ કનેક્શન ધરાવે છે?

તમને યાદ હોય તે લોગ આદેશથી નહીં, પણ જે systemd યુનિટ ખરેખર VPN કનેક્શન ધરાવે છે તેનાથી શરૂ કરો. સીધી OpenVPN સેવા, wg-quick યુનિટ અને NetworkManager પ્રોફાઇલ તેમના ઉપયોગી સંદેશા જુદા જુદા યુનિટમાં મૂકે છે, અને ખોટા યુનિટ સામેની ક્વેરી ખાલી પરિણામ આપે છે જે મૌન જેવું લાગે. ત્રણ સામાન્ય માલિકોની સરખામણી કરો, વિન્ડો સાંકડી કરો, પછી તબક્કા ક્રમમાં વાંચો.

ત્રણ સામાન્ય માલિકોની સરખામણી કરો

OpenVPN ક્લાયન્ટ સેવા સામાન્ય રીતે પ્રોફાઇલના નામ પરનું ઇન્સ્ટન્સ યુનિટ હોય છે, જેમ કે [email protected]. તેના સંદેશામાં કન્ફિગરેશન પાથ, વિકલ્પોનું પદચ્છેદન, TLS હેન્ડશેક અને ક્લાયન્ટ જે રૂટ ઇન્સ્ટોલેશન કરે છે તેનો સમાવેશ થાય છે.

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

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

ક્વેરીને એક યુનિટ અને એક વિન્ડો સુધી સાંકડી કરો

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

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

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

પ્રથમ નિષ્ફળ તબક્કો વાંચો

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

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

નિષ્ફળ સેવાને હાથે ચલાવેલા ક્લાયન્ટ સાથે ભેગી ન કરો

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

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

એક્સપોર્ટ નહીં, અંશ શેર કરો

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

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