فیلد Proxy در پروفایل VPN اپل در واقع چه کار می‌کند
پر کردن یک فیلد پروکسی، VPN را به HTTP تبدیل نمی‌کند. دو اتصال درگیر است و این فیلد فقط به یکی از آن‌ها می‌رسد.
پر کردن فیلد Proxy در یک پیکربندی VPN اپل حس می‌دهد که باید تونل را از یک پورت وب عبور دهد. اما این کار را نمی‌کند. این فیلد یک واسطه در سطح برنامه را برای ترافیکی انتخاب می‌کند که یک برنامه سازگار تصمیم می‌گیرد به آنجا بفرستد. اما اتصال خودِ کلاینت VPN به دروازه‌اش را پروتکل، شنونده و ترانسپورتی که پیکربندی کرده‌اید تعیین می‌کند، و این‌ها تصمیم‌های جداگانه‌ای هستند.
دو اتصال، دو مالک
هر تنظیمی مانند این شامل اتصال کلاینت به دروازه و اتصال برنامه به مقصد است. بخش Proxy درباره دومی صحبت می‌کند، هرچند در همان پروفایل اولی قرار دارد.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
مرجع تنظیمات پروکسی اپل HTTP، HTTPS، SOCKS و پیکربندی خودکار پروکسی را فهرست می‌کند که توصیفی از گزینه‌های پروکسی برنامه‌هاست. هیچ‌یک از این ورودی‌ها چیزی درباره این نمی‌گوید که بسته IPsec یا WireGuard چگونه به دروازه می‌رسد.
یک بررسی سریع که موضوع را روشن می‌کند. پورت و پروتکلی را که کلاینت VPN در گزارش خود اعلام می‌کند نام ببرید. اگر آن خط هنوز UDP 500 یا UDP 51820 می‌گوید، فیلد پروکسی چیزی در آن تغییر نداده است.
کِی این فیلد ابزار درست است
یک مورد واقعی وجود دارد که پروکسی جلوی تونل می‌نشیند، اما این ویژگی کلاینت است، نه فیلدی در پروفایل. راهنمای OpenVPN گزینه --http-proxy را برای اتصال‌های TCP که از طریق پروکسی HTTP CONNECT منتقل می‌شوند مستند کرده است. استفاده از آن به گزینه متناظر کلاینت، دروازه‌ای که از این راه در دسترس باشد و پروکسی‌ای نیاز دارد که CONNECT به پورت مورد استفاده را مجاز کند.
اگر کلاینت شما آن گزینه را ارائه می‌دهد و شبکه CONNECT به پورت را مجاز می‌کند، ممکن است کار کند. اگر کلاینت آن را ارائه نمی‌دهد، پر کردن یک پروکسی سیستمی هیچ اثری بر تونل ندارد.
کِی هیچ چیز را تغییر نمی‌دهد
یک پروفایل IKEv2 یا IPsec فقط به خاطر پر بودن فیلد پروکسی به تونل HTTP تبدیل نمی‌شود. WireGuard هم نه، چون قالب پیکربندی آن هیچ مفهومی از پروکسی ندارد. تغییر پورت دروازه هم پروتکل آن را تغییر نمی‌دهد. و نقطه پایانی که به HTTPS معمولی پاسخ می‌دهد، به‌طور خودکار شنونده VPN نیست.
همان تله کسانی را می‌گیرد که پروفایل‌های دوره PPTP را از راهنماهای قدیمی iPad کپی می‌کنند. گزینه‌ها هنوز در رابط وجود دارند؛ سرویس پشت آن‌ها دیگر آن پروتکل را صحبت نمی‌کند.
تصمیم اینکه کدام لایه را درست کنیم
قبل از تغییر هر چیزی بپرسید کدام لایه شکست خورده است. اگر کلاینت نمی‌تواند نشستی برقرار کند، مشکل ترانسپورت است و فیلد پروکسی بی‌ربط است. اگر تونل برپاست اما یک برنامه به سرور خود نمی‌رسد، بررسی پروکسی برنامه ارزش دارد. اگر تونل برپاست و همه برنامه‌ها شکست می‌خورند، مسیریابی و DNS داخل تونل مشکوک هستند.
برای مورد اول، از اپراتور بپرسید کدام ترانسپورت یا شبکه جایگزین تأییدشده را پشتیبانی می‌کند. OpenVPN روی TCP 443 وجود دارد چون بعضی شبکه‌ها فقط آن را مجاز می‌کنند، و هنوز نیاز دارد که سرور به آن گوش دهد.
پورت UDP مسدود را مجوز بداهه‌پردازی نگیرید. بررسی‌های گواهی یا هویت دروازه را دست‌نخورده نگه دارید، نه اینکه برای جا افتادن دست‌دهی آن‌ها را غیرفعال کنید.
دو لایه را یکی‌یکی تأیید کنید
اول تونل را تأیید کنید: در صفحه وضعیت کلاینت نشست برقرارشده و شمار بایت غیرصفر را ببینید. سپس تنظیم پروکسی را مستقیم بخوانید، با scutil --proxy برای پیکربندی مؤثر یا networksetup -getwebproxy Wi-Fi برای مقدار ذخیره‌شده. سپس یک برنامه را که پروکسی سیستم را رعایت می‌کند و یکی را که آن را نادیده می‌گیرد آزمایش کنید، چون بسیاری از برنامه‌های بومی آن را نادیده می‌گیرند.
سه نتیجه، سه اصلاح متفاوت.
اگر هر دو لایه موفقیت را گزارش کنند و برنامه هنوز شکست بخورد، تونل‌سازی تقسیم‌شده، DNS و تنظیمات شبکه خود برنامه را بررسی کنید. آن یک لایه سوم است، و آن هم فیلد پروکسی نیست.