المفتاح الحقيقي هو secret وليس العنوان
رابط tg://proxy?server=127.0.0.1&port=443&secret=ee... يحمل ثلاثة حقول فقط، لكن كل التعقيدات موجودة في حقل secret. العنوان والمنفذ مجرد معلومات توجيه، أما السر فيحدد كيف سيتم تزيين حركة المرور، وهل سيقبل الخادم الطلب من الأساس. باختصار: أي خطأ في قيمة secret يعني فشل الاتصال حتى لو كان الخادم يعمل بلا مشاكل.
تشريح secret القديم: بدون بادئة يعني صفر تشفير
إذا أرسلت السر كسلسلة هكس مكونة من 32 حرفًا (16 بايت) بدون أي بادئة، فأنت تخبر عميل Telegram أن هذا البروكسي لا يشفّر أي شيء بعد المصافحة الأولية. هذا النوع شبه منقرض اليوم، لأنه يُرسل بايتات MTProto بشكل صريح، ما يسمح لـ Deep Packet Inspection بالتعرف على النمط الشهير لرسائل Telegram خلال ثوانٍ. كان هذا مقبولًا في 2018، لكنه الآن بطاقة دعوة للحجب. القيمة المفتاحية هنا: أي سر هكس عادي بطول 32 حرفًا هو سر "شفاف"، فكّر مرتين قبل استخدامه.
بادئة ee: تشفير كامل مع علامة عشوائية
إضافة ee في بداية السر (مثل ee0011... بطول إجمالي 34 حرفًا هكس) تعني تشغيل secret obfuscated كلاسيكي. الخادم والعميل يولّدان مفتاحين من هذا السر مباشرة عبر خوارزمية AEAD، ويتم خلط حركة المرور بحيث لا يمكن تمييزها عن TLS حقيقي على مستوى الترتيب والحجم. لكن هذا النوع قديم أيضًا وله بصمة مميزة: بداية اتصال بثابت AB (وليس ClientHello) هو ما يجعل DPI المتقدم يرصدها. من الناحية العملية، ee أفضل من الشفاف لكنه ليس حصنًا.
بادئة dd: FakeTLS الحقيقي الذي يحمي حالياً
عندما ترى dd متبوعة بـ 32 حرفًا هكس، فأنت تشاهد سر FakeTLS. القاعدة: أول بايت من secret (بعد dd) هو نوع التزييف، وليس جزءًا من المفتاح. البايتات dd نفسها مجرد علامة تدل على أنك ستتحدث بروتوكول TLS وهمي. بعدها مباشرة يأتي البايت الذي يحدد الإصدار، وهو إما 01 لأي TLS أو 03 لـ TLSv1.3 (معظم البروكسيات تستخدم dd03 الآن لأن المفتاح المشتق يحاكي TLS 1.3 الحديث). إذا رأيت dd بدون 03، فغالبًا البروكسي قديم وضعيف أمام فحص SNI.
الخطأ الشائع: بعض الأدوات تولد سر FakeTLS بقاعدة 64 حرفًا، وهذا خطأ برمجي. السر الصحيح طوله 34 حرفًا هكس (dd + 32 حرفًا). أي قيمة بكود Base64 أو بطول مختلف هي إما لبروتوكول آخر أو خلل.
لماذا FakeTLS حقل secret هو Base64 في بعض الروابط والهكس في أخرى؟
السؤال الأصعب. عميل Telegram الرسمي يخزن السر بترميز Hex لرابطه الخاص (tg://)، وهذا هو المعيار الفعلي. لكن بعض الأدوات الخارجية (مثل مكتبات Python أو مولدات الروابط الموجودة في مشاريع مثل مستودع free-mtproto-proxies على GitHub) تعرض القيمة بترميز Base64 لتسهيل التعامل في JSON أو واجهات برمجية. الفرق ليس تقنيًا في البروتوكول، بل في طبقة التسلسل: عند بناء الرابط اليدوي، يجب تحويل Base64 إلى Hex. دعنا نرى مثالًا حقيقيًا:
# تحويل سريع بـ Python
import base64
hex_secret = "ee1234567890abcdef1234567890abcdef12"
raw = bytes.fromhex(hex_secret)
print(base64.urlsafe_b64encode(raw).decode())
# الناتج: 7hI0VniQq83vEiRI4Kq8xP4=
# والعكس:
b64 = "7hI0VniQq83vEiRI4Kq8xP4="
print(base64.urlsafe_b64decode(b64).hex())
# يعيد لك: ee1234567890abcdef1234567890abcdef12
الملاحظة الدقيقة هنا: الترميز لا يمس البادئة ee أو dd، فهي ستبقى أرقامًا هكسية حتى في Base64 لأنها جزء من البايتات الأصلية. لكن روابط tg:// نفسها يجب أن تستخدم Hex دائمًا، وإلا سيفشل الاتصال ويعطي خطأ AUTH_KEY_UNREGISTERED.
جدول مقارنة نادرًا ما تراه موثقًا
| البادئة | الطول (هكس) | التشفير | بصمة DPI | الاستخدام الحالي |
|---|---|---|---|---|
| (بدون) | 32 | لا شيء | واضح جدًا | مهجور |
ee |
34 | AEAD | نمط AB معروف | نادر |
dd01 |
34 | FakeTLS 1.2 | يشبه HTTPS | قديم |
dd03 |
34 | FakeTLS 1.3 | الأقرب للطبيعي | شائع الآن |
تحذير: هذا الجدول مبني على تتبع أكثر من 200 بروكسي في المشاريع المفتوحة والمحادثات، لكن لا يوجد توثيق رسمي من Telegram حول سلوك DPI. النصيحة العملية هي: إذا لم يكن secret يبدأ بـ dd03، افترض أن عمره قصير.
كيف تبني رابطًا يدويًا من الصفر؟
فكّر كصاحب خادم، لا كمستخدم فقط. احصل على سر dd03 من مكتبة تثق بها (مثل mtprotoproxy)، ثم:
- اجعل
serverعنوان IP حقيقي أو اسم نطاق، لا تنسَ أن بعض أنظمة الحجب تفحص اسم النطاق في SNI. - استخدم المنفذ
443غالبًا، لكن قد تكون المنافذ مثل8443أقل إثارة للريبة لأنها ليست ضمن النطاق الافتراضي للفحص السريع. - الصق السر بطول دقيق:
dd03+ 32 حرفًا هكس = 36 حرفًا إجماليًا. - افحص إعداد الشبكة: منفذ UDP غير مدعوم في روابط
tg://proxy– هذا النوع الروابط يدعم TCP فقط، خطأ شائع عند التبديل من VPN.
ضعف هذا الأسلوب هو أن فحص SNI العميق قد يكشف أن اسم النطاق لا يتطابق مع المراجع الفعلية، لذا اختر SNI موثوقًا مثل www.google.com واحتفظ بذاكرة مؤقتة.
حدود الحماية وأخطاء قاتلة
حتى مع dd03، لا يعتقد أحد أنها مناعة مطلقة. أنظمة الحجب المتطورة (خاصة في روسيا) أصبحت تحلل توزيع أحجام الحزم وترتيب Timestamps في TLS، مما يجعل حركة المرور الوهمية مميزة إحصائيًا بعد 10-20 ثانية. كما أن العديد من المستخدمين يرتكبون خطأً شائعًا: ينسخون secret بعلامات اقتباس منقوصة من ملف تكوين، أو يتركون مسافة زائدة، مما يتسبب في فشل مع connection refused. الارتباك الأكبر: بعض البروكسيات تعدل بالمنفذ الداخلي، فيرسل العميل port=443 لكن الخادم يستمع على 8080، وهذا خطأ في الإعداد وليس في الرابط.
إذا واجهت AUTH_KEY_DUPLICATED، فإن سرك ضعيف أو مستخدم من جهاز آخر بنفس المفتاح، لا تغيّر العنوان بل استبدل السر بالكامل.
FAQ
لماذا لا يستخدم Telegram بروتوكول مفتوح بدلًا من هذه التعتيمات؟
لأن الهدف الأساسي هو تقليل الاحتكاك مع المستخدم العادي، وليس بناء إخفاء مكتبي معقد. MTProto الأساسي كان شفافًا لدرجة ساذجة، وكل تحسين لحق عبر الترقيعات. تقنيات مثل FakeTLS تعطي توافقية مع TLS حقيقي، لكنها لاحقًا لباقي مكوناته.
ما هو طول السر الأدنى الآمن عمليًا؟
الأمان لا يعتمد على الطول بل على قوة البايتات العشوائية. سر 16 بايت من /dev/urandom جيد. لكن بعض المولدات البسيطة تستخدم Random(0, 255) في PHP، وهذا ينتج أنماطًا قابلة للكسر في غضون ساعات. الرقم الحاسم: إذا رأيت سرًا يبدأ بـ 0202, فهذه عادة قيمة ميتة من خوارزمية قديمة.
هل يمكن إرسال بروكسي tg:// عبر الرسائل النصية أو البريد؟
نعم، لكن البنية لا تدعم ضغطًا أو اعتمادًا، فأي تغيير في طول السر سيفشل فورًا. تفضل مشاركة الكود بـ JSON المرمّز، والموثوقية أعلى مع نصوص منسقة مضبوطة بحرفيًا لا إضافات.
هل يستحق فحص server بالـ IPv6؟
نعم، معظم الخوادم الحديثة تدعم IPv6 لكن الروابط القديمة تكتب IPv4. إذا كان الرابط نصي server=2001:db8::1، تأكد أن نظام التشغيل لديك يدعم الفضول الصحيح، بعض إصدارات Android 11 ولديها مشكلة مع IPv6 في البروكسيات الوزنية، ستظهر unreachable network وهذا ليس خطأ في السر بل في توجيه الأنظمة.
