لماذا يفشل IKEv2 على أندرويد عند استخدام منفذ UDP غير قياسي

تستجيب البوابة لـ IKEv2 على UDP 4443 لسبب ما، وفي الملف الشخصي حقل يحمل اسم Server، وتكتب اسم المضيف والمنفذ، فيبلغ الهاتف أنه لا يستطيع الوصول إلى الخادم أو لا يستطيع تحليل العنوان. لا شيء محجوب هنا. النموذج الأصلي في أندرويد يتوقع اسم مضيف، والأمر ذاته ينطبق على ويندوز. المنفذ المخصص قدرة خاصة بالعميل قبل أن يكون إعدادًا في الخادم، وليس كل العملاء يتيحون التعبير عنه. اعمل على الأجزاء الثلاثة بالترتيب: ما يستطيع العميل قوله، وما يستمع إليه الخادم، وهل يؤطّر الطرفان الحزم بالطريقة نفسها.

ما أرسله الهاتف فعلًا

سلسلة host:port في حقل مخصص لاسم تُحلّ كاسم. لا يُرجع المُحلِّل شيئًا لـ vpn.example.net:4443، والخطأ الذي تراه هو فشل في تحليل الاسم أو تعذّر الوصول، لا مهلة منتهية على منفذ. هذا التمييز مهم، لأن إعادة المحاولة باسم أقصر أو شبكة أخرى لن تصلح أبدًا سلسلة لا يستطيع النموذج تحليلها.

ملف IKEv2 الأصلي على أندرويد، مثل عميل ويندوز المدمج، مثبّت على منافذ IKE القياسية. لا أحد منهما يعرض حقل منفذ، ولا يضيفه أي قدر من تحرير الملف الشخصي. إذا كان مستمع المشغّل فعلًا على 4443، فالعميل المدمج هو الأداة الخطأ، وليس أداة أُسيء ضبطها.

استخدم عميلًا يعرض المنفذ

يوثّق عميل strongSwan لأندرويد منفذ خادم قابلًا للضبط في إعداداته المتقدمة، ولهذا يظهر في كل وصفة عاملة تقريبًا لهذا التصميم. هذا الدعم يخص ذلك العميل: تطبيق IKEv2 آخر، أو نسخة معدّلة من التطبيق نفسه، قد لا يعرض الحقل ذاته رغم أن خادم strongSwan الأساسي يدعمه.

اطلب من المشغّل المجموعة كاملة دفعة واحدة: اسم البوابة، ومنفذ UDP، وطريقة المصادقة، وهوية الخادم التي يجب أن يتوقعها العميل. المنفذ المخصص ليس سببًا لتعطيل فحص الشهادات أو لتغيير البروتوكولات. أدخل المنفذ حيث يتوقعه العميل المثبّت، وإذا لم يكن لذلك العميل حقل كهذا، فالجواب عميل آخر معتمد لا حل ملتوٍ مُخمَّن.

للخادم منفذان، ويجب أن يتطابقا

يبدأ IKE على UDP 500، وعادةً ما ينقل اجتياز NAT بروتوكول IKE وESP المُغلَّف إلى UDP 4500. هذان إعدادان منفصلان في strongSwan، لذا فخادم نُقل إلى منفذ مخصص واحد يحتاج إلى تغيير كليهما إلى القيمة نفسها:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

مع منفذ واحد للدورين، على الخادم أن يميّز IKE من ESP داخل UDP على المقبس نفسه، ويفعل ذلك عبر علامة الأربعة بايتات غير الخاصة بـESP التي تسبق رسالة IKE. لهذا لا يستطيع العميل التفاوض على المنفذ المخصص ثم المتابعة بصمت على 4500، ولهذا تخفي عبارة “غيّر المنفذ فقط” شرطًا في التأطير.

إعادة التوجيه ليست مستمعًا

إعادة توجيه 4443 إلى مستمع IKE عادي هي نمط الفشل الذي يبدو ناجحًا تقريبًا. يصل التبادل الأول، ويجيب الخادم، ثم يتوقف الاتصال أو يعيد توليد المفاتيح إلى لا شيء، لأن الرد يخرج من منفذ آخر ولن تطابق حركة المرور المُغلَّفة اللاحقة الحالة التي أنشأها الطرفان. القاعدة التي تعيد كتابة منفذ الوجهة دون تحريك المستمع تنتج هذه النتيجة النصف مفتوحة بالضبط.

وعلى المسار أن يسمح بـUDP من الطرف إلى الطرف. مرور TCP 443 عبر شبكة فندق أو شبكة مشغّل لا يقول شيئًا عن IKEv2 على منفذ UDP، ولو كان بالرقم نفسه. حيث يُسمح فقط بـTCP 443، لا يحوّل منفذ UDP المخصص IKEv2 إلى HTTPS، وقد يكون الجواب الصحيح مسار وصول آخر بدلًا من تجربة منفذ أخرى.

افصل المراحل الثلاث عند الاختبار

التقط على الخادم بينما يحاول العميل مرة واحدة. الطلب الذي لا يصل قط مسألة نقطة نهاية أو جدار حماية؛ والطلب الذي يصل بلا رد مسألة مستمع أو سياسة؛ والرد الذي يتبعه صمت هو مسألة التأطير أو الهوية.

tcpdump -ni eth0 -vv udp port 4443

ثم اقرأ رسالة العميل لا مؤشره الدوّار. خطأ في المقترح يعني اختلاف الخوارزميات، وفشل المصادقة يعني اختلاف الهويات أو الشهادات، وإعادة الإرسال المتكررة بلا استجابة تعني أن شيئًا لا يجيب على ذلك المنفذ. اختبر مرحلة واحدة في المرة وغيّر حقلًا واحدًا بين المحاولات؛ توثيق strongSwan عن اجتياز NAT يصف العلامة وسلوك المنفذ الذي يريك الالتقاط إياه.