رفتار DNS اپراتور ایرانسل با دامنه‌های تحت تحریم

مشاهدات اخیر روی شبکه‌ی ایرانسل نشان می‌دهد که چندین دامنه‌ی مطرح و تحریم شده، بدون VPN قابل دسترسی هستند. این دامنه‌ها شامل موارد زیر می‌شوند:

• chatgpt.com
• openai.com
• gitlab.com
• okta.com
• epicgames.com

در شرایط عادی، این دامنه‌ها باید به آیپی‌های مربوط به Cloudflare CDN متصل شوند که این موضوع هنگام استفاده از DNSهای غیرپیش‌فرض هم صادق است. با این حال، هنگام استفاده از شبکه‌ی ایرانسل و DNSهای پیش‌فرض، این دامنه‌ها درگیر DNS spoofing می‌شوند. این تکنیک باعث می‌شود که آن‌ها به سرورها یا آیپی‌های نادرست که در شبکه هتزنر میزبانی می‌شوند، ریزالو شوند. علاوه بر این، برخی از دامنه‌های Spoof شده نه تنها به این آیپی‌های نادرست متصل می‌شوند، بلکه از طریق یک تانل، به شبکه‌ی WARP متصل می‌شوند که همین امر، آیپی هتزنر را از Cloudflare CDN بیشتر پنهان می‌کند.

هنگام استفاده از DNSهای غیرپیش‌فرض (مثلا ست کردن 8.8.8.8 بعنوان DNS)، آیپی مبدأ مشاهده شده توسط کلاودفلر متعلق به ایرانسل نیست، بلکه به Delta Telecom، یک شبکه مستقر در آذربایجان، تعلق دارد.

به نظر می‌رسد برای انجام این کار، ایرانسل از یک SNIProxy یا یک Transparent Proxy استفاده می‌کند. این امر به ترافیک HTTPS رهگیری شده (که توسط SNI در TLS handshake شناسایی می‌شود) اجازه می‌دهد تا به مقصد مورد نظر فوروارد شده یا بیشتر دستکاری شود، در حالی که اتصال از دید کاربر نهایی، یکپارچه و بدون مشکل باقی می‌ماند.

دامنه‌هایی که در اینجا مورد بحث قرار گرفتند، آنهایی هستند که تاکنون شناسایی شده‌اند، اما احتمالاً ایرانسل از همین راه برای دامنه‌های دیگری که پشت CDN کلاودفلر هستند، استفاده میکند.

بررسی روند

برای مثال، chatgpt را در نظر میگیریم:

هنگام دسترسی به https://www.chatgpt.com/cdn-cgi/trace با استفاده از اینترنت خانگی ایرانسل، رفتارهای زیر به طور مداوم مشاهده می‌شود:

• اگر DNS سفارشی (مثلا 8.8.8.8 یا هرچیز دیگری) تنظیم نشده باشد، سرور DNS همیشه یک آدرس هتزنر (هم v4 هم v6) برای chatgpt.com برمی‌گرداند و کلاودفلر هم همیشه یک آیپی v6 هتزنر را به عنوان آیپی کاربر می‌بیند. (حتی زمانی که دستگاه فقط برای IPv4 تنظیم شده باشد) این آیپی هتزنر، بطور تصادفی ممکن است در فنلاند یا آلمان باشد. همان‌طور که مشهود است، ریزالو دامنه بدون DNS سفارشی، منجر به بازگشت آدرس‌های آیپی متعلق به هتزنر می‌شود.

  هنگام اجرای دستور curl: در این حالت، کلاودفلر همواره و منحصراً یک IPv6 متعلق به هتزنر را مشاهده می‌کند.

• در صورت تنظیم هرگونه DNS سفارشی (مثلا 8.8.8.8 یا هرچیز دیگری)، پاسخ DNS یک آیپی استاندارد Cloudflare CDN خواهد بود و کلاودفلر مبدأ اتصال را یک IPv4 متعلق به Delta Telecom (آذربایجان) شناسایی می‌کند. همان‌طور که مشاهده می‌شود، ریزالو دامنه با یک DNS سفارشی، آیپی واقعی Cloudflare CDN را بازمی‌گرداند.

  هنگام اجرای دستور curl: در این سناریو، کلاودفلر به طور مداوم مبدأ اتصال را یک آدرس آیپی از آذربایجان (DeltaTelecom) مشاهده می‌کند.

جمع‌بندی (برای دامنه chatgpt.com):

با DNS پیش‌فرض ایرانسل:

• آیپی ریزالو شده: هتزنر IPv4
• آیپی مشاهده‌شده توسط کلاودفلر: هتزنر IPv6
• وضعیت وارپ: Off

با DNS کاستوم:

• آیپی ریزالو شده: CDN کلاودفلر
• آیپی مشاهده‌شده توسط کلاودفلر: دلتا تلکام
• وضعیت وارپ: Off

آزمایش‌های Traceroute به این آیپی‌های هتزنر تأیید می‌کنند که این آدرس‌ها به طور قانونی announce شده‌اند و hijack نشده‌اند.

دامنه‌هایی مانند cloudflare.com به آیپی‌های هتزنر حل نمی‌شدند، و هنگام تلاش برای برقراری اجباری اتصال به cloudflare.com از طریق این سرور هتزنر، اتصال قطع می‌شد، که نشان‌دهنده وجود یک سیستم whitelist روی SNI proxy است.

وضعیت برای سایر دامنه‌ها در جدول زیر قابل مشاهده است:

در انتها، نکته قابل توجه این است که هنگام ریزالو دامنه‌های www.epicgames.com و www.okta.com از طریق سرور DNS پیش‌فرض ایرانسل، یک آدرس آیپی متعلق به هتزنر بازگردانده می‌شود، اما هنگام دسترسی به https://epicgames.com/cdn-cgi/trace، وضعیت WARP به صورت on نمایش داده می‌شود. این موضوع نشان‌دهنده یک الگوی مسیریابی متفاوت در مقایسه با سایر دامنه‌هاست، جایی که به نظر می‌رسد ترافیک ابتدا به آیپی هتزنر متصل شده و سپس از به WARP هدایت می‌شود.

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

نتیجه‌گیری

اپراتور ایرانسل با پیاده‌سازی روش‌هایی مانند DNS spoofing و تغییر مسیر ترافیک در لایه زیرساخت، امکان دسترسی به دامنه‌های تحریم را به‌گونه‌ای فراهم کرده که رفتار شبکه برای کاربر نهایی شفاف نیست. این اقدامات شامل استفاده از ابزارهایی مانند تونل‌زنی WARP و whitelisting خاص است که باعث می‌شود برخی سرویس‌ها بدون نیاز به VPN در دسترس قرار گیرند. با این حال، مشخص نیست که این رویکردها حاصل یک سیاست هدفمند هستند یا ناشی از ملاحظات فنی و محدودیت‌های اجرایی. نبود شفافیت درباره منطق و زیرساخت این عملیات، پرسش‌های جدی درباره مسئولیت‌پذیری و اهداف پشت آن به وجود می‌آورد.