پرش به محتویات

مقاومت در برابر DPI

Teleproxy شامل چندین لایه دفاعی در برابر سیستم‌های بازرسی عمیق بسته (DPI) است که تلاش می‌کنند ترافیک MTProxy را شناسایی و مسدود کنند.

وضعیت فعلی تهدیدات

سیستم‌های DPI روسیه (TSPU/ASBI) پروتکل MTProxy fake-TLS را به عنوان یک پروتکل مجزا («TELEGRAM_TLS») طبقه‌بندی می‌کنند. شناسایی بر پایه اثر انگشت TLS سمت کلاینت است: ClientHello اپلیکیشن تلگرام یک اثر انگشت JA4 ثابت دارد که DPI آن را با یک امضا تطبیق می‌دهد. پروکسی نمی‌تواند این را تغییر دهد — بایت‌ها را کلاینت تلگرام تولید می‌کند، نه سرور.

در سال ۲۰۲۶ دو موج مسدودسازی متمایز رخ داده است و پس از آن یک پاسخ از سمت کلاینت:

آوریل ۲۰۲۶ (اثر انگشت ثابت). TSPU اثر انگشت ثابت JA4/JA3 را تطبیق می‌داد و به نشانه‌هایی تکیه می‌کرد که هیچ مرورگر واقعی ارسال نمی‌کند (کد افزونه نامعتبر 0xfe02 و یک فیلد تصادفی ۲۰ بایتی). تلگرام این آرتیفکت‌ها را سمت کلاینت برطرف کرد (tdesktop PR #30513، DrKLO Android PR #1949) و این اتصال را تا اواخر مه بازگرداند.

اواخر مه – ژوئن ۲۰۲۶ (بازسازی + همبستگی جریان). اصلاح آوریل فقط یک اثر انگشت ثابت را با دیگری جایگزین کرد — کلاینت همچنان یک JA4 ثابت ارسال می‌کند. این موج سخت‌تر است:

  • اکنون TSPU جریان‌های TCP را بازسازی می‌کند پیش از گرفتن اثر انگشت، بنابراین تقسیم ClientHello بین بخش‌ها دیگر آن را پنهان نمی‌کند. آزمایش‌های میدانی که MSS سرور را به‌شدت پایین آوردند (۲۵۶ و سپس ۸۸ بایت) و روی شبکه تأیید شدند، باز هم روی گره‌های بازسازی‌کننده مسدود شدند.
  • همبستگی فعال جریان. چند ClientHello با SNI یکسان + JA4 تلگرام به یک ip:port باعث قطع موقت اتصال می‌شود. IP پروکسی نیز با رکورد A دامنه پوشش بررسی می‌شود — یک SNI تصادفی که به IP پروکسی resolve نشود عبور نمی‌کند. چرخش SNI بین دامنه‌های پوشش واقعی یا پخش روی IP/پورت‌ها این همبستگی را خنثی می‌کند.
  • افت بی‌صدای بسته، بدون RST. دست‌تکانی TLS کامل می‌شود؛ به‌محض شروع داده‌های اپلیکیشن MTProto، بسته‌ها بدون ریست رها می‌شوند و کلاینت با ارسال مجدد سیل می‌کند (نشانه «وصل می‌شود، سپس بعد از ~۳۰ ثانیه قطع می‌شود»).

اوت ۲۰۲۶ (به‌روزرسانی اثر انگشت کلاینت). در ۲۲ اوت ۲۰۲۶ تلگرام ClientHello جدیدی برای fake-TLS در Desktop 7.1 و Android 12.10.0 منتشر کرد. دو چیز تغییر کرد:

  • سه کدپوینت طرح امضای ML-DSA (0x0904/0x0905/0x0906، یعنی mldsa44/mldsa65/mldsa87) به ابتدای signature_algorithms اضافه شد تا با پروفایل کروم فعلی هم‌خوانی داشته باشد.
  • key_share اکنون یک کلید عمومی واقعی X25519 حمل می‌کند به‌جای ۳۲ بایت تصادفی. این یک نشانه واقعی بود: مختصه u یک کلید واقعی X25519 همیشه کمتر از 2^255-19 است، پس بیت پرارزش آن صفر است، در حالی که بایت‌های تصادفی در نیمی از موارد آن را یک می‌کنند.

این کار اثر انگشت را تغییر می‌دهد و یک آرتیفکت واقعی را حذف می‌کند، بنابراین ممکن است برای مدتی اتصال را برگرداند. اما این یک اثر انگشت ثابتِ جدید است، نه تصادفی‌سازی — دقیقاً همان الگوی اصلاح آوریل، که حدود شش هفته دوام آورد تا موج بعدی جایگزین را هدف بگیرد. آن را زمانِ خریداری‌شده در نظر بگیرید. ما هیچ داده میدانی درباره عبور آن از گره‌های فعلی TSPU نداریم؛ پلی‌بوک اپراتور در پایین همچنان توصیه اصلی است.

مشاهدات کلیدی:

  • موبایل در برابر خانگی نابرابر است، نه سیاست. همان پروکسی اغلب روی شبکه موبایل یک اپراتور کار می‌کند اما روی شبکه باسیم/خانگی همان اپراتور کار نمی‌کند (و برعکس، و iOS در برابر Android می‌تواند فرق کند). این استقرار نابرابر بازسازی روی گره‌های TSPU است — پروکسی یکسان است؛ جعبه DPI در مسیر فرق دارد — نه تصمیم اپراتور. Beeline، MTS، Megafon، Rostelecom به هر دو شکل گزارش شده‌اند.
  • VPN / تونل‌های Reality به‌طور کامل اثر انگشت MTProto را دور می‌زنند (به پلی‌بوک اپراتور در پایین مراجعه کنید).
  • ابزارهای تکه‌تکه‌سازی سمت کلاینت (zapret، GoodbyeDPI) هنوز روی مسیرهای بدون بازسازی کمک می‌کنند، اما اکنون که بخشی از گره‌ها بازسازی می‌کنند، به مسیر وابسته‌اند.
  • تلگرام در ۲۲ اوت ۲۰۲۶ اثر انگشت fake-TLS را به‌روزرسانی کرد (بالاتر را ببینید)، اما تصادفی‌سازی هنوز منتشر نشده است. tdesktop #30733 همان روز و بدون آن بسته شد؛ #30528 باز و ادغام‌نشده است، #30738 بدون ادغام بسته شد، و telemt/tdlib-obf هنوز هیچ انتشاری ندارد.

Teleproxy چه می‌کند (سمت سرور)

استتار Fake-TLS

تمام ترافیک در رکوردهای TLS 1.3 با ClientHello پروفایل Chrome بسته‌بندی می‌شود. برای راه‌اندازی Fake-TLS را ببینید.

بک‌اند TLS سفارشی (مقاومت در برابر کاوش فعال)

سیستم‌های DPI به طور فعال پروکسی‌های مشکوک را کاوش می‌کنند. هنگام اجرا با بک‌اند TLS واقعی (nginx با گواهی معتبر)، هر اتصال نامعتبر — رمز اشتباه، مهر زمانی منقضی، کاوش DPI — به وب‌سایت واقعی هدایت می‌شود. کاوشگر یک سرور HTTPS معتبر می‌بیند.

این مؤثرترین اقدام سمت سرور است. Fake-TLS: بک‌اند TLS سفارشی را ببینید.

تغییر اندازه رکورد پویا (DRS)

اندازه رکوردهای TLS از الگوی تدریجی مطابق با وب‌سرورهای واقعی (Cloudflare، Caddy) پیروی می‌کند: اندازه MTU در هنگام شروع آهسته، افزایش تا حداکثر. نویز تصادفی به هر رکورد اضافه می‌شود. این کار تحلیل آماری را که ترافیک پروکسی را از طریق اندازه‌های یکنواخت رکورد شناسایی می‌کند، خنثی می‌سازد.

تنوع پاسخ ServerHello

اندازه payload رمزگذاری‌شده ServerHello تا ±۳۲ بایت بین اتصالات تغییر می‌کند و تنوع طبیعی اندازه‌های زنجیره گواهی و تیکت نشست سرورهای TLS واقعی را تقلید می‌کند. ServerHello و ChangeCipherSpec به عنوان بخش‌های TCP جداگانه ارسال می‌شوند تا DPI نتواند پاسخ کامل دست‌تکانی را در یک بسته تطبیق دهد.

قطعه‌قطعه‌سازی اجباری ClientHello (خودکار)

Teleproxy یک TCP MSS کوچک (۲۵۶ بایت) را در SYN-ACK روی پورت گوش‌دهنده عمومی پروکسی اعلام می‌کند. هسته کلاینت از این محدودیت پیروی می‌کند و ClientHello خروجی (~۵۰۰-۷۰۰ بایت) را به ۲-۳ بخش TCP تقسیم می‌کند، طوری که داده‌های لازم برای JA4 (ALPN، signature_algorithms) در بخش‌های بعدی قرار می‌گیرند.

ارزیابی صادقانه (به‌روزشده در ژوئن ۲۰۲۶). این فقط DPIای را خنثی می‌کند که از یک بسته اثر انگشت می‌گیرد. موج فعلی TSPU جریان TCP را بازسازی می‌کند پیش از هش‌گیری، بنابراین روی آن گره‌ها این تکه‌تکه‌سازی هیچ اثری ندارد — آزمایش‌های میدانی با پایین‌آوردن MSS تا ۸۸ بایت، تأییدشده روی شبکه، باز هم مسدود شدند. این روش در برابر گره‌های بدون بازسازی (بخشی از مسیرهای موبایل) همچنان مفید است و با سگمنت‌بندی موجود ServerHello جفت می‌شود، پس به‌طور پیش‌فرض فعال می‌ماند. اما به‌تنهایی موج ژوئن را حل نمی‌کند — برای آنچه واقعاً اکنون کمک می‌کند به پلی‌بوک اپراتور در پایین مراجعه کنید.

به صورت خودکار کار می‌کند، نیازی به پیکربندی ندارد، و در برابر کلاینت‌های Telegram اصلاح‌نشده روی هر سکویی عمل می‌کند. شنونده HTTP /stats / /metrics از MSS پیش‌فرض سیستم استفاده می‌کند و تحت تأثیر قرار نمی‌گیرد.

تعادل: لینوکس MSS سوکت شنونده را به هر دو جهت هر اتصال پذیرفته‌شده اعمال می‌کند، بنابراین بخش‌های سرور→کلاینت نیز در ۲۵۶ بایت محدود می‌شوند. تعداد بسته‌ها حدود ۵ برابر افزایش می‌یابد و سربار سرآیند TCP/IP از ~۳٪ به ~۱۵٪ می‌رسد. روی سخت‌افزار مدرن با TSO/GSO، هزینه CPU قابل مدیریت است، اما پروکسی‌هایی که پهنای باند را اشباع می‌کنند کاهش قابل اندازه‌گیری توان عملیاتی را می‌بینند.

نحوه غیرفعال‌سازی. اپراتورهایی که ترجیح می‌دهند ریسک شناسایی JA4 را به جای سربار توان عملیاتی بپذیرند می‌توانند کلامپ را غیرفعال کنند:

  • TOML: mss_clamp = false (کلید سطح بالا)
  • CLI: --no-mss-clamp
  • Docker / start.sh: MSS_CLAMP=false (یا MSS_CLAMP=0)

هر یک از این روش‌ها MSS اعلام‌شده در SYN-ACK را به مقدار پیش‌فرض سیستم بازمی‌گرداند — هر اتصال پذیرفته‌شده در هر دو جهت یک MSS عادی دریافت می‌کند و پروکسی ترافیک حجیم MTProto را با سرعت کامل حمل می‌کند. به طور پیش‌فرض قطعه‌قطعه‌سازی فعال باقی می‌ماند — برای بیشتر کاربران، یک پروکسی کار‌کننده اما کمی کندتر بهتر از یک پروکسی سریع اما مسدودشده است.

تصادفی‌سازی GREASE

هر ClientHello (برای کاوش دامنه بالادست) از مقادیر GREASE تازه طبق RFC 8701 استفاده می‌کند و از تطبیق اثر انگشت ثابت جلوگیری می‌کند.

شما چه می‌توانید انجام دهید (راه‌اندازی سرور)

از پورت 443 استفاده کنید

ترافیک TLS روی پورت‌های غیراستاندارد (8443، 6443) مشکوک است. همیشه Teleproxy را روی پورت 443 اجرا کنید:

./teleproxy -H 443 -S <secret> -D example.com ...

یک دامنه پرترافیک انتخاب کنید

یک دامنه محبوب با پشتیبانی CDN برای SNI انتخاب کنید (مثلاً www.google.com، cloudflare.com). دامنه باید از TLS 1.3 پشتیبانی کند. Teleproxy دامنه را هنگام راه‌اندازی کاوش می‌کند تا ویژگی‌های ServerHello آن را بیاموزد و تقلید کند.

بک‌اند TLS سفارشی راه‌اندازی کنید

اگر دامنه سرور را کنترل می‌کنید، nginx با گواهی TLS معتبر را پشت Teleproxy راه‌اندازی کنید. این کار سرور را هنگام کاوش فعال از یک وب‌سایت HTTPS معمولی غیرقابل تشخیص می‌سازد. Fake-TLS: بک‌اند TLS سفارشی را ببینید.

از padding تصادفی استفاده کنید (حالت DD)

برای ISPهایی که MTProto را از طریق اندازه بسته‌ها شناسایی می‌کنند، padding تصادفی را با افزودن پیشوند dd به رمز کلاینت فعال کنید. نکته صادقانه: این در برابر اکتشافی‌های مبتنی بر اندازه بسته در برخی ISPها کمک می‌کند، اما هیچ اثری بر شناسایی JA4 که موتور موج ژوئن ۲۰۲۶ است ندارد — به‌تنهایی به آن تکیه نکنید.

پلی‌بوک اپراتور (فعلی)

موج فعلی به JA4 کلاینت به‌علاوه همبستگی (SNI + ip:port) تکیه می‌کند و TCP را بازسازی می‌کند. ترفندهای اثر انگشت سمت سرور نمی‌توانند JA4 کلاینت را تغییر دهند، پس آنچه در میدان دوام می‌آورد، اقداماتی است که همبستگی را رقیق می‌کنند و سمت خروجی را از MTProto دور می‌کنند. تقریباً به ترتیب اولویت:

۱. SNI را بین چند دامنه پوشش واقعی بچرخانید

همبستگی وقتی فعال می‌شود که اتصالات زیادی با SNI یکسان + JA4 تلگرام به یک ip:port برسند. چند دامنه پوشش ثبت کنید و به کاربران مختلف لینک‌هایی با SNIهای متفاوت بدهید:

./teleproxy -H 443 -S <secret> \
  -D www.cloudflare.com:127.0.0.1:8443 \
  -D www.microsoft.com:127.0.0.1:8443 \
  -D www.apple.com:127.0.0.1:8443

در هر دامنه SNI از بک‌اند جدا است (EE_DOMAIN/EE_BACKEND یا شکل -D sni:backend:port)، پس همه می‌توانند از یک بک‌اند TLS محلی استفاده کنند. گواهی‌های wildcard (-D '*.example.com:backend:443') نیز کار می‌کنند.

رکورد A دامنه پوشش باید به IP پروکسی resolve شود. یک SNI تصادفی که جای دیگری اشاره کند از بررسی رکورد A در ژوئن عبور نمی‌کند. از دامنه‌هایی استفاده کنید که در اختیار دارید (یا میزبان گواهی wildcard) و واقعاً به پروکسی اشاره می‌کنند.

۲. روی IPها و پورت‌ها پخش کنید و IPها را تمیز نگه دارید

چند IP/پورت گوش‌دهنده همبستگی بر پایه ip:port را بیشتر رقیق می‌کنند. توجه کنید که بن IP پس از شناسایی روی IPهای همسایه در همان محدوده نیز مشاهده شده — IPهای پروکسی را به‌جای خوشه‌ای‌کردن، در محدوده‌های مختلف پخش کنید و IP سوخته را بچرخانید.

۳. سمت خروجی را از طریق VLESS + Reality کاسکاد کنید (مطمئن‌ترین گزینه)

مطمئن‌ترین روش تأییدشده در میدان این است که اصلاً ترافیک شبیه‌MTProto را از شبکه سانسورشده خارج نکنید: teleproxy را در حالت مستقیم اجرا کنید و اتصالات خروجی آن به DC را از طریق یک کلاینت محلی Xray VLESS + Reality روی SOCKS5 عبور دهید:

# teleproxy روی ماشین داخل کشور، ترافیک به DC از طریق Xray Reality محلی خارج می‌شود
DIRECT_MODE=true
SOCKS5_PROXY=socks5://127.0.0.1:1080   # خروجی محلی Xray Reality

کلاینت تلگرام همچنان به‌صورت محلی با fake-TLS به teleproxy می‌رسد، اما آنچه از مرز TSPU عبور می‌کند Reality است که موج فعلی آن را مسدود نمی‌کند. به مصالحه‌های حالت مستقیم توجه کنید (مدیا روی اکانت‌های غیر-Premium، کانال‌های اسپانسرشده). این تنظیمات بیشتری دارد، اما همان چیزی است که وقتی fake-TLS معمولی از کار می‌افتد، کار می‌کند.

کاربران چه می‌توانند انجام دهند (سمت کلاینت)

عامل اصلی شناسایی، اثر انگشت TLS کلاینت تلگرام است که از سمت سرور قابل رفع نیست. کاربران در شبکه‌های تحت تأثیر باید از ابزارهای دور زدن DPI سمت کلاینت استفاده کنند که بخش‌های TCP را تکه‌تکه می‌کنند:

ابزار پلتفرم روش
zapret Linux، Android (root) تکه‌تکه‌سازی TCP، بسته‌های جعلی
zapret2 Linux، Android (root) فورک به‌روزشده
GoodbyeDPI Windows تکه‌تکه‌سازی TCP، ترفندهای TTL
NoDPI Android (بدون root) VPN محلی با تکه‌تکه‌سازی
SpoofDPI macOS، Linux پروکسی تقسیم HTTP/TLS

این ابزارها ClientHello را به چند بخش TCP تکه‌تکه می‌کنند. روی مسیرهای بدون بازسازی این هنوز کمک می‌کند، اما موج ژوئن روی بخشی از گره‌ها جریان را بازسازی می‌کند، پس نتیجه به مسیر وابسته است — امتحان کنید، اما دیگر یک راه‌حل تضمینی نیست.

آخرین کلاینت را اجرا کنید — Desktop 7.1 یا Android 12.10.0 و بالاتر

هر دو به‌روزرسانی اثر انگشتِ اوت ۲۰۲۶ را دارند که در بالا توضیح داده شد؛ این تغییر واقعی و ارزشمندی است. اما بدانید چه چیزی نیست: اصلاح پایدار آن است که کلاینت محتوای اثر انگشت TLS خود را بین اتصال‌ها تغییر دهد، و این منتشر نشده است. توجه کنید که جابه‌جایی ترتیب افزونه‌ها کمکی نمی‌کند — تلگرام از پیش این کار را به سبک کروم انجام می‌دهد، اما JA4 افزونه‌ها را پیش از هش‌کردن مرتب می‌کند، پس اثر انگشت قابل مشاهده برای هر بیلد کلاینت ثابت می‌ماند. tdesktop #30733 در ۲۲ اوت ۲۰۲۶ بدون تصادفی‌سازی بسته شد؛ از دو PR که آن را پیشنهاد داده بودند، #30528 هنوز باز است و #30738 بدون ادغام بسته شد. جدی‌ترین تلاش، telemt/tdlib-obf (ماسک‌کردن ClientHello بر اساس پروفایل‌های واقعی مرورگر از روی pcap)، هنوز انتشاری ندارد.

آنچه از سمت سرور قابل رفع نیست

  • اثر انگشت TLS کلاینت: اپلیکیشن تلگرام محتوای بایت‌به‌بایت ClientHello را کنترل می‌کند و TSPU بین کلاینت و پروکسی قرار دارد. کد سمت سرور نمی‌تواند آنچه کلاینت ارسال می‌کند را تغییر دهد. کلامپ MSS می‌تواند این بایت‌ها را روی بخش‌های TCP پخش کند، اما گره‌های DPI که جریان را بازسازی می‌کنند — همان‌طور که موج ژوئن ۲۰۲۶ می‌کند — باز هم JA4 درست را محاسبه می‌کنند. تنها اصلاح واقعی اثر انگشت سمت کلاینت است، و تا اینجا سمت کلاینت به‌جای تصادفی‌سازی فقط اثر انگشت را عوض کرده است (به بالا مراجعه کنید).
  • مسدودسازی IP/L3 و بن IP: وقتی DPI یک IP را در لایه شبکه مسدود می‌کند — از جمله بن‌های پس از شناسایی که به IPهای همسایه در همان محدوده سرریز می‌کنند — فقط VPN، کاسکاد Reality یا انتقال به IP تمیز کمک می‌کند.
  • تفاوت در استقرار TSPU: اینکه یک مسیر خاص ترافیک را شناسایی کند به نسخه سخت‌افزار/نرم‌افزار گره TSPU و به اینکه آیا TCP را بازسازی می‌کند بستگی دارد. این از اپراتوری به اپراتور دیگر، از منطقه‌ای به منطقه دیگر و حتی بین شبکه موبایل و باسیم یک اپراتور متفاوت است.