سائٹ ٹنل کی واپسی کے بعد فال بیک لیز: تجدید کریں یا انتظار کریں؟

سائٹ لنک فعال ہے، ٹنل قائم ہے، پھر بھی برانچ کے کمپیوٹر فائل سرور تک نہیں پہنچ پاتے۔ خلل کے دوران دو گھڑیاں چل رہی تھیں اور ان میں سے صرف ایک مکمل ہوئی ہے۔ خفیہ کردہ راستہ واپس آنے پر ٹنل بحال ہوا؛ ہر کلائنٹ کا پتہ اس وقت بحال ہوتا ہے جب اس کی موجودہ لیز ختم ہو یا بدل دی جائے۔ ان دو وقت کی لکیروں کا موازنہ فائر وال لاگ پڑھنے سے زیادہ تیزی سے فرق کی وضاحت کرتا ہے۔

دو گھڑیاں، اور ان میں سے ایک ٹنل نہیں

VPN پر DHCP اور مقامی فال بیک کے ساتھ، آلہ دور دراز کے DHCP راستے کے دستیاب نہ ہونے پر عارضی مقامی لیز جاری کر سکتا ہے۔ عارضی مدت عام طور پر منٹوں میں شمار ہوتی ہے، جو مسئلہ چھپانے کے لیے کافی مختصر اور مختصر خلل سے گزرنے کے لیے کافی طویل ہے۔ ٹنل واپس آنے پر فال بیک ان لیز کی پیشکش بند کر دیتا ہے۔ یہ کسی کلائنٹ کے اندر جا کر اس کی پہلے سے موجود لیز منسوخ نہیں کرتا۔ وہ کلائنٹ اپنا پتہ، ماسک، گیٹ وے اور حل کنندہ تجدید یا میعاد ختم ہونے تک رکھتا ہے، اسی لیے ایک صحت مند ٹنل اور خراب ڈیسک ٹاپ لیز کے باقی وقت تک اکٹھے رہ سکتے ہیں۔

عمل درآمد اور سافٹ ویئر ورژن کو اس بیان سے منسلک رکھیں۔ ٹائمر کے نام اور طے شدہ اقدار SonicOS کے ورژنوں کے درمیان مختلف ہوتی ہیں، اور پرانا انٹرفیس ثابت نہیں کرتا کہ نیا کیا کرتا ہے۔

بحالی کے دو اقدامات کا موازنہ کریں

اقدام A انتظار کرنا ہے۔ اس میں کوئی خرچ نہیں، کوئی خطرہ نہیں، اور یہ ہر کلائنٹ کو اپنے شیڈول کے مطابق تجدید کرنے دیتا ہے۔ اقدام B متاثرہ کلائنٹ پر جبری رہائی اور تجدید کرنا ہے، جو مطلوبہ پتہ فوراً دے دیتا ہے مگر کلائنٹ کے ہر کام میں خلل ڈالتا ہے۔ ایک ہی ڈیسک ٹاپ پر جبری تجدید عام طور پر تیز تر راستہ ہے اور اس کا جواز پیش کرنا آسان ہے۔ لیبارٹری میں یا لین دین کے وسط میں واقع پوائنٹ آف سیل ٹرمینل پر انتظار زیادہ محفوظ انتخاب ہے، اور کام کے اوقات سے باہر طے شدہ تجدید دونوں کو پیچھے چھوڑ دیتی ہے۔

ipconfig /all
ipconfig /release
ipconfig /renew

کچھ بھی جاری کرنے سے پہلے آؤٹ پٹ پڑھیں۔ اگر پتہ، گیٹ وے اور DNS پہلے ہی معمول کے دائرے سے مطابقت رکھتے ہیں تو کلائنٹ خود بحال ہو گیا ہے اور باقی مسئلہ کہیں اور ہے۔ Linux کلائنٹ پر متبادل یہ ہے کہ ہاتھ سے ترمیم شدہ پتہ نہیں، بلکہ نیٹ ورک مینیجر کے ذریعے لیز کی رہائی اور تجدید کی جائے، ورنہ مینیجر اگلے واقعے میں آپ کی تبدیلی دوبارہ لکھ دے گا۔

پیشکش پڑھیں، صرف پتہ نہیں

پتہ اکیلا یہ نہیں بتاتا کہ یہ کس نے فراہم کیا۔ اہم بات پیشکش میں سرور کی شناخت، لیز کا وقت، اور یہ کہ گیٹ وے اور حل کنندہ فال بیک دائرے سے مطابقت رکھتے ہیں یا معمول سے۔

tcpdump -ni any 'port 67 or port 68'

تجدید کے دوران ریکارڈ کریں، کیونکہ خاموش انٹرفیس بتاتا ہے کہ کلائنٹ نے کبھی درخواست نہیں کی۔ اگر ٹنل فعال ہونے کے دوران پیشکش مقامی فال بیک سے آئے تو انتخاب کی منطق اب بھی دور دراز کے راستے کو دستیاب نہیں سمجھتی، اور کلائنٹس پر جبری تجدید صرف وہی نتیجہ دہرائے گی۔ ریکارڈ کو اسی گھڑی کے ٹنل واقعات سے منسلک کریں۔ کلائنٹ کی درخواست سے چند سیکنڈ پہلے ختم ہونے والی کلید کی تجدید یا مختصر کمی ممکنہ سبب ہے؛ صاف ٹنل کے ساتھ فال بیک جواب انتخاب کے راستے میں ترتیب کا مسئلہ ہے۔

جہاں موازنہ الٹ جاتا ہے

اگر ایک ساتھ بہت سے کلائنٹس متاثر ہوں تو فی کلائنٹ تجدید خلل کی قطار اور معاونت کی کال بن جاتی ہے۔ اس صورت میں کلائنٹس کے بجائے فال بیک دائرہ اور بحالی کا طریقہ کار دیکھیں، کیونکہ وہ گروہ اکٹھے بحال ہوا ہے اور دوبارہ اکٹھے بحال ہوگا۔

اگر صرف ایک کلائنٹ متاثر ہو جبکہ اس کے پڑوسی ٹھیک ہوں تو معاملہ الٹا ہے: اس کلائنٹ کی لیز، اس کی مختص کردہ جگہ یا اس کے اپنے DHCP کلائنٹ کا رویہ متغیر ہے، اور پوری سائٹ میں تبدیلی غلط اوزار ہے۔

مستقل پتوں اور مختص کردہ جگہوں کو تیسرا جواب درکار ہے۔ کسی پتے پر جکڑے کلائنٹ کو تجدید سے نہیں بچایا جا سکتا، اور فال بیک دائرے سے ٹکرانے والی مختص کردہ جگہ ایسی نقل پیدا کرتی ہے جو دو پتہ منصوبوں کا موازنہ کرنے تک روٹنگ کی خرابی جیسی لگتی ہے۔

خروج کا طریقہ کار لکھیں

پہلے سے طے کریں کہ فال بیک کس لیے ہے، کلائنٹ اپنا عارضی پتہ کتنی دیر رکھ سکتا ہے، اور کام کے اوقات میں کس کو تجدید جبری کرنے کی اجازت ہے۔ جواب وہاں لکھیں جہاں ڈیوٹی پر موجود انجینئر کو مل سکے، دائرے کی تعریف کے پاس۔ پھر ایک بار جان بوجھ کر آزمائیں: ٹنل گرائیں، دیکھیں کلائنٹ کو کیا ملتا ہے، ٹنل بحال کریں، اور لکھیں کہ کلائنٹ کو اپنی معمول کی سیٹنگز واپس لینے میں کتنا وقت لگتا ہے۔ وہی ایک مشق اگلی بار سائٹ لنک کے ڈگمگانے پر زیادہ تر اندازوں کی جگہ لے لیتی ہے۔

وسیلے کی تصدیق کر کے ختم کریں، پتے کی نہیں۔ فائل سرور تک پہنچنا، اس کا نام حل کرنا اور انٹرنیٹ تک پہنچنا تین الگ جانچیں ہیں، اور صرف آخری پر کبھی شک نہیں ہوا۔