ما الذي يفعله حقل الوكيل في ملف تعريف VPN على أجهزة Apple فعلاً
ملء حقل وكيل لا يحوّل VPN إلى HTTP. هناك اتصالان، والحقل لا يصل إلا إلى أحدهما.
ملء حقل الوكيل في إعداد VPN على Apple يبدو وكأنه يجب أن يعيد توجيه النفق عبر منفذ ويب. لكنه لا يفعل ذلك. الحقل يختار وسيطاً على مستوى التطبيق للحركة التي يقرر تطبيق متوافق إرسالها إلى هناك. أما اتصال عميل VPN نفسه بالبوابة فيحكمه البروتوكول والمستمع والنقل الذي أعددته، وهذه قرارات منفصلة.
اتصالان، مالكَان
أي إعداد كهذا يتضمن اتصالاً من العميل إلى البوابة واتصالاً من التطبيق إلى الوجهة. قسم الوكيل يتحدث عن الثاني، رغم أنه يقع في الملف نفسه الذي يقع فيه الأول.
| 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 |
يسرد مرجع إعدادات الوكيل من Apple بروتوكولات 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 وإعدادات الشبكة الخاصة بالتطبيق. تلك طبقة ثالثة، وهي أيضاً ليست حقل الوكيل.