تعرض auth_key_id في تليجرام: الأسباب العميقة والحل الأمثل (إصلاح mtproto لا يعمل، mtrproto، mtporoto)

I. ما هو auth_key_id ولماذا يهم؟

auth_key_id (معرف مفتاح التفويض) هو قيمة 64 بت داخل كل رأس رسالة MTProto مشفرة. يتم اشتقاقه من البتات 64 السفلية من تجزئة SHA-1 لمفتاح التفويض (auth_key). فكر فيه كـ "رقم المفتاح" – يستخدمه الخادم لتحديد موقع مفتاح فك التشفير الصحيح بسرعة.

الخصائص الرئيسية: الثبات (لا يتغير عبر الشبكات والجلسات وإعادة التشغيل)، التفرد (معرف لكل جهاز)، الإرسال كنص عادي (في الرأس الخارجي قبل التشفير). هذا المزيج "الثابت + الفريد + النص العادي" يجعله بصمة تتبع مثالية لأي مراقب شبكة سلبي.

II. السبب الجذري: خيارات تصميم تليجرام

2.1 الطبقات الثلاث لـ MTProto

• طبقة التطبيق: بيانات الدردشة (تسلسل TL) — لا تحتوي على auth_key_id
• طبقة التشفير: حمولة مشفرة AES-256 مع إلحاق auth_key_id و msg_key — يعيش auth_key_id هنا
• طبقة النقل: نفق TCP/UDP/بروكسي — مجرد ناقل

2.2 المشكلة الحقيقية: التخلي عن TLS الإلزامي

تستخدم عملاء تليجرام اتصالات TCP غير مشفرة افتراضيًا (حتى عند استخدام المنفذ 443، فهو TCP خام بدون مصافحة TLS). يتم إلقاء حزمة MTProto بأكملها – بما في ذلك auth_key_id كنص عادي – على الشبكة. يمكن لأي كيان لديه قدرة التقاط حزم سلبية استخراجه. في المقابل، تفرض Signal و WhatsApp وغيرها من المنافسين TLS كطبقة نقل. لقد حول منطق تليجرام الرسمي "الأداء" و"تجاوز الرقابة" auth_key_id إلى معرف جهاز يتم بثه علنًا.

III. لماذا يفشل Fake TLS المدمج في MTProto (بروكسي ee) (ويؤدي إلى mtproto لا يعمل)

بروكسي ee هو تشويش على مستوى النقل، وليس تشفيرًا. يقوم بتغليف حزم MTProto داخل مصافحة TLS 1.3 مزيفة، ولكن هذا الغلاف مجرد تمويه – يظل رأس النص المشفر الداخلي لـ MTProto (بما في ذلك auth_key_id) دون تغيير. يمكن لأي نظام DPI قادر على تقشير التمويه (عبر تحليل بصمة TLS، أو الاختبار النشط، أو التصنيف بالتعلم الآلي) لا يزال قراءة auth_key_id. بعد ترقيات DPI الروسية في أبريل 2026، تم التعرف على بصمات مصافحة Fake TLS على نطاق واسع، مما تسبب في تقارير هائلة عن mtproto لا يعمل – بينما استمرت خدمات VLESS+Reality على نفس الخادم في العمل بشكل مثالي.

IV. الحل الأمثل: نفق VLESS + Reality

4.1 الفكرة الأساسية

أضف طبقة تشفير حقيقية أخرى تحت طبقة النقل، مع تشفير حزمة MTProto بأكملها (بما في ذلك auth_key_id) ككتلة واحدة وتمويهها كحركة مرور HTTPS الأكثر شيوعًا.

4.2 تقسيم العمل: VLESS و Reality

• VLESS: بروتوكول نقل خفيف الوزن، بدون رؤوس إضافية، يعيد توجيه البيانات كما هي.
• Reality: يستعير شهادات TLS من مواقع ويب حقيقية (على سبيل المثال، update.microsoft.com)، مما يجعل الاتصال بأكمله يبدو وكأنه تصفح HTTPS عادي. حتى DPI المدعوم بالذكاء الاصطناعي لا يمكنه تمييزه.

[رسالة الدردشة] → [طبقة تشفير MTProto (auth_key_id كنص عادي)] → [نفق VLESS+Reality (تشفير مزدوج + تمويه HTTPS)] → [الإنترنت]

لماذا هو مثالي؟ يتم تشفير auth_key_id بشكل مزدوج ولا يظهر أبدًا على السلك العام؛ بصمة حركة المرور مطابقة لمتصفح يزور موقعًا حقيقيًا؛ إنه يحمي جميع حركة مرور الجهاز، وليس فقط تليجرام.

V. مقارنة الميزات

الميزة	بروكسي MTProto (ee Fake TLS)	نفق VLESS+Reality
الهدف الأساسي	تجنب التعرف على بروتوكول DPI	إخفاء الحزمة بأكملها بالكامل
يخفي auth_key_id؟	❌ لا (غلاف خارجي فقط)	✅ نعم (تشفير مزدوج، تغليف كامل)
مقاومة البصمة	ضعيفة (أنماط مصافحة TLS قابلة للكشف)	قوية (يستعير شهادات حقيقية + بصمة uTLS)
الأداء بعد أبريل 2026	فشل واسع النطاق (mtproto لا يعمل)	تشغيل مستقر
النطاق	تليجرام فقط	حركة مرور كاملة (أي تطبيق)

VI. دليل التنفيذ (نسخة مختصرة)

6.1 نشر خادم VLESS+Reality (خارج المناطق المقيدة)

# تثبيت Xray-core
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

# إنشاء زوج مفاتيح Reality
xray x25519

# تحرير /usr/local/etc/xray/config.json، المعلمات الرئيسية:
# "dest": "update.microsoft.com:443" (نطاق التمويه)
# "serverNames": ["update.microsoft.com"]
# "privateKey": "مفتاحك-الخاص"
# "shortIds": ["6ba85179e30d4fc2"]

6.2 تكوين العميل (يوصى بـ v2rayNG / Nekobox / v2rayN)

• استيراد رابط VLESS+Reality أو رمز QR؛
• تعيين "بصمة uTLS" إلى chrome أو safari؛
• تمكين البروكسي، ثم في إعدادات بروكسي تليجرام قم بتوجيه إلى SOCKS5 المحلي (على سبيل المثال، 127.0.0.1:1080). هذا يجبر محادثة MTProto بأكملها عبر النفق، مما يحمي auth_key_id من طرف إلى طرف.

VII. الخلاصة والنظرة المستقبلية

تعرض auth_key_id ليس عيبًا في طبقة تشفير MTProto – بل هو نتيجة مباشرة لقرار تليجرام بالتخلي عن تشفير طبقة النقل. يوفر بروكسي ee المدمج (Fake TLS) فقط تشويشًا سطحيًا؛ لا يمكنه إخفاء هذا المعرف الثابت حقًا. الحل الأمثل الحقيقي هو إنشاء نفق مشفر حقيقي في طبقة أقل – VLESS+Reality. إنه يشفر بشكل مزدوج حزمة MTProto بأكملها ويتمويه كـ HTTPS عادي، مما يجعل auth_key_id غير مرئي تمامًا على الإنترنت العام مع هزيمة أكثر DPI تقدمًا مدعوم بالذكاء الاصطناعي اعتبارًا من 2026.

للمستخدمين في المناطق عالية الخطورة مثل روسيا وإيران، لم يعد هناك حاجة للاعتماد على بروكسيات تليجرام الخاصة. انشر نفق VLESS+Reality – لن تحمي فقط auth_key_id الخاص بتليجرام ولكن أيضًا تستعيد الوصول الآمن إلى الإنترنت بأكمله. تستمر لعبة القط والفأر؛ البقاء على اطلاع بتقنيات الدفاع هو أفضل ممارسة للخصوصية.

تستند هذه المقالة إلى تقرير Symbolic Software GNMX‑01 لعام 2026، وحادثة ترقية DPI الروسية في أبريل 2026، ووثائق VLESS+Reality التقنية العامة.