ترتیب سرویس در macOS مسیرهای VPN شما را کنترل نمیکند
ترتیب سرویس بین رابطهای معمولی انتخاب میکند. یک VPN از قبل بر آنها اولویت دارد و مسیرهای شامل آن از پروفایل میآید، نه از آن فهرست.
چیزی در یک وبسایت شکست میخورد، همکاری به یاد میآورد که ترتیب سرویس وجود دارد و Wi-Fi بالای Ethernet کشیده میشود. هیچ چیز تغییر نمیکند، چون آن فهرست هرگز تعیین نکرده است که مقصد VPN کجا میرود. اپل به اتصالهای VPN بر اتصالهای معمولی اولویت میدهد و آنها را از این بازچینش بیرون نگه میدارد، بنابراین آن کلید به پرسشی محدودتر از پرسش مطرحشده پاسخ میدهد. این خطا به مسیر انتخابشده و resolver نیاز دارد، نه به یک رتبهبندی تازه.
ترتیب سرویس چه چیزی را تغییر میدهد و هرگز به چه چیزی دست نمیزند
«تنظیم ترتیب سرویس» در تنظیمات سیستم، شبکه، در منوی Action قرار دارد و اتصالهای معمولی را وقتی دو یا بیشتر فعالاند رتبهبندی میکند. این رتبهبندی سرویس اصلی را انتخاب میکند که مسیر پیشفرض و بخشی از رفتار resolver را تأمین میکند. این یک تصمیم میان همتاها است، نه کلیدی برای مقصدهای خصوصی پشت تونل. یک لپتاپ با Wi-Fi و آداپتور Ethernet USB از آن برای پاسخ به پرسشی معقول استفاده میکند و آن پرسش درباره تونل نیست.
یک پروفایل VPN مسیرهای شامل، مقصدهای خارجشده و گاهی قواعد بهازای برنامه را حمل میکند و آنها تعیین میکنند چه چیزی وارد تونل شود؛ منوی ترتیب آنها را ویرایش نمیکند. به همین دلیل یک پروفایل split-tunnel میتواند ترافیک عمومی را بیرون بگذارد در حالی که VPN هنوز بر هر رابط فیزیکی اولویت دارد. کشیدن Wi-Fi به بالا نمیتواند یک محدوده خصوصی را قابلدسترس کند و نمیتواند مقصدی را که پروفایل از قبل شامل آن است متوقف کند. فهرست رابطها را جابهجا میکند؛ پروفایل پیشوندها را. اپل این اولویت را در صفحه ترتیب سرویس شبکه مستند کرده است، که ارزش یک بار خواندن پیش از هر بازچینشی را دارد.
مسیری را بخوانید که دستگاه واقعاً انتخاب کرده است
با route get 10.20.4.10 از دستگاه بپرسید یک نشانی مشخص کجا میرود، سپس آن را برای IPv6 با route -n get -inet6 2001:db8::10 تکرار کنید. این دو خانواده تصمیمهای جداگانهاند، بنابراین یک مسیر IPv4 کارکننده هیچ چیزی درباره v6 نمیگوید، و یک زیرشبکه متصل مستقیم یا پیشوند خاصتر در هر حال بر برچسب عمومی اتصال پیروز میشود، که دقیقاً دلیل گمراهکننده ماندن آن برچسب است.
اگر خروجی رابط تونل را نام ببرد، پروفایل مقصد را گرفته و ترتیب بیربط است. اگر رابط فیزیکی را نام ببرد، پروفایل آن را نگرفته و هیچ کشیدنی جدول پیشوند را تغییر نمیدهد. هر دو خروجی همچنین نشانی مبدأی را که دستگاه استفاده میکند نام میبرند و این همان فیلدی است که هنگام مقایسه دو اجرا باید نقل کنید. پیش از تغییر هر چیزی خروجی را ذخیره کنید، چون تنها مدرکی است که بعداً خواهید داشت.
DNS بر اساس نام حل میکند، نه بر اساس رابط
resolverهای محدودشده و دامنهمحور یعنی پاسخ میتواند بهازای نام متفاوت باشد نه بهازای رابط. scutil --dns پیکربندی resolverی را که سیستم واقعاً استفاده میکند چاپ میکند، شامل ورودیهای محدودشده. ترتیب سرویس بر این اثر میگذارد که کدام سرویس resolver پیشفرض را تأمین کند، اما یک محدوده ناممحور میتواند در هر حال پیروز شود.
به همین دلیل ping به یک نشانی میتواند کار کند در حالی که نام میزبان شکست میخورد، یا برعکس. پیش از انتخاب مقصر هر دو خروجی را بخوانید.
پروفایل را تغییر دهید، سپس هر دو خروجی را دوباره بخوانید
وقتی یک سیاست مقصد باید تغییر کند، مالک آن پروفایل VPN است: مسیرهای شامل، مسیرهای خارجشده و هر قاعده split-tunnel که فروشنده پشتیبانی میکند. تغییر رابطها در عوض فقط بحث را جابهجا میکند. روی Macی که از راه دور مدیریت میشود، اول وضعیت فعلی شبکه را ذخیره کنید، چون از دست دادن تونل روی دستگاهی که به آن دسترسی ندارید یک سفر است نه یک بازگردانی.
خطا را بازتولید کنید، مسیر را بخوانید، resolver را بخوانید، یک چیز را تغییر دهید، سپس همان دو خروجی را دوباره بخوانید. بههمزدن چند سرویس و پروفایل همزمان دستگاهی باقی میگذارد که هیچکس نمیتواند توضیح دهد، از جمله کسی که آن را درست کرده. آزمون زمانی تمام است که هر دو خروجی با تغییری که قصد داشتید همخوان باشند. اگر هنوز ناهمخواناند، پروفایل و دستگاه دو سیاست متفاوت را توصیف میکنند و پروفایل همان است که باید تغییر کند.