چرا یک مسیر VPN حذف‌شده پس از اتصال دوباره برمی‌گردد

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

چه کسی مسیر را نصب کرد

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

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

جدول را قبل از ویرایش بخوانید

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

ip route show
ip route show table all
ip rule show

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

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

ip route get 10.20.5.7

مالک را تغییر دهید، نه نشانه را

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

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

دوباره وصل شوید و هر دو مسیر را بررسی کنید

دوباره وصل شوید، سپس هر دو مقصد را در یک گذر بررسی کنید. نشانی محافظت‌شده و نقطهٔ پایانی مستثنی‌شده به پرسش‌های متفاوتی پاسخ می‌دهند:

ip route get 10.20.5.7
ip route get 198.51.100.20

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

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