openconnect کشتهشده: مسیرها و DNS هنوز به تونل اشاره میکنند
یک فرایند مرده openconnect میتواند مسیرها و ورودیهای resolver را نصبشده باقی بگذارد. مسیر خاموششدن را طی کنید، سیگنالی را که build شما مستند میکند بفرستید و پاکسازی کنید.
تونل پایین است، اما ماشین هنوز طوری رفتار میکند که انگار بالاست: یک جستوجو تا پایان مهلت معلق میماند و یک مسیر به واسطی اشاره میکند که دیگر وجود ندارد. این امضای فرایند openconnect است که بدون اجرای کمککننده قطع اتصالش مرده است. وضعیت شبکهای که ساخته هنوز نصب است و هیچ چیز دیگری در سیستم نمیداند چگونه آن را حذف کند.
ماشین را به ترتیبی که وضعیت ساخته شد طی کنید: فرایند، پیوند، مسیر، resolver. هر گام به شما میگوید کلاینت واقعاً رفته است یا فقط از ترمینال شما جدا شده، و همین تفاوت تعیین میکند که اصلاً چیزی را تعمیر کنید یا نه.
با فرایند شروع کنید، نه با پیکربندی
ترمینالی باز کنید و پیش از دست زدن به مسیر بپرسید چه چیزی هنوز در حال اجراست. pgrep -a openconnect هر نمونه را با آرگومانهایش فهرست میکند، که فایل pid و اسکریپتی را که به آن داده شده نشان میدهد. فرایندی که انتظارش را نداشتید، تونل شبح را سریعتر از هر لاگی توضیح میدهد.
اگر چیزی در حال اجرا نیست، به پیوند نگاه کنید. ip link show tun0 میگوید واسط دوام آورده است یا نه، و ip route show dev tun0 مسیرهایی را که هنوز به آن بستهاند فهرست میکند. سپس resolver را با این بررسی کنید resolvectl status. هر سه خروجی را پیش از تغییر ثبت کنید، چون همان ثبت است که بعداً ورودی کهنه را از ورودی تازه تشخیص میدهد.
واسطی که از بین میرود معمولاً مسیرهایش را با خود میبرد. مسیرهایی که از پیوند جان سالم به در میبرند معمولاً یعنی فرایند هنوز زنده است یا کلاینت دومی صاحب دستگاه است.
اسکریپت کمککننده همان چیزی است که تغییرات را برمیگرداند
openconnect خودش واسط، مسیرها یا ورودیهای resolver را حذف نمیکند. یک کمککننده بیرونی را صدا میزند، /etc/vpnc/vpnc-script در یک build بالادستی و /usr/share/vpnc-scripts/vpnc-script در بستههای Debian و Ubuntu، که با سوئیچ زیر انتخاب میشود: -s. همان اسکریپتی که تونل را بالا میآورد همان است که آن را پایین میآورد.
اگر فرایند بدون صدا زدن آن کمککننده خارج شود، وضعیت میماند. راهنمای OpenConnect صریحاً میگوید که مسیریابی و سرویس نام بدون اسکریپت درست کار نمیکنند و کمککننده را جزئی توصیف میکند که وضعیت واسط را هنگام خروج از هم میپاشد. به همین دلیل مسیر مهم است وقتی کلاینت را با سوئیچ زیر اجرا میکنید: -s.
اینکه کدام سیگنال به آن مسیر میرسد بین نسخهها تغییر کرده است. راهنمای 7.06 سیگنال SIGTERM را خروج فوری میداند که اسکریپت را رد میکند. buildهای کنونی INT و TERM را توقف تمیز مستند میکنند، جایی که نشست خارج میشود و کمککننده اجرا میشود. بخش SIGNALS همان باینریای را که واقعاً دارید بخوانید، بهجای فرض کردن هر یک از این دو رفتار.
man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'
سیگنالی را که build شما مستند میکند بفرستید
وقتی سیگنال را دانستید، فرایند را با pid متوقف کنید نه با الگو.
pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"
سپس سه بررسی بخش اول را تکرار کنید بهجای اعتماد به وضعیت خروج. ip link show tun0 باید شکست بخورد، ip route show dev tun0 نباید چیزی چاپ کند، و resolvectl status نباید دیگر پیوند VPN را فهرست کند.
SIGHUP دکمه توقف نیست: اتصال را قطع میکند، اسکریپت را اجرا میکند و نشست را با سوئیچ زیر قابل از سرگیری نگه میدارد: --cookie. SIGUSR2 اتصال مجدد فوری را تحمیل میکند. SIGKILL پاکسازی را کاملاً رد میکند و این دقیقاً همان وضعیتی است که این مقاله درباره آن است.
resolver را بدون جایگزینی resolv.conf تعمیر کنید
در بیشتر سیستمهای Ubuntu /etc/resolv.conf یک پیوند نمادین به systemd-resolved است، نه فایلی که باید ویرایش کنید. جایگزینی آن نامجویی را برای هر شبکهای میشکند، نه فقط VPN. بهجای آن ثبت تونل را حذف کنید:
resolvectl revert tun0
resolvectl query example.com
اگر سیستم بهجای systemd-resolved از resolvconf استفاده میکند، رکورد هر واسط باقی میماند تا به آن گفته شود پیوند را رها کند، و resolvconf -d tun0 معادل همان اقدام است. پیش از انتخاب دستور بررسی کنید کدام resolver استفاده میشود.
جستوجویی که هنوز به سروری پشت پیوند مرده نشانه رفته تا پایان مهلت معلق میماند و آن تأخیر بیشتر شبیه سرور DNS خراب است تا مسیر باقیمانده.
قطع اتصال بعدی را خستهکننده کنید
مسیر فایل pid را در شروع و خاموشی یکسان نگه دارید با فرستادن سوئیچ --pid-file هر بار، یا openconnect را زیر یک unit اجرا کنید که KillSignal با سیگنالی که نسخه شما مستند میکند مطابقت دارد. تست در پیشزمینه ابتدا پیامهای خاموشی را که کمککننده چاپ میکند نشان میدهد.
وصل شوید، قطع کنید و سه بررسی را یک بار اجرا کنید. خروج تمیز هیچ پیوند VPN، هیچ مسیر VPN و هیچ ورودی resolver VPN باقی نمیگذارد. اگر یکی از سه دوام آورد، اکنون میدانید کدام جزء در پاکسازی شکست خورده. تحقیق بعدی آنگاه از همان پاسخ شروع میشود نه از یک جستوجوی معلق.