یک برنامه خطا می‌دهد و تقصیر به گردن VPN می‌افتد، اما درخواست هرگز به تونل نمی‌رسد. اگر macOS هنوز به آن برنامه می‌گوید از یک پروکسی محلی استفاده کند، اولین گام 127.0.0.1 است و هیچ چیزی روی آن گوش نمی‌دهد. بستن Charles همیشه تنظیم پروکسی سیستمی را که نصب کرده پاک نمی‌کند، بنابراین یک VPN سالم پشت یک سوکت مرده می‌نشیند. این ترتیبی است که با آن موضوع را تأیید کنید و فقط بخش اشتباه را درست کنید.

اولین گام همین Mac است، نه سرور

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

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

گام 1: وضعیت فعلی پروکسی را بخوانید

با نمای فقط‌خواندنی شروع کنید، چون می‌گوید سیستم پیش از تفسیر هر برنامه چه باوری دارد:

scutil --proxy

به HTTPEnable، HTTPProxy، HTTPPort، معادل‌های HTTPS و هر ProxyAutoConfigEnable همراه URL آن نگاه کنید. پروکسی فعال روی پورتی که هیچ چیز روی آن گوش نمی‌دهد همان خطای شماست. URL از نوع PAC شکل دیگر است: تنظیم می‌تواند بدون نشانی دستی قابل مشاهده فعال باشد، چون فایل در زمان درخواست پروکسی را انتخاب می‌کند.

سپس همان مقادیر را در تنظیمات سیستم، شبکه، سرویسی که واقعاً استفاده می‌کنید، جزئیات، پروکسی‌ها تأیید کنید. رابط گرافیکی و دستور همان انبار را می‌خوانند، پس اختلاف یعنی به سرویس دیگری نگاه می‌کنید.

گام 2: پیدا کنید که صاحب تنظیم است

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

Charles یکپارچه‌سازی مرورگر و پروکسی سیستمی خود را مستند می‌کند، از جمله کمک‌کننده macOS، پس ابتدا از کنترل‌های خودش و مسیر خاموش‌شدن آن استفاده کنید. کمک‌کننده دارای دسترسی ویژه برای تغییر پیکربندی وجود دارد؛ این دلیلی برای دادن دسترسی گسترده به یک نرم‌افزار بی‌ربط نیست.

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

گام 3: باریک‌ترین چیز را تغییر دهید

ورودی ناخواسته مشخص را برای سرویس مشخص غیرفعال کنید. هر سرویس را جابه‌جا نکنید و کل پنجره پروکسی را پاک نکنید، چون سرویس VPN و سرویس Wi-Fi زیرین تنظیمات جداگانه نگه می‌دارند و یکی از آن‌ها ممکن است درست باشد.

اگر پروکسی عمداً لازم است، شنونده تأییدشده‌اش را راه‌اندازی کنید نه اینکه سیاست را حذف کنید. این تفاوت در سازمان‌هایی مهم است که پروکسی تنها مسیر به اینترنت است و VPN مسیر دوم و باریک‌تر.

یک درخواست تازه از برنامه آسیب‌دیده را دوباره امتحان کنید. بعضی برنامه‌ها پروکسی را یک بار هنگام اجرا می‌خوانند، پس بستن و باز کردن دوباره بخشی از آزمون است نه خرافه.

گام 4: اگر پروکسی رفته و هنوز شکست می‌خورد

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

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

پیش از شروع برنامه بازگشت را بنویسید: مقادیر دقیق پروکسی را که یافتید یادداشت کنید تا بازگردانی یک رونوشت باشد نه تمرین حافظه. مستندات پیکربندی پروکسی Charles یکپارچه‌سازی و رفتار خاموش‌شدن آن را برای نسخه‌ای که اجرا می‌کنید توصیف می‌کند.

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

مقالات مرتبط