بررسی مسیر VPN در macOS: اجرای route get بدون تغییر چیزی

کاربری در شبکه اداری به اینترانت میرسد و نه از طریق تونل، در حالی که تنظیمات هنوز VPN را متصل نشان میدهد. ویرایش جدول مسیرها در آن لحظه خطر قطع نشست راه دوری را دارد که برای عیبیابی استفاده میکنید. به جای آن از هسته بپرسید کدام مسیر را برای میزبان ناموفق انتخاب میکند. ابزار route در macOS یک عملیات get دارد که دقیقاً به همین پرسش برای یک مقصد پاسخ میدهد، بدون اینکه چیزی را تغییر دهد.

از میزبان ناموفق بپرسید، نه از مسیر پیشفرض

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

شکل آن route -n get به همراه نشانی است: route -n get 203.0.113.10، جایی که نشانی مستندات جای هدف شما را میگیرد. از مقصد مجاز و خانواده نشانی مطابق استفاده کنید، زیرا پاسخ IPv4 درباره منبعی که فقط IPv6 است چیزی نمیگوید. مستندات ابزار route عملیات get و فیلدهایی را که چاپ میکند توصیف میکند.

رابط و دروازه را به عنوان شواهد بخوانید

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

پیش از نتیجهگیری، مقصد، رابط، دروازه و زمان پرسوجو را ثبت کنید. خروجی شواهد است، نه تشخیص: همان رابط میتواند برای یک میزبان درست و برای میزبانی دیگر نادرست باشد وقتی تونل منقسم در کار است.

مسیر درست به معنای درخواست کارآمد نیست

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

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

نقطه پایانی و منبع را جدا نگه دارید

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

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

اول بخوانید، بعد تغییر دهید

route add و route delete را از دور اول بیرون نگه دارید. روی Macی که از راه دور مدیریت میکنید، یک ویرایش بیدقت جدول میتواند همان مسیر بازگشت به دستگاه را از بین ببرد و هیچکس نتواند عیبیابی را تمام کند. تصمیم بگیرید مسیر درست چیست، بنویسید چگونه تغییر را برگردانید و تنها پس از آن اجرایش کنید. بازرسی چنین دمی ندارد.

همین احتیاط برای پاک کردن حافظههای نهان و راهاندازی دوباره سرویسهای شبکه به عنوان نخستین گام هم صدق میکند، زیرا هر دو شواهدی را نابود میکنند که در آستانه خواندنشان بودید. بررسیهای فقطخواندنی ارزان، تکرارپذیر و در هر ترتیبی ایمناند. آنها را گام پیشفرض کنید و تنها وقتی شواهد به آن اشاره کرد سراغ تغییر بروید.