VPN پر SSH ServerAliveInterval: تحقیقی پیغام کون سا سرا بھیجتا ہے؟

SSH نشست کو زندہ رکھنے کے بیشتر مشورے «ServerAliveInterval 30 شامل کریں» پر رک جاتے ہیں اور مفید حصے چھوڑ دیتے ہیں۔ کلیدی لفظ کلائنٹ کی طرف کا ٹائمر ہے جو صرف اسی وقت چلتا ہے جب چینل خاموش رہا ہو، یہ سیکنڈ نہیں بلکہ بغیر جواب والے پیغامات گنتا ہے، اور ایسی فائل میں رہتا ہے جہاں پہلی مماثل قدر جیتتی ہے۔ ان تین خصوصیات میں غلطی کریں تو صحت مند VPN نشست بھی ٹوٹ جائے گی، جبکہ مردہ نشست لٹکی رہے گی۔

دونوں سمتوں کا تعلق مختلف ڈیمان سے ہے

ServerAliveInterval آپ کا ssh کلائنٹ پڑھتا ہے۔ ClientAliveInterval دوسرے سرے کا sshd پڑھتا ہے اور اُلٹی سمت میں، سرور سے کلائنٹ کی طرف جانچ کرتا ہے۔ یہ متبادل نام نہیں ہیں اور ساتھ کام نہیں کرتے، اسی لیے ایک کو سیٹ کرنے کا دوسرے سرے کے رویے پر کوئی اثر نہیں ہوتا۔ انہیں آپس میں ملانا ہی وہ عام وجہ ہے کہ کوئی اصلاح ایک ہوسٹ پر کارآمد دکھتی ہے اور اگلے پر نہیں۔

دونوں صفر قبول کرتے ہیں۔ صفر پر کلائنٹ کچھ بھی نہیں بھیجتا، اور سرور کی طرف صفر والا ClientAliveCountMax اُس منقطعی کو بند کر دیتا ہے جو ورنہ بغیر جواب جانچ کے بعد آتا۔

تحقیقی پیغام کیا ثابت کرتا ہے اور کیا نہیں

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

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

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

کون سی قدر زندہ رہے گی یہ ترتیب طے کرتی ہے

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

کمانڈ لائن کے اختیارات فائل پر بھاری پڑتے ہیں، جس سے عارضی تجربہ سستا ہو جاتا ہے:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

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

ssh -G office-shell | grep -i alive

سرنگ پر کِیپ اَلائیو کیا کرتے ہیں

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

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

ملٹی پلیکس روابط ایک تہہ بڑھاتے ہیں۔ جب ControlMaster کھیل میں ہو تو تحقیقی پیغامات مرکزی رابطے کے ہوتے ہیں، اور موجودہ مرکزی پر نیا سیشن وہی ورثے میں لیتا ہے جو اُس مرکزی نے طے کیا تھا۔ اگر mux مرکزی پھنسا ہوا ہو تو دوسری ونڈو کھولنا راستہ دوبارہ نہیں جانچے گا۔

ترتیب کی تصدیق شروع سے آخر تک

سرور پر فائل پڑھ کر اندازہ لگانے کے بجائے کہ کون سا include جیتا، مؤثر ڈیمان کنفیگریشن ڈمپ کریں:

sshd -T | grep -i clientalive

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

صرف سرنگ کے ذریعے پہنچنے والے کسی بھی ہوسٹ کے لیے دو جانچیں شامل کرنا مناسب ہے: تصدیق کریں کہ حل شدہ وقفہ وہی ہے جو آپ کا ارادہ تھا، اور تصدیق کریں کہ وہ وقفہ گنتی سے ضرب دے کر VPN گیٹ وے پر غیر فعال ٹائم آؤٹ سے کم ہے۔ جب دوسرا عدد بڑا ہو تو گیٹ وے پہلے خاموشی سے بہاؤ پھینک دیتا ہے اور SSH پیغام کو کچھ بتانے کا موقع ہی نہیں ملتا۔