એક VPN લોગમાં ત્રણ ઘડિયાળો: ક્લાયન્ટ, ગેટવે, સંગ્રાહક

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

દંતકથા: VPN પાસે એક જ ઘડિયાળ છે

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

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

મૂલ્ય પહેલાં સ્રોત વાંચો

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

journalctl -o short-iso --utc -n 20
logger -t vpn-check "test event"

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

કયા ઘટકે ક્ષેત્ર લખ્યું તે કહી ન શકો તો થોભો. તેની બીજા કોઈપણ વસ્તુ સાથે તુલના કરવી એ અનુમાન છે.

સમય વિસ્તારનું દર્શન અલગ ક્ષણ નથી

એ જ ક્ષણ 10:00Z અને 18:00+08:00 તરીકે દર્શાવવી એ કોઈ વિસંગતિ નથી, અને તેને વિસંગતિ ગણવાથી અડધો દિવસ વેડફાય છે. તુલના કરતા પહેલાં બંનેને UTCમાં બદલો, અને મૂળ લખાણ રૂપાંતરણની બાજુમાં રાખો. એક તરફ દશાંશ અપૂર્ણાંક અને બીજી તરફ પૂર્ણ સેકન્ડ હોવી પણ સંઘર્ષ નથી. ચોકસાઈ એ સચ્ચાઈ નથી: મિલિસેકન્ડવાળું મૂલ્ય પણ એવી ઘડિયાળમાંથી આવી શકે જે મિનિટો જેટલી ખોટી હોય.

date -u +%FT%TZ
timedatectl

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

પુરાવા ફરીથી લખ્યા વિના સહસંબંધ કરો

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

chronyc tracking
journalctl --utc -u openvpn-client@work -n 50 --no-pager

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

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