ٹنل چل رہا ہے، آپ ایک اضافی ٹرمینل بند کرتے ہیں، اور کلائنٹ میں ایک بٹن دبائے بغیر VPN نیچے آ جاتا ہے۔ Linux AnyConnect کلائنٹ میں بتایا گیا سبب روٹنگ نہیں بلکہ سیشن کا حساب ہے: کلائنٹ ریکارڈ کرتا ہے کہ ٹنل اٹھنے کے وقت کون سے لاگ اِن سیشن موجود تھے اور اُن میں سے کسی کا خاتمہ ٹنل گرا دینے کی وجہ سمجھتا ہے۔ نیچے دی گئی جانچ ترتیب سے چلتی ہے، اور پہلی ناکام بتاتی ہے کہ آپ واقعی یہی رویہ دیکھ رہے ہیں یا نہیں۔ کلائنٹ کے معمول کے آؤٹ پٹ میں ٹرمینل کا کوئی ذکر نہیں ہوتا، اسی لیے پہلا ردِعمل، یعنی کنسنٹریٹر کو موردِ الزام ٹھہرانا، عموماً بیکار محنت ہے۔

سسٹم فائلیں ترمیم کرنے سے شروع نہ کریں۔ ہر مرحلہ یا تو کٹنے کی وضاحت کرتا ہے یا ایک امکان ہٹاتا ہے، اور سستے مراحل پہلے آتے ہیں۔

سیشن کے کٹنے کو بنیادی روابط کے کٹنے سے الگ کریں

کٹنے کے فوراً بعد دوبارہ جڑیں۔ اسی نیٹ ورک پر، نئے اسناد کے بغیر، چند سیکنڈ میں واپس آنے والا ٹنل مردہ اپ لنک، Wi-Fi رومنگ یا کنسنٹریٹر پر بے کاری کی مدت نہیں بلکہ بند سیشن جیسے مقامی محرک کی طرف اشارہ کرتا ہے۔ Connecting پر لٹکا رہنے والا یا نیٹ ورک بدلنے تک ناکام رہنے والا ٹنل دوسرا مضمون ہے۔

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

دیکھیں کہ جڑتے وقت کلائنٹ نے کیا ریکارڈ کیا

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

کچھ بدلنے سے پہلے وہ سب لکھیں جو کلائنٹ دیکھ سکتا تھا:

who
w
last -n 10
sudo ls -l /run/utmp

who کی ہر سطر utmp میں صارف کے پروسیس کا اندراج ہے۔ اگر آپ کا سیشن دو بار نظر آئے، ایک بار گرافیکل لاگ اِن کے لیے اور ایک بار ٹرمینل کے لیے، تو دونوں اندراج جڑتے وقت موجود تھے اور دونوں امیدوار ہیں۔

utmp سے صرف اپنا اندراج ہٹائیں

شائع شدہ حل اُس سیشن کو، جو آپ استعمال کرنے جا رہے ہیں، کلائنٹ شروع ہونے سے پہلے utmp میں پوشیدہ کر دیتا ہے۔ ایک چھوٹا C پروگرام getutent() سے گزرتا ہے، وہ ریکارڈ ڈھونڈتا ہے جس کا ut_line معیاری اِن پٹ کے TTY کے برابر ہو، اور پھر وہ ریکارڈ دوبارہ لکھتا ہے۔ ترتیب جان بوجھ کر ہے: setutent()، اندراج پڑھیں، اُس کا ut_id نقل کریں، ut_type کو DEAD_PROCESS مقرر کریں، صارف اور سطر کے خانے خالی کریں، pututline() سے واپس لکھیں، پھر endutent()۔

اُسے کمپائل کریں، پھر اُس شیل سے root کے طور پر چلائیں جو کلائنٹ شروع کرے گا:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

زیادہ تر شکایات کہ اوزار کچھ نہیں کرتا، دو ناکامی طریقوں سے واضح ہوتی ہیں۔ یہ معیاری اِن پٹ سے منسلک TTY پر عمل کرتا ہے، اس لیے بغیر ٹرمینل اسکرپٹ یا کِرون کام سے چلانے پر ملانے کو کچھ نہیں بچتا۔ اور /run/utmp عام صارفین کے لیے لکھنے کے قابل نہیں، اس لیے root کے بغیر چلانا خروجی حالت جانچے بغیر خاموشی سے ناکام ہوتا ہے۔

تصدیق کریں کہ ٹنل بندش برداشت کرتا ہے

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

اگر پھر بھی کٹے تو زیرِ نگرانی سیشن کہیں اور تھا، اکثر وہ گرافیکل لاگ اِن جس نے آپ کا ٹرمینل پیدا کیا، اور ایک TTY اندراج ہٹانے سے مدد نہیں ملے گی۔ مزید سرجری بڑھانے کے بجائے پہلے مرحلے کی مکمل فہرست کے ساتھ مشاہدہ دہرائیں۔

utmp دوبارہ لکھنا کب غلط جواب ہے

utmp مشترکہ حساب ہے، نجی جدول نہیں۔ ابھی زندہ سیشن کا اندراج دوبارہ لکھنے سے who، w اور کچھ آڈٹ اوزار اُسے کم رپورٹ کرتے ہیں، اور بعد میں وہی اندراج بند کرنے والا پروگرام بالکل ناکام ہو سکتا ہے۔ اوزار کو اپنے سیشن تک محدود رکھیں، اصل فائل کی نقل رکھیں، اور اُسے ہر ریکارڈ مٹانے والی بوٹ سروس نہ بنائیں۔

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

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

متعلقہ مضامین