keepalive دوبارہ رابطہ نہیں: اپنی موجودہ خرابی کے مطابق چنیں

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

جب نقشہ ہی مسئلہ ہو

صرف چند منٹ کی خاموشی کے بعد مرنے والا سرنگ عام طور پر ساتھی نہیں بلکہ ترجمے کا اندراج کھوتا ہے۔ WireGuard کا PersistentKeepalive NAT اور فائر وال کی حالت کے لیے موجود ہے، اور خود منصوبے کے نوٹس اسے بالکل اسی طرح بیان کرتے ہیں، صحت کی جانچ کے طور پر نہیں۔ چند درجن سیکنڈ کا وقفہ اندراج کو گرم رکھتا ہے، جبکہ ہر سیکنڈ ایک پیکٹ بیٹری کا فیصلہ ہے، بھروسے کا نہیں۔ OpenVPN اسی جگہ پہنچتا ہے ping اور ping-restart کے ذریعے، جو پہلے خاموشی نوٹ کرتے ہیں اور پھر اس پر عمل کرتے ہیں۔

یہ ترتیبات پروٹوکول کے درمیان بھی بدلی نہیں جا سکتیں۔ IKEv2 کی مردہ ساتھی پالیسی، OpenVPN کا ping ٹائمر اور WireGuard کا keepalive ایک ہی سوال کا جواب تین مختلف نحوی ڈھانچوں اور تین مختلف طے شدہ قدروں کے ساتھ دیتے ہیں، اس لیے ان کے درمیان عدد نقل کرنا ترتیب کے لباس میں اندازہ ہے۔

جب تعلق ختم ہو جائے

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

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

دونوں میں سے کوئی کیا ثابت نہیں کرتا

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

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

براہ راست ٹریفک کو روکنا الگ فیصلہ ہے

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

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

پالیسی لکھیں، صرف عدد نہیں

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

حدود کے بارے میں WireGuard کے نوٹس ایک مفید یاد دہانی ہیں کہ keepalive درمیانی ڈبوں کے لیے ایک بچاؤ راستہ ہے، زندگی کا عمومی ڈیزائن نہیں۔ جس مسئلے کو یہ حل نہیں کر سکتا اس کے جواب میں تعدد بڑھانے سے پہلے وہ حد پڑھیں۔