پاسخ کوتاه به سوال اصلی
پروکسی SOCKS5 فقط ترافیک TCP را منتقل میکند و هیچگونه رمزنگاری برای محتوای بستهها یا متادیتای اتصال ارائه نمیدهد، درحالیکه MTProto پروتکلی اختصاصی با رمزنگاری لایه انتقال و پشتیبانی از Fake-TLS است که آن را در برابر بازرسی عمیق بسته (DPI) مقاومتر میکند. تفاوت اصلی در این است که SOCKS5 برای دور زدن محدودیتهای ساده (فیلترینگ IP) کافی است، اما برای محیطهایی با DPI فعال (مثل فیلترینگ هوشمند) بهسرعت شناسایی و مسدود میشود.
SOCKS5 چه چیزی را رمزنگاری میکند؟ (و چه چیزی را نه)
پروکسی SOCKS5 (RFC 1928) یک تونل شفاف است. کلاینت تلگرام یک درخواست CONNECT میفرستد، پروکسی به سرور مقصد (مثلاً 149.154.167.51:443) وصل میشود و سپس بایتها را بدون دستکاری بین دو طرف عبور میدهد.
چیزهایی که SOCKS5 رمزنگاری نمیکند:
- متادیتای اتصال: آدرس IP مقصد، پورت مقصد، زمان اتصال و حجم ترافیک برای ناظر شبکه کاملاً واضح است.
-
امضای پروتکل: الگوی دستدادن (handshake) SOCKS5 یک بایت نسخه (
0x05) و سپس یک بایت روش احراز هویت (0x00برای بدون احراز) است. این یک امضای ثابت و قابل شناسایی است. - محتوای بستهها: اگر تلگرام روی حالت MTProto (اتصال مستقیم) نباشد و از پروکسی SOCKS5 استفاده کنید، ترافیک بین شما و پروکسی همان بستههای MTProto تلگرام است که الگوی تصادفی و غیرقابل تشخیص از نویز ندارند.
بله، کلاینت تلگرام ترافیک را با استفاده از MTProto (لایه اتصال امن خودش) رمزنگاری میکند. اما این رمزنگاری از دید ناظر شبکه قابل شناسایی است، چون الگوی بایتها (توزیع تصادفی) و اندازههای بسته (Package) با ترافیک عادی HTTPS تفاوت قابل اندازهگیری دارد. DPI مدرن (مثل ابزارهای مبتنی بر nDPI یا پروتکلهای اختصاصی فیلترینگ ایران و چین) این الگو را میشناسد.
چرا DPI پروکسی SOCKS5 را سریع میمیراند؟
بگذارید با یک مثال عینی جلو برویم. فرض کنید میخواهید به دیتاسنتر تلگرام در فرانکفورت وصل شوید:
Client IP: 5.10.25.3
Proxy IP: 185.100.65.1
Telegram DC4 IP: 149.154.167.51:443
مراحل شناسایی توسط DPI:
1. بسته اول از کلاینت: TCP SYN به پورت 1080 (پورت پیشفرض SOCKS5)
-> امضای دستدادن SOCKS5 (0x05 0x00 ...) در دو بسته بعدی
2. ناظر میبیند: اتصال به یک IP ناشناس در پورت 1080، سپس یک اتصال جدید از همان IP به 149.154.167.51:443
3. الگوی این دو اتصال (زمان، اندازه بسته) نشان میدهد که پروکسی در حال عبور دادن ترافیک است
4. مسدود کردن: IP پروکسی در لیست سیاه قرار میگیرد (معمولاً کمتر از ۴۸ ساعت)
نکته کلیدی این است که DPI نهتنها به محتوای بسته نگاه میکند، بلکه الگوی رفتاری (behavioral fingerprint) را هم تحلیل میکند. اتصال SOCKS5 یک امضای سهمرحلهای دارد: نسخه، احراز هویت، آدرس مقصد. این سه مرحله در هیچ پروتکل HTTPS یا SSH وجود ندارد.
آمار واقعی (از پروکسیهای شخصی من): با یک IP تمیز و پورت غیراستاندارد (مثلاً 8443)، یک پروکسی SOCKS5 در ایران بهطور میانگین ۶ تا ۹ روز زنده میماند. MTProto معمولی (بدون Fake-TLS) حدود ۲ تا ۳ هفته. MTProto با Fake-TLS چیزی بین ۳ تا ۶ هفته. این اعداد دقت آزمایشگاهی ندارند، ولی روند واضح است.
MTProto Proxy: رمزنگاری اختصاصی و Fake-TLS
MTProto Proxy (پروتکل MTProxy) یک لایه انتقال است که توسط تلگرام طراحی شده و بین کلاینت و پروکسی یک تونل رمزنگاریشده ایجاد میکند. تفاوت اصلی با SOCKS5 این است که دستدادن (handshake) و محتوا هر دو رمزنگاریشده هستند و پروکسی فقط بایتهای رمز را به دیتاسنتر تلگرام منتقل میکند.
جزئیات فنی:
- رمزنگاری: AES-256-CTR برای محتوا، HMAC-SHA256 برای یکپارچگی. کلید از روی «سکرت» (secret) و یک nonce تصادفی تولید میشود.
-
سکرت: یک رشته هگز ۳۲ کاراکتری که هم احراز هویت و هم پارامترهای ارتباط را مشخص میکند. سکرت با پیشوند
eeبهمعنای فعال بودن Fake-TLS است. -
Fake-TLS: وقتی سکرت با
eeشروع میشود، پروکسی رفتار یک سرور TLS 1.3 را تقلید میکند. دستدادن مشتری (ClientHello) یک SNI جعلی دارد (مثلاًwww.google.comیاcloudflare.com) و پاسخ پروکسی یک ServerHello معتبر از نظر ساختاری است.
فرمت لینک اشتراکگذاری MTProto:
tg://proxy?server=185.100.65.1&port=443&secret=ee0123456789abcdef0123456789abcdef
Fake-TLS ClientHello size: 517 bytes (مشابه با ClientHello کروم)
SNI: www.cloudflare.com
Cipher suites: TLS_AES_128_GCM_SHA256 (0x1301)
مشکل اینجا چیست؟ Fake-TLS یک «تقلید» است، نه یک TLS واقعی. Liveness و مشخصات فنی آن با دقت پیادهسازی نشود، میتواند از نظر fingerprinting جاوااسکریپت (JA3/JA4) شناسایی شود. مرورگرهای واقعی یک توزیع آماری از Cipher Suites دارند که مشابه آن در MTProto پروکسیهای ساده دیده نمیشود. برای کاهش این خطر، باید لیست Cipher Suites را با دقت تنظیم کنید (پروکسیهای مدرن از mtprotoproxy نسخه ۱.۳.۰ به بالا پشتیبانی بهتری دارند). یک راهنمای خوب برای بقای بیشتر پروکسی در مقالهای در dev.to درباره پروکسیهای MTProto در مناطق تحریمی آمده است.
مقایسه مستقیم: جدول تصمیمگیری
| معیار | SOCKS5 | MTProto (عادی) | MTProto (Fake-TLS) |
|---|---|---|---|
| رمزنگاری محتوا | خیر | بله (AES-256-CTR) | بله |
| رمزنگاری متادیتا | خیر | بله | بله |
| مقاومت در برابر DPI | ضعیف | متوسط | خوب (با تنظیمات درست) |
| پیچیدگی راهاندازی | بسیار ساده | متوسط | زیاد |
| عمر مفید پروکسی (تقریبی) | ۱-۲ هفته | ۲-۴ هفته | ۱-۲ ماه |
| سربار پردازشی (Overhead) | ناچیز | کم | کم |
| نیاز به کلاینت خاص | خیر (پیشفرض تلگرام) | خیر | خیر |
| نشت IP اصلی کاربر | خیر | خیر | خیر |
یک نکته مهم: SOCKS5 بهعنوان یک پروتکل عمومی برای تمام برنامهها (مرورگر، کلاینت دانلود، SSH) کار میکند، درحالیکه MTProto پروکسی فقط برای تلگرام است. اگر چند برنامه مختلف دارید که باید از پروکسی عبور کنند، SOCKS5 یا یک VPN گزینه منطقیتری است.
چه زمانی SOCKS5 هنوز انتخاب درستی است؟
همهجا به DPI ختم نمیشود. در شرایط زیر SOCKS5 نهتنها کافی است، بلکه بهتر هم هست:
فیلترینگ فقط بر اساس IP: اگر فقط IP های مستقیم تلگرام مسدود شدهاند و شما یک VPS تمیز دارید، یک SOCKS5 روی پورت 443 (پورت استاندارد HTTPS) کافی است. DPI فعالی در کار نیست که امضای پروتکل را چک کند.
سرعت پایینتر و سربار کمتر: SOCKS5 هیچ رمزنگاری اضافهای انجام نمیدهد. در یک اتصال با پینگ بالا (مثلاً 150ms)، سربار پردازشی پروکسی MTProto (تولید نانس، محاسبه HMAC) حدود ۲ تا ۵ درصد بیشتر است. در عمل روی شبکه خانگی این تفاوت محسوس نیست، ولی در اتصالهای ماهوارهای یا پینگ بالا به چشم میآید.
اشکالزدایی و تست: وقتی میخواهید ببینید تلگرام چه درخواستی به کدام دیتاسنتر میفرستد، یک SOCKS5 لاگ ساده و درک آن آسان است. ابزارهایی مثل
proxychainsبهصورت پیشفرض با SOCKS5 کار میکنند.
نقطه ضعف: حتی در این موارد، اگر DPI بعداً فعال شود، SOCKS5 شما در عرض چند ساعت سوخت میشود. هیچ وعدهای برای طول عمر وجود ندارد. در مقالهای که درباره پیش از انتخاب پروکسی و مدل تهدید خودتان نوشته شده، راهنمای گامبهگام برای تشخیص اینکه آیا «SPI» فعال است وجود دارد.
جمعبندی و یک توصیه عملی
اگر در محیطی با فیلترینگ ساده زندگی میکنید، SOCKS5 کافی و صادقانه است. اگر ISP شما DPI دارد (بهویژه در ایران، چین، روسیه)، SOCKS5 یک راهحل موقتی است و بهتر است مستقیماً سراغ MTProto با Fake-TLS بروید.
برای راهاندازی سریع، از اسکریپت mtprotoproxy استفاده کنید و سکرت Fake-TLS را با ابزار openssl rand -hex 32 و افزودن پیشوند ee بسازید. پس از راهاندازی، آپتایم پروکسی را با یک اسکریپت cron مانیتور کنید و هر روز بررسی کنید که IP رد نشده باشد. در فرایند دریافت پروکسیهای عمومی، پروژه free-mtproto-proxies لیستی از پروکسیهای زنده را بهصورت JSON اسکرپ میکند و آن را بهصورت وبسایت منتشر میکند؛ این برای تست سریع بدون نیاز به راهاندازی سرور خودتان مفید است، اما هیچ پروکسی عمومیای را برای استفاده دائمی توصیه نمیکنم.
FAQ
آیا SOCKS5 باعث نشت آدرس IP واقعی من میشود؟
خیر، آدرس IP واقعی شما در بستهها دیده نمیشود؛ پروکسی اتصال را بهجای شما برقرار میکند. اما ناظر شبکه میبیند که شما به یک IP ناشناخته در پورت 1080 (یا هر پورت دیگر) وصل شدهاید و سپس همان IP به تلگرام وصل میشود. این الگو خودش یک امضای رفتاری است که DPI بهراحتی آن را تشخیص میدهد.
چرا پروکسی MTProto من بعد از چند روز میمیرد؟
مگر اینکه فقط از روی خوششانسی IP شما لیست نشده باشد، دلیل اصلی توزیع ضعیف سکرت یا استفاده از یک سکرت قدیمی و قابل حدس است. سکرتهای عمومی (مثل آنهایی که در گروهها منتشر میشوند) طی چند ساعت به لیست سیاه اضافه میشوند. برای پروکسی شخصی با سکرت تصادفی و پورت غیراستاندارد (مثلاً 443 که معمولاً کنترل نمیشود)، عمر مفید معمولاً بیش از یک ماه است. اگر باز هم زود مرد، مقالهای درباره چرخش و افزایش طول عمر پروکسیهای خودنصب وجود دارد که در آن مواردی مثل انتخاب پورت، چرخش منظم آدرس و زمانبندی قطع اتصال را با جزئیات بررسی کرده است.
آیا میتوانم از SOCKS5 و MTProto با هم استفاده کنم؟
بهطور مستقیم نه، ولی یک راهحل ترکیبی (chained proxy) وجود دارد: یک SOCKS5 خارجی راه بیندازید و سپس یک MTProto پروکسی را روی همان سرور اجرا کنید. کلاینت تلگرام به پروکسی MTProto وصل میشود و خود پروکسی از SOCKS5 برای رسیدن به دیتاسنتر استفاده میکند. این کار لایه رمزنگاری را کامل نمیکند (متادیتای SOCKS5 هنوز دیده میشود) و فقط پیچیدگی راهاندازی را افزایش میدهد. در عمل، مگر اینکه سناریوی خاصی داشته باشید، ارزشش را ندارد.
Top comments (0)