قطع شدن AnyConnect هنگام بستن ترمینال: بررسی‌های نشست

تونل بالاست، یک ترمینال اضافی را می‌بندید و VPN بدون حتی یک فشار کلید در کلاینت قطع می‌شود. در کلاینت AnyConnect لینوکس علت گزارش‌شده حسابداری نشست است نه مسیریابی: کلاینت ثبت می‌کند که هنگام بالا آمدن تونل کدام نشست‌های ورودی وجود داشتند و پایان هر یک از آن‌ها را دلیلی برای فروپاشی تونل می‌داند. بررسی‌های زیر به ترتیب اجرا می‌شوند و اولین بررسی ناموفق به شما می‌گوید آیا اصلاً با این رفتار روبه‌رو هستید. هیچ چیز در خروجی معمول کلاینت به ترمینال اشاره نمی‌کند، به همین دلیل غریزه اول، یعنی مقصر دانستن concentrator، معمولاً تلاشی هدررفته است.

با ویرایش فایل‌های سیستم شروع نکنید. هر گام یا قطع شدن را توضیح می‌دهد یا یک گزینه را حذف می‌کند، و گام‌های ارزان اول می‌آیند.

قطع نشست را از قطع شبکه زیرین جدا کنید

بی‌درنگ پس از قطع اتصال دوباره وصل شوید. تونلی که در چند ثانیه بازمی‌گردد، روی همان شبکه، بدون اعتبارنامه جدید، به یک محرک محلی مانند نشست بسته‌شده اشاره دارد نه به یک لینک بالادستی مرده، رومینگ Wi-Fi یا یک مهلت بی‌کاری در concentrator. تونلی که روی 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 متصل به ورودی استاندارد عمل می‌کند، بنابراین اجرای آن از یک اسکریپت یا کار cron بدون ترمینال چیزی برای تطبیق باقی نمی‌گذارد. و /run/utmp برای کاربران عادی قابل نوشتن نیست، بنابراین اجرا بدون root بی‌صدا شکست می‌خورد مگر اینکه وضعیت خروج را بررسی کنید.

تأیید کنید تونل از بسته شدن جان سالم به در می‌برد

مکانیزم را آزمایش کنید نه اینکه آن را فرض بگیرید. از نشستی که قصد دارید نگه دارید وصل شوید، ترمینال دومی باز کنید، دومی را ببندید، سپس با vpn state و نگاهی به فهرست واسط‌ها تأیید کنید که تونل هنوز بالاست. اگر تونل زنده بماند، محرک یک نوع نشست خاص بوده نه هر نشست، و نشستی را یافته‌اید که باید باز بماند.

اگر باز هم قطع می‌شود، نشست تحت نظر جای دیگری بوده است، بیشتر اوقات ورود گرافیکی که ترمینال شما را ساخته، و حذف یک ورودی TTY کمکی نمی‌کند. مشاهده را با فهرست کامل گام اول تکرار کنید نه اینکه جراحی بیشتری اضافه کنید.

چه زمانی بازنویسی utmp پاسخ اشتباه است

utmp حسابداری مشترک است، نه جدولی خصوصی. بازنویسی ورودی نشستی که هنوز زنده است باعث می‌شود who، w و برخی ابزارهای حسابرسی آن را کمتر از واقع گزارش کنند، و برنامه‌ای که بعداً همان ورودی را ببندد ممکن است کاملاً شکست بخورد. ابزار را محدود به نشست خودتان نگه دارید، نسخه‌ای از فایل اصلی نگه دارید و آن را به سرویس بوت تبدیل نکنید که هر رکورد را پاک کند.

اگر سازمان شما برای انطباق حسابداری نشست جمع می‌کند، این راه‌حل با آن الزام در تضاد است و پاسخ پشتیبانی‌شده نسخه دیگری از کلاینت یا روش دسترسی متفاوت است، نه utmp اصلاح‌شده. برای بیشتر مردم کم‌تهاجمی‌ترین راه‌حل این است که کلاینت را از نشستی اجرا کنند که تمام روز باز می‌ماند و آن پنجره را به حال خود بگذارند.

پیش از بستن تیکت، ثبت کنید کلاینت هنگام بالا آمدن تونل مراقب کدام نشست بود. همان یک خط است که یک قطع اتصال مرموز را به شرطی تکرارپذیر برای نفر بعدی پشت دستگاه تبدیل می‌کند.