چگونه وضعیت IPv6 یک مک را پس از قطع اتصال VPN بررسی کنیم

اگر پس از افتادن تونل از طریق IPv4 به سایتی برسید، دربارهٔ IPv6 چیزی اثبات نکرده‌اید. macOS دو خانواده را جداگانه و به‌ازای هر سرویس شبکه پیکربندی می‌کند و کارخواه VPN می‌تواند یکی را بدون دست زدن به دیگری تغییر دهد. سه لایه را به ترتیب کار کنید: پیکربندی نشانی، انتخاب مسیر و سپس هر سیاستی که کارخواه در حالت قطع‌شده نصب می‌کند. در این فاصله شبکهٔ دسترسی را بی‌تغییر نگه دارید، وگرنه دو مسئلهٔ متفاوت را مقایسه خواهید کرد.

با خانواده‌ای شروع کنید که واقعاً شکسته است

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

همان شبکهٔ Wi-Fi و همان نقطهٔ دسترسی را در تمام مقایسه نگه دارید. شبکهٔ یک کافه که دیروز IPv6 ارائه می‌داد دربارهٔ شبکه‌ای که اکنون روی آن هستید چیزی نمی‌گوید.

نشانی را پیش از مسیر بخوانید

در تنظیمات سیستم، پنل TCP/IP سرویس فعال نشان می‌دهد IPv6 خودکار، دستی یا فقط پیوندی-محلی است. آن را با انتظار خود مقایسه کنید و به یاد داشته باشید که سازمانی ممکن است پیکربندی دستی را آگاهانه انتخاب کرده باشد. سپس ifconfig را اجرا کنید و رابط مورد نظر را بخوانید. نشانی fe80:: به‌تنهایی یعنی رابط می‌تواند با همسایگان خود سخن بگوید و نه بیشتر، پس وجود نشانی پیوندی-محلی شاهدی بر مسیر قابل استفاده نیست.

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

جدول مسیرها را برای مقصد ناموفق بخوانید

از هسته دربارهٔ مقصدی که شکست خورده بپرسید، نه دربارهٔ مسیر پیش‌فرض. route -n get 2001:db8::25 رابط و دروازهٔ انتخاب‌شده برای آن نشانی را چاپ می‌کند و netstat -rn -f inet6 کل جدول را برای مقایسه نشان می‌دهد. مسیر پیش‌فرض می‌گوید پیش‌فرضی وجود دارد؛ نمی‌گوید این مقصد از آن استفاده می‌کند.

DNS را در محفظهٔ خودش نگه دارید. تفکیک‌کننده‌ای که از طریق IPv4 دسترس‌پذیر است هنوز می‌تواند رکوردهای AAAA را برگرداند، پس شکست جست‌وجو و شکست مسیریابی همان نشانه را در مرورگر تولید می‌کنند.

سیاست مسدودسازی کارخواه را از یک بازمانده جدا کنید

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

پیش از آنکه مسدودسازی را آسیب بدانید، بفهمید کارخواه شما چه رفتاری را مستند کرده است. scutil --dns تفکیک‌کننده‌های مؤثر به‌ازای هر سرویس را نشان می‌دهد و همان‌جاست که تفکیک‌کنندهٔ نصب‌شده توسط کارخواه یا تنظیم DNS محدودشده دیده می‌شود. سپس بررسی کنید آیا قواعد پالایهٔ بسته‌ها نصب و جا گذاشته شده‌اند. مسدودسازی مورد انتظار و قاعدهٔ باقی‌مانده پاسخ‌های متضاد می‌خواهند و تنها مستندات مالک آن‌ها را از هم جدا می‌کند.

شواهد را ثبت کنید، سپس یک چیز را تغییر دهید

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

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