انقطاع AnyConnect عند إغلاق الطرفية: فحوص الجلسات

النفق قائم، تُغلق طرفية احتياطية، فينهار الـVPN دون ضغطة مفتاح واحدة في العميل. في عميل AnyConnect على Linux يكون السبب المبلَّغ عنه محاسبة الجلسات لا التوجيه: يسجّل العميل جلسات تسجيل الدخول التي كانت موجودة عند قيام النفق ويعتبر انتهاء أي منها سببًا لهدمه. الفحوص أدناه تُنفَّذ بالترتيب، وأول فحص يفشل يخبرك إن كنت تنظر إلى هذا السلوك أصلًا. لا شيء في مخرجات العميل المعتادة يذكر طرفية، ولهذا فإن الغريزة الأولى، أي إلقاء اللوم على المُجمِّع، غالبًا جهد ضائع.

لا تبدأ بتعديل ملفات النظام. كل خطوة إمّا تفسّر الانقطاع وإمّا تُزيل احتمالًا، والخطوات الرخيصة تأتي أولًا.

افصل انقطاع الجلسة عن انقطاع الشبكة الأساسية

أعد الاتصال فورًا بعد الانقطاع. النفق الذي يعود خلال ثوانٍ، على الشبكة نفسها، دون بيانات اعتماد جديدة، يشير إلى محفّز محلي مثل جلسة مغلقة لا إلى وصلة صاعدة ميتة أو تجوال Wi-Fi أو مهلة خمول على المُجمِّع. أما النفق الذي يتوقف عند Connecting، أو الذي يفشل حتى تغيّر الشبكات، فهو مقال آخر.

اكتب ما كان مفتوحًا عند قيام النفق: الطرفية التي شغّلت منها العميل، وأي صدفة ثانية، وتسجيل الدخول الرسومي، وأي جلسة SSH من جهاز آخر. ستحتاج تلك القائمة بعد قليل، وإعادة بنائها من الذاكرة بعد الانقطاع التالي غير موثوقة.

افحص ما سجّله العميل عند الاتصال

العميل لا يفحص الآباء في شجرة العمليات ولا ملكية الطرفية. إنه يأخذ لقطة لمجموعة جلسات تسجيل الدخول الموجودة عند الاتصال ويقارن تلك المجموعة لاحقًا؛ وعندما يختفي عضو منها تفشل المقارنة ويذهب النفق معه. لهذا قد يكون إغلاق النافذة التي اتصلت منها غير ضار بينما يقتل إغلاق طرفية احتياطية لا علاقة لها بالاتصال: المهم هو هل كانت تلك الجلسة في المجموعة الأصلية. الفحص مقارنة مجموعات لا عدّ، ولهذا فإن استبدال جلسة قد يكون قاتلًا مثل فقدان واحدة.

اسرد ما كان العميل قادرًا على رؤيته قبل أن تغيّر أي شيء:

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

كل سطر من who هو مدخل عملية مستخدم في utmp. إذا ظهرت جلستك مرتين، مرة لتسجيل الدخول الرسومي ومرة للطرفية، فإن المدخلين كانا موجودين عند الاتصال وكلاهما مرشح.

أزل مدخلك أنت فقط من utmp

الحل المنشور يجعل الجلسة التي أنت على وشك استخدامها غير مرئية في utmp قبل أن يبدأ العميل. برنامج C صغير يتنقل عبر getutent()، ويطابق السجل الذي يساوي ut_line فيه طرفية الإدخال القياسي، ثم يعيد كتابة ذلك السجل. الترتيب مقصود: setutent()، اقرأ المدخل، انسخ ut_id الخاص به، اضبط ut_type على DEAD_PROCESS، امسح حقلي المستخدم والسطر، اكتبه مرة أخرى بـpututline()، ثم endutent().

ترجمه، ثم شغّله بصلاحية الجذر من الصدفة التي ستبدأ العميل:

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

نمطا فشل يفسّران معظم التقارير التي تقول إن الأداة لا تفعل شيئًا. إنها تعمل على الطرفية المرتبطة بالإدخال القياسي، لذا تشغيلها من سكربت أو مهمة cron بلا طرفية لا يترك لها ما تطابقه. و/run/utmp غير قابل للكتابة للمستخدمين العاديين، لذا يفشل تشغيل بدون جذر بصمت ما لم تتحقق من حالة الخروج.

تحقق من أن النفق ينجو من الإغلاق

اختبر الآلية بدلًا من افتراضها. اتصل من جلسة تنوي إبقاءها مفتوحة، افتح طرفية ثانية، أغلق الثانية، ثم أكّد أن النفق ما زال قائمًا باستخدام vpn state ونظرة على قائمة الواجهات. إذا نجا النفق، فالمحفّز كان نوع جلسة معينًا لا كل جلسة، وقد وجدت الجلسة التي يجب أن تبقى مفتوحة.

إذا استمر الانقطاع، فالجلسة المراقَبة كانت في مكان آخر — غالبًا تسجيل الدخول الرسومي الذي أنشأ طرفيتك — ولن يساعد تجريد مدخل طرفية واحد. أعد الملاحظة بالقائمة الكاملة من الخطوة الأولى بدلًا من إضافة المزيد من الجراحة.

متى تكون إعادة كتابة utmp الجواب الخاطئ

utmp محاسبة مشتركة لا جدولًا خاصًا. إعادة كتابة مدخل جلسة ما زالت حية تجعل who وw وبعض أدوات التدقيق تبلغ عنه بأقل من حقيقته، وقد يفشل برنامج يغلق المدخل نفسه لاحقًا فشلًا كاملًا. أبقِ الأداة محصورة في جلستك أنت، واحتفظ بنسخة من الملف الأصلي، ولا تحوّلها إلى خدمة إقلاع تجرّد كل سجل.

إذا كان موقعك يجمع محاسبة الجلسات لأغراض الامتثال، فإن الحل يتعارض مع ذلك الشرط والجواب المدعوم هو إصدار عميل آخر أو طريقة وصول مختلفة، لا utmp مُرقَّعًا. ولأكثر الناس فإن أقل إصلاح تدخلًا هو ببساطة بدء العميل من جلسة ستبقى مفتوحة طوال اليوم وترك تلك النافذة وشأنها.

قبل أن تغلق التذكرة، سجّل أي جلسة كان العميل يراقبها عند قيام النفق. ذلك السطر الواحد هو ما يحوّل انقطاعًا غامضًا إلى شرط قابل لإعادة الإنتاج للشخص التالي على الجهاز.