VPN می‌گوید متصل است، اما مسیر پیش‌فرض مرده است

کلاینت می‌گوید متصل است، نماد سینی سیستم عادی به نظر می‌رسد، و هیچ چیزی بارگذاری نمی‌شود. درست بعد از اینکه از Wi-Fi به کابل رفتید، یا درست بعد از اینکه به‌روزرسانی توزیع تمام شد، شروع شد. چیزی که خراب شده پروفایل نیست، بلکه وضعیتی است که برای اتصال پایه قبلی ساخته شده بود. هسته هنوز یک مسیر پیش‌فرض دارد که به دستگاه تونلی اشاره می‌کند که مالک ندارد، یا حل‌کننده هنوز سرورهایی را روی پیوندی که از بین رفته فهرست می‌کند. هر دو خرابی شبیه شبکه مرده‌اند و هر دو در همان‌جا قابل تعمیرند.

قطعه‌های کهنه پیش از آنکه متوجهشان شوید غلط بودند. بیرون کشیدن کابل فقط آن‌ها را آشکارتر کرد.

از هسته بپرسید بسته به کجا می‌رود

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

جستجو را دو بار اجرا کنید، یک بار برای نشانی عمومی و یک بار برای نشانی داخلی، چون سیاست تونل تقسیم‌شده می‌تواند یکی را صادقانه مسیریابی کند و دیگری را بیندازد.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

حل‌کننده هم پیوند مرده را نگه می‌دارد

روی میزبانی با systemd-resolved، سرورهای DNS به پیوندها تعلق دارند نه به یک فهرست جهانی. پیوند VPN که از کار افتاده می‌تواند مدتی با سرورهایش ثبت‌شده بماند، و آنگاه هر جستجو منتظر نشانی‌ای می‌ماند که هرگز پاسخ نمی‌دهد. این تأخیر شبیه شبکه مرده حس می‌شود و مردم را به سمت مسیرها می‌فرستد وقتی مسیر درست است.

resolvectl status
resolvectl query intranet.example.com

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

ثبت را تعمیر کنید، نه /etc/resolv.conf. در نصب‌های کنونی Ubuntu و Fedora آن مسیر یک پیوند نمادین به وضعیت زمان اجرای حل‌کننده است، پس ویرایش یا نادیده گرفته می‌شود یا در رویداد شبکه بعدی بازنویسی می‌شود.

VPN هرگز خودبه‌خود شروع نمی‌شود

NetworkManager یک VPN را روی یک اتصال پایه بالا می‌آورد و یاد می‌گیرد که از کدام یک پیروی کند، از connection.secondaries روی آن پایه. مرجع تنظیمات اتصال صریحاً می‌گوید که اتصال خودکار برای پروفایل‌های VPN پیاده‌سازی نشده است. این تمام سازوکار پشت این دسته از خرابی‌هاست: پایه را تغییر دهید، و VPN باید دوباره جفت شود یا دستی فعال شود.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

وقتی فهرست فعال پایه را بدون VPN نشان می‌دهد، تونل اصلاً فعال نیست و مسیر هرگز نصب نشده بود، نه اینکه کهنه مانده باشد. وقتی فعال‌سازی شکایت می‌کند که هیچ اتصال مبدأ وجود ندارد، پایه‌ای که با آن جفت شده بود از بین رفته است، پس اول پایه یا جفت‌سازی را درست کنید و دست از تلاش دوباره VPN بردارید.

به‌روزرسانی می‌تواند تنظیمات را بی‌صدا بیندازد

به‌روزرسانی یک توزیع کلاینت و اغلب افزونه NetworkManager آن را جایگزین می‌کند، در حالی که پروفایل ذخیره‌شده نام ویژگی‌هایی را که با آن‌ها نوشته شده نگه می‌دارد. هر چیزی که افزونه جدید دیگر نمی‌شناسد، در سکوت رد می‌شود. پروفایل هنوز فعال می‌شود و دستگاه هنوز ظاهر می‌شود، اما مسیری که قبلاً با آن می‌آمد هرگز نمی‌آید.

قلاب‌های دست‌نویس هم جابه‌جا می‌شوند. اسکریپتی که در لحظه‌ای قابل پیش‌بینی از توالی قدیمی مسیری نصب می‌کرد، اکنون ممکن است پیش از وجود رابط یا پس از اینکه کلاینت از مهلت گذشته اجرا شود.

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

سه وضعیت، سه تعمیر متفاوت

پیش از دست زدن به هر چیزی تصمیم بگیرید در کدام وضعیت هستید، چون راه‌اندازی مجدد شواهد را نابود می‌کند و نقص در تغییر شبکه بعدی برمی‌گردد.

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