چگونه مسیرهای تزریق‌شده توسط VPN را از مسیرهای ایستا در لینوکس تشخیص دهیم
پیشوندی که همراه تونل ظاهر می‌شود می‌تواند از سه منبع بیاید. جدول را مقایسه کنید، متریک را بررسی کنید و سپس همان منبعی را که مدام آن را دوباره نصب می‌کند اصلاح کنید.
پیشوندی روی لپ‌تاپ ظاهر می‌شود که تونل بالا می‌آید، پس به نظر می‌رسد VPN آن را نصب کرده است. شاید نصب کرده باشد، اما همین نتیجه می‌تواند از یک اسکریپت کلاینت که هنگام اتصال اجرا می‌شود، از یک پروفایل اتصال که زیرشبکه را فهرست می‌کند، یا از یک مسیر ایستا بیاید که از ابتدا آنجا بود و فقط وقتی رابط وجود داشت شروع به کار کرد. انتخاب منبع اشتباه یعنی مسیر پس از هر پاک‌سازی برمی‌گردد و نفر بعدی همان اصلاح را تکرار می‌کند. توالی زیر پیش از هر تغییری این سه را از هم جدا می‌کند.
گام 1: مکانیزمی را که پیشوندها را نصب می‌کند نام ببرید
پروتکل‌های مختلف دسترس‌پذیری را به روش‌های مختلف فراهم می‌کنند و نامیدن همهٔ آن اعلان، تفاوت را پنهان می‌کند. یک سرور OpenVPN یک دستور مسیر را از کانال کنترل تزریق می‌کند و کلاینت آن را نصب می‌کند مگر اینکه یک فیلتر pull مانع شود. پیکربندی WireGuard پیشوندهای مجاز را به‌صورت محلی فهرست می‌کند که کلاینت از آن‌ها هم برای مسیریابی کلید رمزنگاری و هم برای مسیرهایی که اضافه می‌کند استفاده می‌کند. تونل IPsec انتخابگرهای ترافیک را با همتا توافق می‌کند و هسته مسیرها را از آن انتخابگرها نصب می‌کند.
پیش از خواندن هر جدولی مشخص کنید تونل شما کدام یک از این‌ها را به کار می‌برد. مسیری که هنگام اتصال تزریق می‌شود اعلان یک پروتکل مسیریابی نیست و قولی نمی‌دهد که پیشوند پشت انتهای دور قابل دسترسی باشد. مکانیزم را کنار پیشوند یادداشت کنید، چون تعیین می‌کند اصلاح به کجا تعلق دارد.
گام 2: جدول را در طول یک اتصال مقایسه کنید
جدول اصلی را با تونل پایین ذخیره کنید، آن را بالا بیاورید، دوباره ذخیره کنید و دو ضبط را مقایسه کنید. هر چیزی که ظاهر شد به چرخهٔ عمر اتصال تعلق دارد و هر چیزی که ماند به پیکربندی محلی.
آن را با ip route show table main > /tmp/route-down.txt ضبط کنید، متصل شوید و دوباره ضبط کنید. اگر سایت از IPv6 استفاده می‌کند همین کار را برای ip -6 route انجام دهید، چون پیشوندی که آنجا غایب است خرابی‌هایی می‌سازد که بی‌ربط به مسیریابی به نظر می‌رسند.
گام 3: متریک را بخوانید، نه فقط وجود را
دو ورودی برای همان پیشوند می‌توانند هم‌زمان وجود داشته باشند و هسته متریک کمتر را انتخاب می‌کند. یک مسیر ایستا با متریک 50 همچنان بر مسیر تزریق‌شده با 100 پیروز می‌شود هرچند هر دو دیده می‌شوند، به همین دلیل «مسیر آنجاست» و «ترافیک از آن استفاده می‌کند» دو گزارهٔ متفاوت‌اند.
با ip route get 10.20.5.7 مستقیماً از هسته بپرسید و رابطی را که گزارش می‌کند بخوانید. اگر ترافیک از آداپتور فیزیکی خارج شود در حالی که یک مسیر تونل در جدول نشسته است، متریک یا طول پیشوند این را توضیح می‌دهد، نه کلاینت VPN. جست‌وجو را برای میزبانی که می‌دانید پشت تونل است و برای یکی که می‌دانید نیست تکرار کنید، و تفاوت نشان می‌دهد که تقسیم آن‌گونه که مقصود است رفتار می‌کند یا نه.
گام 4: ورودی‌هایی را پیدا کنید که از تونل بیشتر عمر می‌کنند
مسیرهای ایستا طبق طراحی از قطع اتصال جان سالم به در می‌برند و ورودی‌های کهنه از همان‌جا می‌آیند. یک مسیر ماندگار که به رابطی اشاره می‌کند که دیگر وجود ندارد می‌تواند یک زیرشبکه را بی‌صدا ببلعد، و یکی که به نام رابطی بازاستفاده‌شده اشاره می‌کند می‌تواند پس از راه‌اندازی مجدد ترافیک خصوصی را از در اشتباه بیرون بفرستد.
سمت ماندگار را در جایی که توزیع شما استفاده می‌کند بررسی کنید، خواه واحد systemd-networkd باشد، خواه پروفایل NetworkManager یا اسکریپتی در پوشهٔ up کلاینت. اصلاح جدول زنده با ip route del فقط تا اتصال بعدی دوام می‌آورد. آن حذف را آزمون فرضیه بدانید، نه تعمیر.
جایی که انتهای دور پوشش اشتباه می‌دهد، آن را با اپراتور مطرح کنید به‌جای اینکه همه‌چیز را فیلتر کنید. کنار گذاشتن همهٔ تنظیمات تزریق‌شده DNS و سیاست تونل تقسیم‌شده را هم که پروفایل به آن‌ها وابسته است دور می‌ریزد.
گام 5: پیش از سرزنش کلاینت، مسیر بازگشت را تأیید کنید
برای اتصال سایت‌به‌سایت یا زیرشبکه‌ای پشت تونل، سمت دور به مسیری به‌سوی نشانی کلاینت شما و به فعال بودن ارسال در دروازه نیاز دارد. مسیر یک‌طرفه دقیقاً شبیه باگ مسیریابی کلاینت است، با این تفاوت که دست‌دادن و بستهٔ خروجی هر دو موفق می‌شوند.
فیلترکردن مسیر معکوس تلهٔ دومی روی دروازه‌های لینوکس اضافه می‌کند. پاسخی که روی رابطی متفاوت از آنچه مسیر پیش‌بینی می‌کند برسد در حالت سخت‌گیرانه دور انداخته می‌شود، و مسیرهای نامتقارن از دو ارائه‌دهنده آن را به‌طور قابل اتکا فعال می‌کنند. شمارنده‌های حذف روی دروازه، نه روی کلاینت، به شما می‌گویند آیا فیلترکردن علت است.
گام 6: منبع را بیازمایید، نه ping را
وقتی مسیر انتخاب‌شده درست شد، منبع واقعی را باز کنید و ترافیک بازگشت را تأیید کنید. پاسخ ping مسیر را در یک جهت اثبات می‌کند و هیچ چیز دربارهٔ سرویس، و سرویسی که روی اتصال کش‌شده پاسخ می‌دهد حتی کمتر اثبات می‌کند.
سپس کل بررسی را پس از اتصال دوباره تکرار کنید. ارزش این توالی در آن است که پیش‌بینی می‌کند اتصال بعدی چه خواهد کرد، به همین دلیل هم مقایسه و هم متریک به تیکت تعلق دارند.