Պինգ-պահակը չի տարբերում կոտրված թունելը առողջից

Երեք պայման է որոշում՝ պահակը օգնում է, թե վնասում. ինչ կարող է տարբերել ստուգումը, քանի հաջորդական ձախողում է արդարացնում գործողությունը, և արդյոք գործողությունը վերակապակցում է, թե փոփոխություն։ Հանրային հասցեն պինգող cron տողը լավ չի պատասխանում դրանցից ոչ մեկին։ Այն վերակապակցում է առողջ թունելները և թողնում է կոտրվածները, և երկուսն էլ անում է առանց որևէ գրառման։ Պահպանման արժանի ձևավորումը այս երեք ընտրությունները դարձնում է բացահայտ։

Ստուգումն այն մասն է, որ որոշում է մնացած ամեն ինչ։

Ինչ է իրականում ապացուցում ինտերնետին ուղղված պինգը

Հանրային լուծիչին պինգ անելը ցույց է տալիս, որ տեղական ինտերնետ ուղին կենդանի է։ Այն չի ապացուցում, որ թունելը տրաֆիկ է տեղափոխում, և ամբողջական թունելի պրոֆիլում պինգն ինքն անցնում է թունելով, ուստի առողջ պատասխանը և կոտրված թունելը կարող են գոյություն ունենալ միաժամանակ, մինչ հաճախորդը դեռ փոխանցում է փաթեթները։ Եթե պրոֆիլը անունների որոնումներն ուղարկում է թունելով, DNS-ի ձախողումը կարդացվում է որպես մեռած կապ և սկսում է վերակապակցում, որը ոչինչ չի կարող ուղղել։

Սխալի երկու ուղղություններից ոչ մեկը չի հայտնվում ելքի կոդում։ Այդ ազդանշանի վրա կառուցված պահակը cron ժամանակացույցով մետաղադրամ նետելն է։

Ստուգեք մի բան, որ ապրում է թունելի հետևում

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

Ստուգեք ներսից, ամենաէժան ստուգումը սկզբում։ Ինտերֆեյսի առկայությունը ասում է, որ թունելը վերևում է. ծանոթ ներքին հասցեի երթուղու որոնումը ասում է, որ տրաֆիկը կմտնի այնտեղ. մյուս կողմի հոսթին ուղղված TCP ստուգումը ասում է, որ ինչ-որ բան իրոք պատասխանում է։ Միայն echo հարցումները մոլորեցնում են. շատ ներքին հոսթեր սիրով պատասխանում են 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 սերվերի սեփական հանրային հասցեն ամբողջական թունելի ներսից։ Այդ ստուգումը կախված է հենց այն բանից, ինչ ստուգում է, և հաջողություն է հաղորդում, երբ այն ուղին, որ պետք է հաստատեր, արդեն չկա։

Գրանցեք, թե որ ստուգումն է աշխատել, ինչ է վերադարձրել և ինչ գործողություն է հաջորդել։ Այդ գրառումը առեղծվածային վերակապակցումը դարձնում է ախտորոշելի իրադարձություն։