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

અંતરાલને સંખ્યામાં ફેરવો

પાંચ કે છ ઘટનાઓ એકઠી કરો અને તેમની વચ્ચેનું અંતર ગણો, દિવસની શરૂઆતથી નહીં. 09:12, 10:12 અને 11:12 પરનું ડિસ્કનેક્શન કલાકની સીમા છે; 09:12, 09:27 અને 09:42 પરનું ડિસ્કનેક્શન છેલ્લા સફળ કનેક્શનથી પંદર મિનિટ છે. પરિણામને નજીકની મિનિટમાં નહીં, સૌથી સંભવિત ટાઇમરમાં ગોળ કરો.

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

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

એકસરખા દેખાતા ચાર ટાઇમર

લગભગ દરેક પુનરાવર્તિત ટનલ પતન આમાંથી એકમાંથી આવે છે: પ્રોટોકોલ કી રિન્યુઅલ, નિષ્ક્રિય મેપિંગની સમાપ્તિ, DHCP અથવા ઇન્ટરફેસ ઘટના, અથવા એકાઉન્ટ નીતિ. ટ્રાફિક વહેતો હતો કે નહીં અને સીમા પર લોગ શું કહે છે તેમાં તેઓ અલગ પડે છે.

નીચેની સહીઓ શીખવા લાયક છે, કારણ કે તે એક જ લોગ લાઇનથી ત્રણ સમજૂતીઓને નકારવા દે છે:

TimerTypical triggerWhat the log shows at the boundary
Protocol rekeyTraffic present, fixed intervalNegotiation lines, sometimes a failure
NAT or firewall idleNo traffic for minutesSilence, then a timeout on send
DHCP lease or link changeHalf the lease, or a radio eventAddress or interface churn
Account session limitWall-clock hours since loginClean disconnect, server-side reason

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

વ્યસ્ત વિરુદ્ધ નિષ્ક્રિય કહે છે કયો અડધો ભાગ

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

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

પરીક્ષણ દરમિયાન એક્સેસ નેટવર્ક અપરિવર્તિત રાખો. સરખામણી વચ્ચે Wi-Fi અને Ethernet વચ્ચે ફેરવવાથી બરાબર એ જ ઇન્ટરફેસ ઘટના આવે છે જેને તમે ટાઇમરથી અલગ પાડવા માગો છો.

લોગ લાઇનને સીમા સાથે મેળવો

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

આ આદેશો દરેક સ્રોતમાંથી સંબંધિત વિન્ડો ખેંચે છે:

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

જો ત્રણેય સ્રોત સમયચિહ્ન પર સહમત હોય, તો ટાઇમરનો માલિક તમે જાણો છો. જો ફક્ત ક્લાયન્ટ લોગમાં કંઈક હોય, તો સંભવતઃ સર્વર સત્ર સમાપ્ત કરનારું નથી.

તબક્કો સુધારો, આઇકન નહીં

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

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

સંબંધિત લેખો