گزارش
۱۰ دقیقه مطالعه
مدیر

ایرانسل: تاثیر DNS روی دامنه‌های فیلتر شده از طریق SNI

بررسی‌های انجام شده روی شبکه ایرانسل نشان می‌دهد که استفاده از پروتکل‌های DNS جایگزین، فیلترینگ DNS را دور میزند. نکته مهم‌تر اینکه، مسدودسازی مبتنی بر SNI در برابر اتصالات مستقیم به آیپی‌هایی که از این طریق به دست آمده‌اند، کارایی ندارد.

مقدمه

مشاهدات اخیر روی شبکه اپراتور ایرانسل، الگوی قابل توجهی را آشکار کرده: در حالی که درخواست‌های استاندارد DNS (مبتنی بر UDP) برای دامنه‌های فیلتر شده طبق انتظار دستکاری می‌شوند، استفاده از پروتکل‌های جایگزین مانند DoH، DoT و DoTCP وضعیت پیچیده‌تری را ایجاد میکند.

تا پیش از این، تقریباً تمام سرورهای DoT، DoH، DoQ، DoTCP چه عمومی و چه شخصی، مسدود بودند. اما اکنون رویکرد فیلترینگ تغییر کرده است؛ مسدودسازی پروتکل‌های اصلی رمزنگاری‌شده (DoH, DoT, DoQ) روی سرورهای DNS عمومی و معروف (مثل کلاودفلر، گوگل، و ...) را در بر می‌گیرد، در حالی که پروتکل DoTCP روی همین سرورها فعال باقی مانده است. همزمان، سرورهای شخصی که آیپی‌های تمیز و فیلتر نشده دارند، بدون محدودیت به کار خود ادامه می‌دهند. این موضوع عملاً دو راه برای دریافت آیپی واقعی دامنه‌ها باز گذاشته است: استفاده از سرورهای شخصی، یا استفاده از DoTCP روی سرورهای عمومی و معروف.

نکته جالب‌تر اینکه این قضیه به لایه فیلترینگ SNI در هندشیک TLS نیز مربوط می‌شود. بررسی‌ها نشان می‌دهند که در حال حاضر سیستم DPI مبتنی بر فیلترینگ SNI تقریباً ناکارآمد است؛ چرا که اتصالات مستقیم HTTPS به آدرس‌های IP واقعی (که با روش‌های بالا پیدا شده‌اند)، حتی برای دامنه‌های کاملاً فیلتر شده، با موفقیت برقرار می‌شود. این یعنی سیستم DPI ایرانسل، یا این نوع ترافیک را شناسایی نمی‌کند، یا به کل آن را نادیده می‌گیرد.

پیش‌زمینه: لایه‌های معمول مداخله توسط ISP های ایرانی

به طور معمول، ISP ها از یک رویکرد چند لایه برای مدیریت و محدود کردن دسترسی به محتوای آنلاین استفاده می‌کنند:

  • فیلترینگ/دستکاری DNS: رهگیری و تغییر پاسخ‌های کوئری‌های DNS برای جلوگیری از ریزالو شدن آدرس‌های آیپی صحیح دامنه‌های هدف توسط کاربران. (برگشتن آیپی 10.10.34.X)
  • لیست سیاه آدرس آیپی (IP Blocking): نگهداری لیستی از آدرس‌های آیپی یا تمام رنج‌ها که در سطح شبکه مسدود شده‌اند.
  • فیلترینگ مبتنی بر SNI در لایه TLS: بازرسی SNI در هندشیک TLS برای شناسایی و مسدود کردن اتصالات به دامنه‌های فیلتر شده با پروتکل HTTPS.

مشاهدات انجام‌شده بر روی شبکه ایرانسل نشان می‌دهد که اگرچه فیلترینگ DNS همچنان پابرجاست، اما این محدودیت تنها بر پروتکل UDP اعمال می‌شود و DNS-over-TCP را شامل نمی‌شود. همچنین، فیلترینگ مبتنی بر SNI به طور کامل غیرفعال شده است. این موارد حاکی از آن است که احتمالاً در حال حاضر سانسور بر روی پروتکل TCP (و دیگه پروتکل‌ها روی سرور‌های شخصی) فعال نیست. برای کاربران نهایی ایرانسل، این بدان معناست که با دور زدن ساده فیلترینگ DNS، وب‌سایت‌هایی که به طور سنتی مسدود شده‌اند، بدون نیاز به VPN قابل دسترسی هستند.

مشاهدات دقیق روی شبکه ایرانسل

بخش اول: دور زدن فیلترینگ DNS با دیگر پروتکل‌های آن

رفتار زیر بطور پایدار در پروتکل‌های مختلف انتقال DNS مشاهده شده:

  • DNS پیش‌فرض (DoU):

    • هنگام استفاده از DNS های پیش‌فرض ایرانسل، کوئری‌ها برای دامنه‌هایی که در شبکه فیلتر شده‌اند، معمولاً به یک آدرس آیپی داخلی (10.10.34.X) ریزالو می‌شوند که عملاً دسترسی را در سطح DNS مسدود می‌کند. 1-mtn-default-dns-youtube
  • پروتکل‌های دیگر DNS:

    • در مقابل، هنگامی که کوئری‌های DNS برای همان دامنه‌های فیلتر شده با استفاده از DoTCP، DoT، DoH، DoQ (با هر پورتی) به DNS های عمومی و معتبر ارسال می‌شوند، پاسخ‌های DNS به طور مداوم آدرس‌های آیپی واقعی و درست این دامنه‌ها را ارائه می‌دهند.

    • این نشان می‌دهد که سیستم فیلترینگ DNS ایرانسل هنگامی که از این پروتکل‌های DNS جایگزین استفاده شود، به طور موثری دور زده می‌شود.

      2-mtn-custom-dns-youtube

بخش دوم: تست DPI روی دامنه‌ی SNI در هندشیک‌های TLS

برای تحلیل بیشتر رفتار هندشیک TLS و کارایی DPI روی دامنه‌ی SNI، از ابزار تست مخصوص‌مان به نام "heybabe" (جزئیات آن به زودی اعلام خواهد شد) استفاده کردیم. ابزار heybabe به ما امکان می‌دهد انواع مختلفی از هندشیک‌های TLS (شامل TLS 1.3 استاندارد Golang و TLS 1.3 با uTLS های مختلف مانند مرورگر Chrome) را با استفاده از یک دامنه شروع کنیم. برای تست مشخصی که در زیر نشان داده شده است، از دامنه www.youtube.com استفاده شده است.

بطور خلاصه، اگر که heybabe به ما success=true نشان دهد، یعنی آن هندشیک TLS موفقیت‌آمیز است، که بیانگر ناکارآمدی سیستم DPI در شناسایی دامنه‌ی SNI در آن تست می‌باشد. در مقابل success=false نشان‌دهنده مسدود شدن هندشیک TLS است.

  • حالت اول: استفاده از DNS پیشفرض ایرانسل:

    • هنگام شروع هندشیک TLS به www.youtube.com با اتکا به DNS پیش‌فرض ایرانسل، آدرس آیپی همانطور که انتظار می‌رود به آدرس‌های 10.10.34.X (هم IPv4 و هم IPv6) ریزالو می‌شود. هندشیک‌های TLS به این آیپی‌ها و با این SNI ناموفق هستند، که مسدودسازی در سطح DNS را تأیید می‌کند.

      • برای IPv4: 3_1-mtn-heybabe-default-dns-youtube-v4

      • برای IPv6: نتایج ناموفق مشابهی (success=false) مشاهده می‌شود. 3_2-mtn-heybabe-default-dns-youtube-v6

  • حالت دوم: با آیپی واقعی از پیش ریزالو شده (دور زدن DNS ایرانسل):

    • یک آدرس آیپی واقعی برای سرویس‌های مرتبط با دامنه یعنی www.youtube.com (به عنوان مثال، 142.250.186.46 برای IPv4 و 2a00:1450:4001:803::200e برای IPv6) ابتدا با استفاده از یک روش DNS جایگزین (بخش اول) به دست می‌آوریم.

    • سپس با heybabe به دامنه‌ی www.youtube.com با آیپی از پیش تعیین شده، یک هندشیک TLS برقرار میکنیم:

      • برای IPv4: هر دو تست TLS 1.3 استاندارد و uTLS Chrome نتیجه success=true را برمی‌گردانند. 4_1-mtn-heybabe-with-ip-youtube-v4

      • برای IPv6: نتایج موفقیت‌آمیز مشابهی (success=true) مشاهده می‌شود. 4_2-mtn-heybabe-with-ip-youtube-v6

آزمایش‌های بیشتر با "heybabe" با استفاده از این روش دو مرحله‌ای (استفاده از DNS جایگزین و هندشیک TLS با آیپی مستقیم) نشان می‌دهد که این الگوی هندشیک‌های TLS موفقیت‌آمیز، محدود به مورد آزمایشی www.youtube.com نیست. نتایج مثبت مشابهی (دور زدن هم دستکاری DNS و هم مسدودسازی مبتنی بر SNI) برای اکثر دامنه‌های رایج مسدود شده دیگر (مانند instagram.com و ...) در شبکه ایرانسل که معمولاً تحت چنین محدودیت‌هایی قرار دارند، مشاهده شد.

بحث و توضیحات احتمالی

موفقیت پیوسته در دور زدن فیلترینگ DNS با پروتکل‌های جایگزین از یک سو، و مهم‌تر از آن، ناکارآمدی گسترده سیستم DPI در تشخیص SNI (در پروتکل TLS) هنگام اتصال مستقیم با آیپی به اغلب دامنه‌های مسدود شده‌ی آزمایش‌شده از سوی دیگر، نشان‌دهنده چندین ویژگی بالقوه در معماری فیلترینگ فعلی ایرانسل است:

  • تمرکز فیلترینگ DNS عمدتاً بر روی DNS-over-UDP: به نظر می‌رسد سیستم دستکاری DNS ایرانسل به شدت بر روی DNS-over-UDP استاندارد متمرکز است و سایر پروتکل‌های انتقال (DoTCP, DoH, DoT, DoQ) را تا حد زیادی رها کرده است.

  • ناکارآمدی سیستمی یا تعمدی DPI در شناسایی SNI برای اتصالات مستقیم با آیپی: موفقیت گسترده در برقراری اتصالات TLS به آیپی‌های واقعی (پس از ریزالو شدن) برای اکثر دامنه‌هایی که معمولاً از طریق SNI مسدود می‌شوند، یافته کلیدی است. این نشان می‌دهد:

    • دامنه‌ی بررسی محدود: این احتمال وجود دارد که سیستم DPI تنها برای بازرسی ترافیکی پیکربندی شده باشد که مقصد آن، آیپی‌های معرفی‌شده توسط DNS دستکاری‌شده‌ی خود اپراتور است. در نتیجه، ترافیکی که مستقیماً به آیپی واقعی یک دامنه (به‌دست‌آمده از یک DNS سالم) ارسال می‌شود، از این لایه بازرسی عبور کرده و فیلتر نمی‌گردد.
    • محدودیت‌های فنی: زیرساخت DPI می‌تواند محدودیت‌های ذاتی داشته باشد، مانند کمبود برق در ایران.
  • لیست سیاه آیپی‌ها، به طور جامع اعمال نمی‌شوند یا بصورت موردی به راحتی دور زده می‌شوند: این موفقیت نشان می‌دهد که آیپی‌های واقعی بسیاری از این سرویس‌های مسدود شده در یک IP blocklist جامع که این شکاف DPI را پوشش دهد، قرار ندارند (یا نمی‌توانند همگی در چنین لیستی باشند).

این الگو نشان می‌دهد که اگرچه ایرانسل یک لایه فیلترینگ DNS فعال دارد، اما لایه اعمال محدودیت SNI/TLS آن تقریباً به طور کامل غیرفعال شده است.

نتیجه‌گیری

رفتار مشاهده شده در شبکه ایرانسل ظهور یک الگوی دوگانه مشخص را نشان می‌دهد: پروتکل‌های جایگزین DNS مانند DoTCP, DoT, DoH, DoQ، به طور مداوم فیلترینگ سطح DNS آن را دور می‌زنند و امکان resolve شدن آدرس‌های آیپی واقعی برای دامنه‌های فیلتر شده را فراهم می‌کنند. نکته بسیار مهم این است که اتصالات مستقیم HTTPS/TLS به این آیپی‌ها برای اکثر دامنه‌هایی که معمولاً از طریق SNI/DNS مسدود می‌شوند (به عنوان مثال، سرویس‌های مرتبط با www.youtube.com, instagram.com, و غیره) نیز با موفقیت انجام می‌شوند. این امر نشان‌دهنده ناکارآمدی گسترده فعلی یا عدم اعمال خاص مکانیزم‌های مسدودسازی مبتنی بر SNI یا مشابه در لایه TLS توسط ایرانسل برای این مسیرهای ارتباطی خاص است.

وجود یک شکاف مشهود و قابل‌توجه در سیستم فیلترینگ ایرانسل، عملاً موانع دسترسی به طیف وسیعی از محتوای محدود شده را برای کاربران آن کاهش داده است. دلیل اصلی این پدیده هنوز مشخص نیست، اما می‌تواند ناشی از تصمیمات فنی در معماری شبکه، نقصی در فرآیند پیاده‌سازی سیاست‌ها، و یا حتی یکی از ویژگی‌های ذاتی ساختار فعلی آن باشد. از این رو، به منظور درک دقیق میزان پایداری این وضعیت و دلایل بنیادین آن، پایش مستمر شبکه و انجام تحقیقات تکمیلی، امری ضروری تلقی می‌گردد.