پنگ واچ ڈاگ ٹوٹی سرنگ کو صحت مند سرنگ سے الگ نہیں کر سکتا

تین شرطیں طے کرتی ہیں کہ واچ ڈاگ مدد کرتا ہے یا نقصان: جانچ کیا الگ کر سکتی ہے، کتنی مسلسل ناکامیاں اقدام کو جائز ٹھہراتی ہیں، اور اقدام دوبارہ جڑنا ہے یا تبدیلی۔ عوامی پتے پر پنگ کرنے والی 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 سرور کا اپنا عوامی پتہ نہ جانچیں۔ وہ جانچ اسی چیز پر منحصر ہے جسے آزماتی ہے، اور اس راستے کے چلے جانے کے بعد بھی کامیابی کی اطلاع دیتی ہے جس کی تصدیق کرنی تھی۔

کون سی جانچ چلی، کیا واپس کیا اور کون سا قدم آیا، یہ درج کریں۔ وہ ریکارڈ پراسرار دوبارہ جڑنے کو تشخیص کے قابل واقعے میں بدل دیتا ہے۔