VPN می‌گوید متصل است اما هیچ چیز مسیریابی نمی‌شود: دو جا برای بررسی

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

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

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

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

ip route show default
ip route get 203.0.113.9

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

سپس resolver را برای هر پیوند بخوانید، نه برای هر فایل

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

وضعیت را برای هر پیوند بررسی کنید نه فایل را، چون در بسیاری از توزیع‌ها آن فایل پیوند نمادین به resolver است و ویرایش آن یا هیچ کاری نمی‌کند یا به‌سرعت بازنویسی می‌شود. ببینید کدام پیوند مالک کدام کارسازها و کدام دامنه جست‌وجوست، سپس بپرسید آیا پیوند تونل باید هنوز ثبت باشد. اگر نباید، اتصالی را که مالک آن است غیرفعال کنید به‌جای ویرایش دستی وضعیت تولیدشده. نامی که حل می‌شود در حالی که جست‌وجوی مسیر بسته‌ها را جای دیگری می‌فرستد، سومین و جداگانه‌ترین ایراد است.

resolvectl status
resolvectl query app.internal.example

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

چگونه یک مسیر کهنه از تغییر جان سالم به در می‌برد

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

پروفایل VPN خودش را بالا نمی‌آورد، بنابراین جفت‌شدن بسیار مهم‌تر از ترجیح اتصال خودکار خود پروفایل است.

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

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

وضعیت کهنه را از والد غایب جدا کنید

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

راه‌اندازی دوباره پنهان می‌کند که کدام یک از سه وضعیت را داشتید، و دقیقاً به همین دلیل شبیه تعمیر به نظر می‌رسد.

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