روایت فنی وضعیت اینترنت ایران در دوران جنگ

مقدمه:

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

در این مقاله، روایتی فنی و تحلیلی از روز اول تا پایان بحران ارائه می‌دهیم: چرا برخی سرویس‌ها در دسترس و برخی سرویس ها قابل دسترسی نبودند. فیلترینگ داخلی، چه نقشی در اختلالات شبکه جهانی و عدم آمادگی زیرساخت ایفا کردند؟ و در نهایت، چه درس‌هایی می‌توان از این تجربه برای آینده اینترنت ایران و کاربران آن گرفت؟

روزهای ابتدایی جنگ و واکنش فوری شبکه ملی

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

 اعمال فیلترینگ اضطراری و محدودسازی سطح دسترسی

در اولین واکنش، سیاست فیلترینگ به‌صورت شدیدتر از حالت عادی اعمال شد. بسیاری از دامنه‌ها و IPهایی که پیش‌تر در لیست‌های کنترلی نبودند، به‌سرعت در سطح Core شبکه مسدود شدند. پورت‌های حیاتی نظیر 443 (HTTPS) در بسیاری از مسیرها با DPI (تحلیل عمیق بسته‌ها) مورد نظارت فعال قرار گرفت و حتی ارتباط برخی سرویس‌های رمزنگاری‌شده به‌طور کامل دچار اختلال شد.

برخی از اپراتورها (همراه اول، ایرانسل، آسیاتک و…) به‌صورت منطقه‌ای یا ساعتی، دسترسی به اپلیکیشن‌هایی مانند واتساپ، تلگرام، جیمیل و حتی برخی سرویس‌های CDN را مسدود کردند؛ به‌گونه‌ای که کاربران در برخی استان‌ها صرفاً به شبکه داخلی دسترسی داشتند.

تغییرات در مسیرهای BGP و مسدودسازی IPهای بین‌المللی

یکی از اقدامات فنی که در سطح زیرساخت رخ داد، تغییر مسیرهای BGP (پروتکل مرزی اینترنت) بود. برخی از Prefixهای بین‌المللی از جدول‌های مسیریابی حذف شدند یا در معرض Route Leak قرار گرفتند. همچنین، بلوک‌های IP خاصی که معمولاً به سرویس‌های خارجی مرتبط بودند (مانند Cloudflare، Google، Amazon) به‌طور مستقیم در سطح فایروال‌های ملی مسدود شدند. این اقدام منجر به عدم دسترسی به بسیاری از منابع بین‌المللی حتی با VPN یا DNS اختصاصی شد.

افت شدید پهنای باند بین‌الملل

نمودارهای منتشرشده توسط منابع نظارتی خارجی مانند Radar.Cloudflare و NIXI (در صورت دسترسی) نشان دادند که در همان ساعات اولیه جنگ، پهنای باند ورودی و خروجی ایران با افتی بین ۴۰ تا ۸۰ درصد مواجه شد. این افت نه تنها به دلیل افزایش ناگهانی مصرف داخلی و اختلالات فنی بود، بلکه بخشی از آن مستقیماً به محدودسازی پهنای باند بین‌الملل توسط IXPهای داخلی بازمی‌گردد.

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

قطع دسترسی به سرویس‌های خارجی

یکی از ملموس‌ترین نمودهای اختلال در وضعیت اینترنت ایران طی روزهای جنگ، عدم دسترسی گسترده کاربران به سرویس‌های بین‌المللی بود. دسترسی به خدمات حیاتی مانند Google، Amazon Web Services (AWS)، Cloudflare، OVH، GitHub و بسیاری دیگر یا به‌طور کامل مسدود شده بود یا با تأخیر و قطعی شدید همراه بود. این اتفاق، نه‌فقط برای کاربران عادی بلکه برای توسعه‌دهندگان، مدیران سرور و صاحبان کسب‌وکارها نیز اثرات قابل‌توجهی داشت.

چرا گوگل، AWS، Cloudflare و OVH از ایران در دسترس نبودند؟

در این دوره، چند عامل به شکل هم‌زمان باعث اختلال یا عدم دسترسی کامل به سرویس‌های خارجی شدند:

1. مسدودسازی هدفمند در سطح ملی:
   بسیاری از IPهای مربوط به سرویس‌دهندگان بین‌المللی در سطح Core شبکه ایران توسط فایروال‌های ملی یا ISPهای بزرگ بلاک شدند. این اقدام معمولاً از طریق ACL (Access Control List) و Blackhole Routing انجام می‌شود تا دسترسی کاربران به زیرساخت خارجی متوقف شود.

2. خروج داوطلبانه یا محافظه‌کارانه ارائه‌دهندگان سرویس:
   برخی سرویس‌ها مانند Google و Amazon در مواجهه با وضعیت بحرانی، بنا به ملاحظات امنیتی و حقوقی (از جمله تحریم‌های بین‌المللی و نگرانی از حملات سایبری)، به‌طور موقت مسیرهای دسترسی از ایران را محدود کردند یا پاسخ به درخواست‌ها را مسدود نمودند.

3. افزایش Latency و ازکارافتادن مسیرهای خارجی:
   در مواردی حتی اگر مسیر به‌صورت فنی باز بود، افت شدید کیفیت شبکه و قطعی در Peerهای بین‌المللی باعث قطع ارتباط TCP در مرحله TLS Handshake یا ارسال بسته‌های اولیه می‌شد.

   بررسی رفتار CDNها و DNSهای عمومی

   در میان اختلالات ایجادشده، CDNها و DNSهای عمومی نیز رفتاری متفاوت نشان دادند:

   • Cloudflare: در بسیاری از نقاط کشور دامنه‌هایی که تحت خدمات Cloudflare بودند، به دلیل قطع دسترسی به سرورهای مرزی (Edge Server) این شرکت، از دسترس خارج شدند. حتی در مواردی که دامنه به IP داخلی resolve می‌شد، سرویس به‌درستی بارگذاری نمی‌شد.

   • Google Public DNS (8.8.8.8 / 8.8.4.4): این سرورها یا بدون پاسخ بودند یا با تأخیر بالا پاسخ می‌دادند. بسیاری از ISPها ترافیک این DNSها را به‌صورت محلی مسدود کرده بودند.

   • Quad9 و OpenDNS: در مقاطعی دسترسی داشتند ولی به دلیل وابستگی به زیرساخت BGP پایدار، دسترسی آن‌ها هم ناپایدار بود.

   • CDNهای وابسته به AWS یا Akamai: بسیاری از فایل‌های JS، فونت‌ها، یا APIهایی که به این CDNها وابسته بودند، به‌صورت Silent Fail عمل کردند؛ یعنی بدون پیام خطا، فقط اجرا نشدند.

نقش تحریم‌ها، geoblocking و مسیریابی داخلی (Routing)

علاوه بر عوامل داخلی، عوامل خارجی نیز در عدم دسترسی به سرویس‌های جهانی نقش مؤثری داشتند:

• تحریم‌های بین‌المللی: بسیاری از شرکت‌های فناوری به‌صورت پیش‌فرض دسترسی به آی‌پی‌های ایرانی را در لایه اپلیکیشن محدود می‌کنند. در شرایط بحرانی، این محدودیت‌ها تشدید شد یا به‌صورت کامل اجرا شد.

• Geoblocking بر اساس MaxMind / GeoIP: حتی در مواردی که IP کاربر از طریق VPN تغییر کرده بود، به دلیل شناسایی Geolocation از روی رفتار مرورگر یا DNS، دسترسی محدود باقی می‌ماند.

• مسیریابی داخلی (Routing Manipulation): بعضی از اپراتورها اقدام به اعمال تغییر در مسیرهای خروجی ترافیک کردند تا دسترسی کاربران به برخی سرورها به‌طور غیرمستقیم قطع شود. این تغییرات معمولاً با تاخیر زیاد یا Time-out در مرحله DNS resolve همراه بود.

پایداری نسبی سرویس‌های داخلی

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

چرا برخی سایت‌های داخلی در ابتدا در دسترس بودند؟

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

1. میزبانی کامل در دیتاسنترهای داخلی:
   این سامانه‌ها در دیتاسنترهایی مانند آسیاتک، شاتل، تبیان، پارس‌آنلاین یا مراکز داده دولتی قرار دارند که از شبکه ملی اطلاعات تغذیه می‌شوند و به ارتباط خارجی برای عملکرد نیاز ندارند.

2. وابستگی پایین به منابع خارجی:
   برخلاف بسیاری از وب‌سایت‌های خصوصی، این سامانه‌ها از فونت‌ها، کتابخانه‌های JS، CAPTCHA یا APIهای بین‌المللی استفاده نمی‌کنند و به‌همین دلیل در زمان قطع اینترنت جهانی، همچنان قادر به پاسخ‌گویی بودند.

   • کاربران ایرانسل و همراه اول دسترسی به بسیاری از سایت‌های داخلی داشتند حتی زمانی که اینترنت بین‌الملل کاملاً قطع بود. این ناشی از پیاده‌سازی بهتر شبکه ملی در هسته شبکه این دو اپراتور بود.

   • در شاتل و آسیاتک قطع و وصل‌های مکرر، مشکل در رزولوشن DNS، و عدم پایداری در زمان بارگذاری سایت‌ها گزارش شد. کاربران این شرکت‌ها بیشتر از سایرین با اختلال در سرویس‌های نیمه‌داخلی (مثلاً سایت‌هایی با CDN خارجی اما دامنه ملی) مواجه بودند.ظ

     دسترسی از طریق شبکه ملی اطلاعات:
     برخی از این سرویس‌ها با آدرس‌های internal (نظیر irancell.cdn یا mci.net) از طریق مسیریابی داخلی قابل‌دسترسی بودند حتی اگر DNS خارجی قطع شده بود.

     تفاوت تجربه کاربران در ISPهای مختلف

     نکته قابل توجه در وضعیت اینترنت ایران در این دوران، تفاوت جدی تجربه کاربران در میان اپراتورهای مختلف بود. در عمل مشاهده شد که:ISPهای استانی یا کوچک‌تر معمولاً تجربه ضعیف‌تری داشتند. به‌دلیل نداشتن caching داخلی یا reliance بالا به transit بین‌الملل، دسترسی حتی به سامانه‌های داخلی نیز با مشکل مواجه شد.

آیا شبکه ملی اطلاعات کار کرد؟ بررسی نقاط قوت و ضعف

بر اساس آنچه در این دوره بحرانی مشاهده شد، می‌توان به این ارزیابی رسید:

 نقاط قوت:

• امکان دسترسی بدون اینترنت بین‌الملل به سامانه‌های کلیدی

• پایداری نسبی خدمات بانکی و احراز هویت در زیرساخت‌های دولتی

• Routing داخلی مؤثر برای برخی دامنه‌ها در ISPهای بزرگ

 نقاط ضعف:

• عدم یکپارچگی تجربه کاربران در ISPهای مختلف

• عدم آمادگی کسب‌وکارهای خصوصی برای عملکرد صرفاً در شبکه ملی

• نبود ابزار عمومی برای تشخیص اینکه آیا یک سرویس در شبکه ملی فعال است یا خیر

• فقدان راهکارهای caching استاندارد برای فایل‌های استاتیک وب‌سایت‌ها

اختلالات غیرمنتظره: چرا بعضی سرویس‌های داخلی هم از دسترس خارج شدند؟

با وجود آنکه بخشی از زیرساخت دیجیتال کشور در روزهای نخست جنگ عملکرد نسبتاً پایداری از خود نشان داد، اما بخش دیگری از سرویس‌های داخلی، حتی با میزبانی در دیتاسنترهای ایران، به‌طور غیرمنتظره‌ای دچار اختلال کامل یا نسبی شدند. این رخداد، کاربران و حتی مدیران فنی را با این پرسش مواجه کرد که چرا در نبود اینترنت بین‌الملل، برخی سرویس‌های بومی نیز از دسترس خارج شدند؟

تحلیل تکنیکی: افت فشار سرورها، ازدحام DNS، اختلال در CDN ملی

سه عامل فنی اصلی در بروز این اختلالات نقش پررنگی داشتند:

1. افت فشار شدید روی سرورهای داخلی:
   به‌محض قطع ارتباط کاربران با سرویس‌های خارجی، بار درخواست‌ها به‌صورت ناگهانی بر روی سرورهای داخلی افزایش یافت. بسیاری از سرورها به دلیل تنظیمات ناکافی برای Scale یا نداشتن Load Balancer، قادر به پاسخگویی به این حجم نبودند. این افت فشار، در برخی موارد منجر به بالا رفتن Load CPU، پر شدن I/O دیسک، یا حتی کرش شدن سرویس‌های PHP و DB شد.

2. ازدحام در DNS داخلی:
   در شرایط بحران، میلیون‌ها کاربر ناچار به استفاده از DNSهای داخلی شدند که غالباً به لحاظ زیرساخت برای این حجم از ترافیک آماده نبودند. برخی ISPها نیز، بدون راه‌اندازی Cache Resolverهای جداگانه، ترافیک DNS کل شبکه را به یک سرور مرکزی هدایت کردند که این اقدام باعث Time-out گسترده در درخواست‌های دامنه‌های حتی داخلی شد.

3. اختلال در عملکرد CDN ملی و Cacheهای داخلی:
   CDNهایی که به‌صورت محلی برای بارگذاری محتوای ثابت (تصاویر، فایل‌های JS، CSS) استفاده می‌شدند، در برخی نقاط دچار اختلال شدند؛ علت آن می‌تواند عدم همگام‌سازی مناسب، نبود سرورهای Region-Based یا حتی نداشتن حافظه کش پایدار باشد. این موضوع به‌ویژه در وب‌سایت‌هایی که به‌صورت SPA (Single Page Application) طراحی شده بودند، باعث Load ناقص صفحات شد.

   وابستگی پنهان سرویس‌های بومی به منابع خارجی

   یکی از واقعیت‌های نادیده‌گرفته‌شده در بسیاری از سرویس‌های داخلی، وابستگی غیرمستقیم آن‌ها به منابع خارجی است. بسیاری از وب‌سایت‌های ایرانی، حتی با میزبانی داخلی، برای عملکرد درست به اجزایی مانند موارد زیر متکی بودند:

   • Google Fonts برای نمایش فونت در رابط کاربری

   • jQuery یا Bootstrap از CDNهای بین‌المللی (jsdelivr, unpkg)

   • Google reCAPTCHA یا hCaptcha برای امنیت فرم‌ها

   • سرویس‌های تحلیل رفتار کاربر مانند Google Analytics یا Meta Pixel

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

   نبود Redundancy واقعی در شبکه ایران

   یکی از اشکالات ساختاری که در این بحران خود را نشان داد، نبود Redundancy واقعی در شبکه ملی بود. برخلاف شبکه‌های زیرساختی پیشرفته که در معماری خود از مسیریابی جایگزین (Failover Routing)، پخش جغرافیایی بار (Geo Load Balancing) و زیرساخت‌های مستقل برای DNS و CDN بهره می‌برند، بیشتر شبکه‌های داخلی ایران به‌صورت متمرکز و وابسته به چند نقطه خاص طراحی شده‌اند.

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

بیشتر بخوانید: امنیت سایت در شرایط بحرانی

درس‌هایی از این بحران برای کسب‌وکارهای دیجیتال

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

یاز به هاست‌های Redundant (داخل و خارج کشور)

یکی از بزرگ‌ترین آسیب‌های این دوران، برای کسب‌وکارهایی رخ داد که تمام خدمات خود را صرفاً بر روی هاست داخل یا هاست خارج بنا کرده بودند. در هر دو حالت، به‌محض اختلال در یکی از مسیرها، کل سرویس از دسترس خارج شد.

راه‌حل چیست؟
پیاده‌سازی معماری Redundant Hosting که در آن، نسخه‌ای از وب‌سایت یا اپلیکیشن روی سرور داخل ایران و نسخه‌ای دیگر روی سرور خارج از کشور قرار دارد. این مدل می‌تواند با تنظیمات هوشمند DNS یا سرویس‌هایی مانند GeoDNS / Failover DNS هدایت شود تا کاربر بر اساس موقعیت مکانی یا وضعیت شبکه به نزدیک‌ترین نقطه متصل شود.

نقش CDN هیبریدی (ایرانی و بین‌المللی)

بسیاری از سایت‌ها در بحران اخیر به این دلیل از کار افتادند که محتوای استاتیک آن‌ها روی CDNهای خارجی مثل Cloudflare، jsDelivr یا AWS S3 میزبانی شده بود. در طرف مقابل، برخی سایت‌های داخلی هم به‌دلیل نبود CDN داخلی واقعی یا وابستگی به یک POP دچار اختلال شدند.

پیشنهاد:
استفاده از CDN هیبریدی که محتوا را هم در داخل ایران و هم در نقاط بین‌المللی توزیع کند. پلتفرم‌هایی مانند ArvanCloud در داخل کشور و Cloudflare در خارج می‌توانند در کنار هم، با طراحی مناسب، شبکه‌ای متعادل بسازند. حتی برخی شرکت‌های بزرگ داخلی شروع به استفاده موازی از هر دو کرده‌اند و روی cdn.example.com، بسته به IP کاربر، مسیر مناسب را ارائه می‌دهند.

داشتن Backup DNS، سرور DR، و برنامه بازیابی

DNSها به‌عنوان دروازه ورود کاربران به سرویس، یکی از نقاط آسیب‌پذیر کلیدی هستند. در زمان بحران، بسیاری از دامنه‌ها به‌دلیل ازکارافتادن DNSهای اولیه یا قطع ارتباط با روت‌های خارجی، به‌کلی از دسترس خارج شدند. همچنین نبود سرور پشتیبان (Disaster Recovery / DR) برای بسیاری از کسب‌وکارها، به معنای توقف کامل فعالیت و ضرر مالی شدید بود.

راه‌کارهای پیشنهادی:

• • استفاده از Secondary DNS Providers با زیرساخت متفاوت (مثلاً ترکیب Route53 و ParsaDNS)

  • پیاده‌سازی سرور DR در لوکیشن متفاوت جغرافیایی با دیتابیس همگام‌سازی‌شده (Replication)

  • داشتن Business Continuity Plan (BCP) و سناریوی مشخص برای قطعی اینترنت بین‌الملل یا داخلی

جمع‌بندی نهایی

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

با تحلیل دقیق آنچه رخ داد، به سه واقعیت غیرقابل‌انکار می‌رسیم:

1. هیچ زیرساخت دیجیتالی، چه دولتی و چه خصوصی، نباید صرفاً به یک مسیر یا یک موقعیت جغرافیایی وابسته باشد.

2. دسترسی پایدار به اینترنت (داخلی و خارجی) بدون معماری مهندسی‌شده، اتکاپذیر نخواهد بود.

3. کسب‌وکارهایی که در طراحی زیرساخت خود Redundancy، CDN هیبریدی، DNS پشتیبان و سرور DR را لحاظ نکرده‌اند، در بحران‌ها آسیب‌پذیرتر از آنی هستند که تصور می‌کنند.

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

اکنون زمان آن است که با نگاهی عمیق‌تر، برای بحران بعدی – چه سایبری، چه طبیعی، چه ژئوپلیتیکی – آماده باشیم. زیرساختی پایدار نه تنها سرمایه‌گذاری برای تداوم کسب‌وکار است، بلکه بخشی از امنیت ملی و اجتماعی ما به‌حساب می‌آید.