DNS اوپن‌وی‌پی‌ان پس از SIGKILL باقی می‌ماند: نخست مالک را بررسی کنید

پس از کشته شدن یک کلاینت OpenVPN، DNS از حل‌شدن بازمی‌ماند و نخستین واکنش بازنویسی /etc/resolv.conf است. آن ویرایش می‌تواند یک resolver سالم را بشکند در حالی که وضعیت کهنهٔ واقعی جای دیگری است. پرسشی که نخست باید روشن شود این است که مالک تنظیمات DNS نصب‌شده توسط تونل کیست و آیا خروجی که پاک‌سازی را از دست داد واقعاً مهم بود.

سه شرط تعمیر را تعیین می‌کند: سیگنالی که فرایند را پایان داد، مؤلفهٔ resolver که تنظیمات را دریافت کرد، و اینکه پیوند تونل هنوز وجود دارد یا نه. به همین ترتیب پاسخ دهید تا اصلاح معمولاً بدون دست‌زدن به هیچ فایل عمومی به دست آید.

تعیین کنید چه نوع خروجی رخ داده است

در نسخهٔ Community OpenVPN، هر دو SIGINT و SIGTERM درخواست خروج آرام هستند. SIGKILL قابل گرفتن نیست: نه می‌توان آن را مسدود کرد و نه مدیریت، پس هیچ روال خاموش‌شدنی فرصت اجرا پیدا نمی‌کند. یک Ctrl+C معمولی در پایانهٔ پیش‌زمینه SIGINT تولید می‌کند، در حالی که ناظری که از انتظار دست می‌کشد معمولاً به SIGKILL ارتقا می‌دهد. تفاوت مهم است چون تنها حالت دوم تضمین می‌کند که قلاب‌ها نادیده گرفته شده‌اند.

اجرا داخل screen یا tmux تغییر نمی‌دهد که Ctrl+C کدام سیگنال را می‌فرستد. آنچه فرایند واقعاً دریافت کرده را بررسی کنید، نه آنچه پایانه معمولاً انجام می‌دهد.

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

تعیین کنید مالک resolver کیست

systemd-resolved، اسکریپتی به سبک resolvconf و بازنویسی سادهٔ فایل سه مالک متفاوت هستند. اولی تنظیمات هر پیوند را در حافظه نگه می‌دارد و وقتی رابط ناپدید شود آن‌ها را دور می‌ریزد. دومی سوابقی نگه می‌دارد که تا وقتی چیزی آن‌ها را حذف نکند باقی می‌مانند. سومی فایلی می‌نویسد و بازگردانی را به عهدهٔ همان کسی می‌گذارد که نوشته است.

پیش از انتخاب فرمان تعمیر، مالک را مشخص کنید. همین نشانه سه پاسخ درست متفاوت دارد بسته به اینکه کدام یک در کار باشد.

یک VPN مدیریت‌شده با NetworkManager ممکن است از پیش مالک تغییرات resolver باشد. افزودن یک کمک‌کنندهٔ دوم روی آن، دو مالک می‌سازد که بر سر همان پیوند رقابت می‌کنند و وضعیت بازنده در اتصال دوبارهٔ بعدی بازمی‌گردد. اگر مدیری مسئول است، تنظیم را در مدیر درست کنید نه در اسکریپت.

قلاب down چه می‌تواند بکند و چه نمی‌تواند

اسکریپت down یک بار پس از بسته شدن دستگاه TUN/TAP اجرا می‌شود. افزودن down-pre این ترتیب را برمی‌گرداند و اسکریپت را زمانی اجرا می‌کند که دستگاه هنوز وجود دارد، چیزی که کمک‌کننده‌های نیازمند پیوند زنده می‌طلبند.

هیچ‌یک از این دو دستور قلاب را پس از SIGKILL اجرا نمی‌کند. دسترسی‌ها هم با down-pre بازگردانده نمی‌شوند: اگر دیمن به user یا group فرود آید یا به chroot وارد شود، قلاب با همان دسترسی‌ای که برایش می‌ماند اجرا می‌شود. قلاب فراخوانده‌شده باز هم می‌تواند در به‌روزرسانی resolver شکست بخورد. مرجع OpenVPN سیگنال‌ها و چرخهٔ عمر فراخوان بازگشتی را پوشش می‌دهد.

خطای خود قلاب را در کنار وضعیت خروج فرایند بررسی کنید. پاک‌سازی غایب و پاک‌سازی ناموفق در resolver یکسان و در گزارش‌ها متفاوت دیده می‌شوند.

وضعیتی را که واقعاً باقی می‌ماند بررسی کنید

در سامانه‌ای که از systemd-resolved استفاده می‌کند، resolvectl status نشان می‌دهد کدام پیوند هنوز سرورهای DNS یا دامنه‌های مسیریابی VPN را حمل می‌کند. آن پیوند می‌تواند به اتصالی تعلق داشته باشد که رفته است، یا به تونل دیگری که هنوز بالاست.

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

بدون دزدیدن پیوند دیگر بازیابی کنید

وقتی تنظیمات هر پیوند به عهدهٔ شماست، resolvectl revert نام پیوند را می‌گیرد و پیکربندی DNS زمان اجرا را برای آن رابط پاک می‌کند. این کاری در زمان اجراست نه ویرایش پروفایل، پس پیکربندی ماندگار اتصال دست‌نخورده می‌ماند. پیوند اشتباه را نام ببرید و DNS یک تونل سالم را پاک می‌کنید، از همین رو نام از خروجی وضعیت گرفته می‌شود.

پیش از ویرایش تأیید کنید که /etc/resolv.conf یک پیوند نمادین مدیریت‌شده است، سپس کلاینت را یک بار دیگر به‌طور عادی متوقف کنید و دوباره به DNS نگاه کنید. اگر توقف دوم پاک کرد، مشکل پیشین خروج اجباری بوده است نه پیکربندی.