પિંગ વોચડોગ તૂટેલી ટનલને સ્વસ્થ ટનલથી અલગ ન કરી શકે

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

ચકાસણી એ ભાગ છે જે બાકીનું બધું નક્કી કરે છે.

ઇન્ટરનેટ પર પિંગ ખરેખર શું સાબિત કરે છે

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

ભૂલની બંને દિશાઓમાંથી એક પણ એક્ઝિટ કોડમાં દેખાતી નથી. તે સંકેત પર બનેલો વોચડોગ cron સમયપત્રક સાથેનો સિક્કો ઉછાળવો છે.

ટનલની પાછળ રહેતી કોઈ વસ્તુ ચકાસો

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

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

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

એક લાઇન અને લૂપ વચ્ચે પસંદ કરો

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

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

failures=0
while sleep 30; do
  if nc -z -w5 10.100.20.10 443; then failures=0
  else failures=$((failures+1)); fi
  if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi
done

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

ફેરફાર એ અલગ નિર્ણય છે

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

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

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