AS60077 يظهر Cloud.ir على الإنترنت دون المسار المادي

ملخص

في 20 يوليو 2026، وصف RIPE RDAP وRIPEstat نظام AS60077 بأنه نظام مستقل نشط ومُعلن، أصله 18 بادئة IPv4 تمثل 14080 عنوانًا، مع رؤية لدى 324 من أصل 325 من أقران RIS IPv4 المُراقبين.
لم يُظهر الملف العام أي بادئة IPv6 منشؤها حاليًا AS60077، ولم يكشف سوى عن AS43754 كجار مُراقب، ولم يُظهر في PeeringDB أي نقطة تبادل أو موقع مُعلن. لكن هذه الملاحظات لا تثبت غياب IPv6 أو المواقع أو المسارات الخاصة الأخرى.
تثبت صفحات Cloud.ir النشطة وجود عرض تجاري موسع، ويوضح SLA بعض حدوده. لكنها لا تربط كل خدمة بـ AS60077 ولا تُظهر المسار المادي أو السعة القابلة للاستخدام أو التنوع المستقل للوصول أو سلوك التعافي.
لذا فإن السؤال المفيد ليس ما إذا كان لدى Asre Dadeha Asiatech حضور شبكي عام: فهذا الحضور موثق جيدًا. بل هو تحديد إلى أي مدى تسمح هذه الرؤية بتقييم التسليم الفعلي لخدمة سحابية، وأين تبدأ المناطق التي لا تسمح المصادر العشرون بالتحقق منها.

دليل شبكي لا ينبغي أن يصبح دليلاً شاملاً

توفر بصمة AS60077 نقطة انطلاق دقيقة بشكل استثنائي مقارنة بالعديد من عروض السحابة التي يصعب إرجاع شبكتها. يترك النظام المستقل المُعلن آثارًا يمكن لعدة سجلات ومراصد مقارنتها: اسم، مؤسسة مُصرِّحة، بادئات، أصل BGP، جيران مُراقَبون، وبعض الطرق، ترخيص RPKI. تسمح هذه العناصر باختبار جزء من السرد العام دون الاعتماد فقط على المفردات التجارية لـ Cloud.ir.

لكن لهذه الدقة حدًا. يوضح BGP كيف يتم الإعلان عن الوجهات لبقية الإنترنت؛ لكنه لا يصف تلقائيًا المباني أو الخوادم أو أنظمة التخزين أو العقود التي تقف خلفها. يمكن أن يكون المسار مستقرًا وواسع الرؤية بينما يستخدم منتج معين بنية أخرى. وعلى العكس، قد تكون وظيفة خدمة متاحة دون أن تكون قابلة للتحديد المباشر كبادئة منشؤها AS60077. لا توفر المصادر جدولًا يربط كل منتج وكل عنوان وكل موقع.

لذلك يجب قراءة الملف في عدة طبقات. الأولى تتعلق بالهوية الإدارية للشبكة. الثانية تتعلق بسلوكها العام المرصود وقت الجمع. الثالثة تتعلق بالسطح التجاري لـ Cloud.ir. الرابعة، التي يصعب توثيقها، ستكون التسليم المادي والتعافي: الموقع الدقيق، المسارات المستقلة، السعة المتاحة، التبديل والاستعادة. تحتوي الطبقات الثلاث الأولى على أدلة ملموسة. تبقى الرابعة مكونة بشكل أساسي من تصريحات المشغل وأسئلة مفتوحة.

هذا الفصل لا يضعف النتائج الإيجابية. بل يمنحها نطاقًا دقيقًا. القول بأن AS60077 نشط ومُعلن ومرئي للغاية في عينة RIS هو استنتاج متين. القول بأن هذه الرؤية تثبت وحدها مرونة جميع خدمات Cloud.ir سيكون توسعًا لا يسمح به الملف. يتمثل تحدى التحليل في الحفاظ على قوة الملاحظة الأولى دون الانزلاق نحو الثانية.

الهوية الإدارية لـ AS60077 واضحة وحالية

يسجل RIPE RDAP AS60077 باسمAT-CLOUD، بحالة نشطة. المؤسسة المُصرِّحة هيORG-ADA42-RIPE/ Asre Dadeha Asiatech. يعود تسجيل الرقم المستقل إلى 27 يونيو 2022 وآخر تعديل مشار إليه بتاريخ 23 يناير 2026. هذه التواريخ لا تثبت نشاطًا تجاريًا يوميًا، لكنها تُظهر أن كائن السجل ليس مجهولاً أو ثابتًا منذ عصر بعيد.

يكمل ملخص RIPEstat هذه الهوية. في وقت الاستعلام في 20 يوليو 2026 الساعة 8 UTC، كان يربط AS60077 بالمالكAT-CLOUD Asre Dadeha Asiatechويعيدannounced=true. وبالتالي، كان السجل ورصد التوجيه يرويان قصة متوافقة: الرقم مخصص للكيان قيد الدراسة ويتم الإعلان عنه علنًا في الوقت المعني.

هذا التوافق مهم لأن المصادر المختلفة لا تؤدي نفس الوظيفة. يصف RIPE RDAP سجلاً إداريًا. يجمع RIPEstat الملاحظات وبيانات التوجيه. يقدم bgp.tools ملخصًا عامًا إضافيًا. عندما تتقارب هذه المصادر على الاسم والحالة وعدد بادئات IPv4، يزداد الثقة في تحديد السيطرة على الشبكة. لم يعد الأمر يتعلق باستدلال المشغل من شعار أو صفحة بيع.

غير أن التقارب لا يحول المؤسسة المُصرِّحة إلى مالك مثبت لكل مورد مادي يخدم المنتج. يحدد الرقم المستقل نطاق سياسة التوجيه. لا يشكل مخزونًا للأصول أو مخططًا تنظيميًا كاملاً للعمليات. يسمح الملف بإسناد AS60077 إلى Asre Dadeha Asiatech؛ لكنه لا يسمح باستنتاج ملكية المباني أو الألياف أو المولدات أو المعدات أو كل السعة المذكورة على صفحات الخدمة.

الاسمAT-CLOUDيعزز بشكل طبيعي التقارب مع عرض Cloud.ir، لكن الاسم لا يحل محل رسم الخرائط التقنية. العلاقة الوثائقية معقولة ومتسقة: تحدد السجلات Asre Dadeha Asiatech، بينما تقدم الصفحات الرسمية Cloud.ir كعرض خدمات يعتمد على مراكز بيانات Asiatech. هذا التقارب يؤسس لسياق مشترك. لا يزال لا يوفر المسار من طرف إلى طرف لخادم أو VPS أو كائن مخزّن أو حركة CDN.

ثمانية عشر إعلانًا IPv4 تشكل بصمة جوهرية

أحصى حالة توجيه RIPEstat 18 بادئة IPv4 مصدرها AS60077 و14080 عنوان IPv4. تتيح قائمة الإعلانات رؤية كيفية تكوين هذا المجموع. تشمل78.110.112.0/21، ثم85.198.8.0/22،85.198.12.0/22،85.198.16.0/23،85.198.19.0/24،85.198.20.0/23و85.198.22.0/23.

في النطاق193.151، تشمل الإعلانات الكتل193.151.128.0/22،193.151.132.0/22،193.151.136.0/22،193.151.140.0/22،193.151.144.0/22،193.151.148.0/22و193.151.152.0/22. أربع بادئات أكثر تحديدًا تكتمل بها المجموعة:193.151.156.0/24،193.151.157.0/24،193.151.158.0/24و193.151.159.0/24. هذا التعداد لا يصف استخدام كل كتلة، لكنه يُظهر أن الرقم الإجمالي يعتمد على سلسلة من الإعلانات القابلة للتحديد بدلاً من تقدير تجاري.

في الساعة 16 UTC من 20 يوليو 2026، كان RIPEstat يعطي193.151.156.0/24كآخر بادئة مرصودة. وأشارت الحالة نفسها إلى أن 324 من أصل 325 من أقران RIS IPv4 المختارين كانوا يرون AS60077. هذه النسبة تعني أن الأصل كان مرئيًا على نطاق واسع في نظام الجمع هذا وقت القياس. لا تضمن أن كل مستخدم إنترنت كان لديه مسار جيد الأداء، لكنها تستبعد صورة إعلان هامشي أو غير مرئي في العينة.

قدم bgp.tools أيضًا AS60077 كشبكة نشطة، مع 18 بادئة IPv4 مصدرها، ولا بادئة IPv6 مصدرها، وAS43754 كأعلى المنبع. استخدمت البطاقة ملصقًا مرتبطًا باستضافة الخوادم. هذا التلخيص مفيد كتأكيد عام، لكنه لا يضيف دليلاً على سعة العميل. يصف ملصق الفئة كيفية تصنيف الشبكة؛ لا يقيس عدد الآلات النشطة أو معدل الإشغال أو حجم الموارد المتاحة.

يمكن أن تكون البصمة أساسًا للمتابعة. يمكن ملاحظة تغير في عدد البادئات أو تغيير في الأصل أو تطور في رؤية RIS بمرور الوقت. بالنسبة لفريق العناية الواجبة، تكون هذه المؤشرات أكثر فائدة عند ختمها بالوقت ومقارنتها بملاحظات لاحقة. بمعزل عن ذلك، فإنها تعطي صورة فوتوغرافية. بالمقارنة مع مرور الوقت، يمكنها أن تشير إلى توسع أو انكماش أو هجرة أو حادث يحتاج إلى فحص.

وحتى في دور المتابعة هذا، يبقى الحذر ضروريًا. لا يرصد الجامعون كل جلسة BGP خاصة، وتعتمد رؤيتهم على نقاط المراقبة الخاصة بهم. الطريق الذي يراه جميع أقران RIS تقريبًا لا يعني خدمة خالية من الأعطال. إنه يشير إلى أن معلومات التحكم منتشرة على نطاق واسع. لا تزال جودة التسليم تعتمد على مسارات البيانات والازدحام والمعدات والمواقع والتطبيقات التي لا تصفها هذه الإعلانات.

مساحة العناوين ليست مقياسًا لسعة السحابة

رقم 14080 عنوانًا يبدو كميًا، مما يجعله عرضة للتفسير المفرط. إنه يقيس الحجم النظري للبادئات المخصصة حاليًا للأصل في العرض المستخدم. لا يكشف عن عدد العناوين المخصصة أو المحجوزة أو غير المستخدمة أو المشتركة أو المفلترة أو المكرسة لوظائف داخلية. ولا يخبرنا بعدد العملاء أو الآلات الافتراضية أو الخدمات المقابلة لهذه المساحة.

يمكن للعنوان العام أن يمثل جهازًا، أو معدات حدودية، أو وظيفة ترجمة، أو نهاية مشتركة، أو موردًا مؤقتًا. يمكن أن تشارك عدة أحمال نفس العنوان، بينما يمكن لبنية واحدة أن تستهلك عدة عناوين. وبالتالي، فإن العلاقة بين المساحة المُعلنة وقدرة الحوسبة ليست ثابتة ولا يمكن حسابها مباشرة من المسارات. ينطبق نفس التحفظ على التخزين والذاكرة وعرض النطاق الترددي القابل للبيع والطاقة الكهربائية.

هذا التمييز أساسي في حالة Cloud.ir، لأن الكتالوج يقدم عدة عائلات منتجات. لا يُظهر الخادم السحابي وVPS وخدمة التخزين وCDN وإدارة النطاقات بالضرورة مواردها بنفس الطريقة. لا تربط المصادر العشرون البادئات الثمانية عشر بتوزيع حسب المنتج. كما لا تسمح بتحديد حصة المساحة المخصصة للبنية التحتية للتحكم أو الخدمات الداخلية أو العملاء.

السعة القابلة للاستخدام فعليًا هي مفهوم تشغيلي واقتصادي. تعتمد على المعدات المثبتة وحدود الإفراط في التخصيص والاحتياطيات الأمنية والطلب الأقصى وقيود الموقع. تعتمد أيضًا على سعة الشبكة المتاحة للمستخدمين، وليس فقط عدد العناوين. لا يتم قياس أي من هذه المتغيرات في المجموعة المدروسة.

لذلك يجب على التحليل الدقيق رفض اختصارين. الأول هو معاملة العناوين البالغ عددها 14080 كـ14080 وحدة تجارية. الثاني هو اعتبار أن عدم وجود بيانات عن السعة يعني عدم وجود سعة كبيرة. يحدد الملف سطح IPv4 بحجم قابل للقياس؛ ولا يسمح بتحويل هذا السطح إلى عرض قابل للبيع أو حمل مستدام.

بالنسبة للمشتري، الاستخدام الصحيح للرقم أكثر تواضعًا. يمكن استخدامه للتحقق من أن المشغل يتحكم في بصمة عامة متسقة وتحديد البادئات المرتبطة بالخدمة أثناء الاختبارات. لا يحل محل التزام بالموارد أو بنية سعة أو حدود احتكاك أو أدلة أداء. يصبح بيانات التوجيه مفيدة للعناية الواجبة عندما تكون مرتبطة بمنتج معين، وليس عندما تتحول إلى مؤشر عالمي.

بادئة RPKI صالحة توفق بين ثلاثة أنواع من الأدلة

توفر البادئة193.151.156.0/24نقطة تحكم مفيدة بشكل خاص. أعاد التحقق من RPKI في RIPEstat الحالةvalid، مع ROAs تغطي الأصل 60077. هذا يعني أنه، بالنسبة لهذه العينة، فإن الارتباط بين البادئة المُعلنة وAS60077 يحترم ترخيص الأصل المنشور.

ربط RIPE RDAP نفس البادئة بالنطاق PA النشطIR-AT-20210316، المسجل لإيران ويغطي193.151.128.0إلى193.151.158.255. ذكر التسجيلASIATECH-MNTوجهات الاتصال الإدارية والفنية Asiatech NOC. وبالتالي، تلتقي ملاحظة BGP وترخيص RPKI وإسناد مورد إداري حول نفس المثال.

هذا التوافق أكثر إقناعًا من سطر سجل واحد. يُظهر أن الأصل المرصود بالفعل يتوافق مع الأصل المصرح به للبادئة المختبرة وأن المساحة مرتبطة بنطاق يُدار تحت معرفات Asiatech. بالنسبة لتخصيص الشبكة، هذه نتيجة إيجابية. تقلل من خطر الخلط بين AS60077 ورقم مذكور فقط على صفحة أو أصل غير مصرح به لهذا المثال.

لكن نطاق التحقق يجب أن يظل ضيقًا. النتيجة تتعلق بـ193.151.156.0/24في وقت الاستعلام. لا توفر المجموعة تدقيقًا مفصلاً لـ RPKI لكل من البادئات الثمانية عشر. لذلك سيكون من غير الصحيح كتابة أن كل البصمة صالحة بالضرورة بناءً على هذه العينة وحدها. الاستنتاج القابل للتحقق هو أن طريقًا واحدًا مهمًا وشائعًا على الأقل لديه ترخيص RPKI متسق.

كما لا يشهد RPKI على الخدمة الواقعة خلف العنوان. تساعد الآلية الشبكات في الحكم على ما إذا كان الأصل مصرحًا به لبادئة. لا تختبر توفر الخادم أو سلامة البيانات. لا تؤكد المبنى أو مالك المعدات أو طاقة النسخ الاحتياطي أو العزل بين العملاء أو جودة الدعم. يمكن أن يكون الطريق صالحًا لـ RPKI مع أنه يؤدي إلى خدمة غير متاحة لسبب آخر.

هذا الحد ليس ضعفًا في RPKI؛ إنه يعكس هدفه. لا يطلب التحليل الجيد من آلية أمن توجيه حل مسألة استمرارية الأعمال. يستخدم النتيجة لما تثبته: ترخيص الأصل. ثم يبحث عن عناصر أخرى للسعة والتكرار والتعافي.

بالنسبة لفريق العميل، يمكن أن تصبح هذه البادئة علامة مرجعية ملموسة. يمكنه التحقق مما إذا كانت عناوينه أو وجهات Cloud.ir الخاصة به تقع ضمن الإعلانات المنسوبة إلى AS60077، وما إذا كان الأصل يظل مستقرًا وما إذا كانت حالة RPKI تظل متسقة. هذا التحقق لا يجيب على جميع الأسئلة، لكنه يحول جزءًا من العلاقة إلى إشارة قابلة للملاحظة بدلاً من مجرد وعد.

BGP وRIPE Whois لا يصفان الحالة نفسها

تضيف رؤية التناسق من RIPEstat تمييزًا أساسيًا آخر. بادئات IPv4 لـ AS60077 المرصودة في BGP ظهرت أيضًا في RIPE Whois. هذا التقارب يدعم التناسق الإداري للإعلانات الحالية. يقلل الفجوة بين المسارات المرصودة والكائنات المنشورة في السجل.

مع ذلك، أظهرت الرؤية نفسها عدة نطاقات أوسع أو مكونات موجودة في RIPE Whois دون أن تُرى في BGP. هذا التباين ليس بالضرورة شذوذًا. يمكن لكائن سجل أن يغطي موردًا محجوزًا أو تجميعًا أو سياسة محتملة أو تكوينًا غير مُعلن حاليًا بهذا الشكل. يصف السجل ما هو مُعلن؛ يظهر BGP جزءًا مما يتم نشره فعليًا.

يفرض هذا الاختلاف انضباطًا في المفردات. النطاق المسجل في Whois ليس تلقائيًا طريقًا نشطًا. سياسة الاستيراد ليست تلقائيًا جلسة مرئية. على العكس، غياب علاقة في الرؤية العامة لا يثبت عدم وجود علاقة خاصة أو مؤقتة. يجب التوضيح ما إذا كان الحديث عن كائن إداري أو سياسة مُعلنة أو رصد توجيه.

AS43754 يوضح حالة التقارب: يظهر في معلومات الاستيراد والتصدير من جانب BGP ومن جانب Whois. AS212895 يوضح الحالة المعاكسة: كان موجودًا في بيانات استيراد Whois، لكن ليس في BGP. وبالتالي، يسمح الملف بالقول إن AS43754 هو كل من مُعلن ومرصود في الدور المدروس. لا يسمح بتقديم AS212895 كمسار نشط على أساس التصريح فقط.

يصبح هذا الفارق حاسمًا عند تقييم التكرار. يمكن لقائمة السياسات أن تعطي انطباعًا بوجود عدة خيارات، لكن الخيار المسجل ليس بعد طريقًا متاحًا ومختبرًا ومصممًا. لدعم ادعاء بالتبديل، يجب رصد الطريق ومعرفة استقلاليته وامتلاك عناصر حول أدائه عند حدوث عطل. لا يتم إثبات أي من هذه المستويات الثلاثة لـ AS212895 في المجموعة.

تعمل المقارنة بين Whois وBGP كمرشح ضد القراءة الحرفية للسجلات. تحافظ على قيمة التصريحات دون الخلط بينها وبين حالة الشبكة. في حالة AS60077، تزيد الثقة في البادئات المرصودة حاليًا بينما تمنع تحويل كل كائن أو كل استيراد مُعلن إلى قدرة تشغيلية.

IPv6 إشارة نقطية، وليس أصلًا حاليًا مثبتًا

تتناقض صورة IPv6 بشكل حاد مع سطح IPv4. لم يحصِ حالة توجيه RIPEstat أي بادئة IPv6 مرئية حاليًا كمنشأ من AS60077. لم يرَ أي من أقران RIS IPv6 البالغ عددهم 321 النظام المستقل في هذا الدور. أشار bgp.tools أيضًا إلى صفر بادئات IPv6 مصدرها.

مع ذلك، احتوت قائمة البادئات المُعلنة على2a05:1a30::/34لختم زمني واحد، 13 يوليو 2026. هذه الملاحظة دقيقة بما يكفي لوجوب الاحتفاظ بها، لكنها محدودة جدًا لدعم استنتاج بخدمة دائمة. قد تتوافق مع إعلان قصير، أو تجربة، أو انتقال، أو حدث لا تصفه المصادر. لا تقدم المصادر المجمعة تفسيرًا أو استمرارية.

هناك خطآن متماثلان محتملان. الأول هو استخدام هذا الإدخال الفريد لتأكيد أن AS60077 يدير حاليًا أصل IPv6 مستقر. حالة التوجيه الحالية لا تثبت ذلك. الثاني هو تأكيد عدم وجود خدمة IPv6 في Cloud.ir. قد تستخدم المنتجات أصلاً آخر، أو مسارات لا تربطها المجموعة بـ AS60077، أو وظائف غير مرئية في هذه البيانات.

وبالتالي فإن الصياغة القابلة للدفاع محدودة زمنيًا وموضوعيًا: في وقت الصورة، لم يُظهر الملف بادئة IPv6 منشؤها حاليًا AS60077، على الرغم من ظهور نقطي لـ2a05:1a30::/34قبل أسبوع. تصف هذه الجملة الملاحظة بدقة دون تحويل الغياب الحالي إلى غياب عالمي.

بالنسبة للعميل الذي يطلب اتصالاً مزدوج المكدس، يجب أن يؤدي هذا الشك إلى التحقق حسب المنتج. يجب سؤال عناوين IPv6 المخصصة والنظام المستقل الذي ينشئها والخدمات المغطاة وكيفية اختبار الاتصال. مجرد ذكر IPv6 لا يكفي؛ على العكس، رؤية AS60077 لا تكفي لرفض أي احتمال.

يمكن أن تكون حلقة 13 يوليو أيضًا نقطة متابعة. إذا عادت البادئة بشكل مستقر، يمكن أن يتطور الاستنتاج. إذا بقيت غائبة، سيستمر الملف في وصف بصمة عامة IPv4 بشكل أساسي. التحليل المختوم بالوقت يسمح بهذا التحديث دون محو ما تم رصده فعليًا.

AS43754 هو الاعتماد المرئي، وليس دليلاً على التنوع المستقل

لم تُرجع رؤية الجيران من RIPEstat سوى AS43754 لـ AS60077. وصف RIPEstat وRIPE RDAP AS43754 بأنه نشط ومملوك لشركة Asiatech Data Transmission company. قدمه bgp.tools أيضًا كأعلى منبع لـ AS60077. وبالتالي، تتقارب عدة مصادر على علاقة مرئية وعلى هوية الشبكة الأخرى.

يسمح هذا التقارب بتسمية الاعتماد العام المرصود. لا يسمح برسم كل الطوبولوجيا. قد يفوت الجامعون العلاقات الخاصة، أو جلسات الطوارئ، أو المسارات غير المُصدَّرة، أو التكوينات التي يتم تنشيطها فقط عند وقوع حادث. حقيقة ظهور جار واحد فقط ليست دليلاً رياضيًا على عدم وجود أي جار آخر.

لكن لا ينبغي عكس التحفظ بشأن الزوايا العمياء. لا يمكن استخدام احتمال وجود مسارات غير مرئية لتأكيد تكرار مستقل. في الملف، لا يوجد أعلى منبع ثان نشط ومستقل تم التحقق منه. AS212895 يظهر في تصريح Whois، لكنه غير مرصود في BGP. يبقى AS43754 الجار الوحيد الذي تُظهره البيانات العامة المجمعة فعليًا.

تضيف هوية AS43754 سؤالاً عن مجال العطل. إنه منسوب إلى Asiatech Data Transmission company، بينما AS60077 منسوب إلى Asre Dadeha Asiatech. الأسماء تشير إلى تقارب Asiatech، لكن المصادر لا تقدم الهيكل القانوني أو التشغيلي التفصيلي الذي يسمح برسم جميع تبعياتهما المشتركة. لذلك سيكون مبالغًا فيه التصريح بأنهما يشتركان بالضرورة في كل معدات أو موقع.

سيكون مبالغًا فيه بنفس القدر معاملة AS43754 كدليل على الاستقلال الخارجي. يُحكم على التنوع المفيد من خلال الموارد المنفصلة فعليًا: المشغل، الألياف، مداخل المباني، المعدات، التغذية، التحكم، والسعة. الرقم المختلف لنظام مستقل لا يثبت وحده أن هذه الأبعاد مستقلة. لا تقدم المجموعة المعلومات اللازمة لإجراء هذا الاختبار.

الفرق بين التكرار والاستقلال مهم. يمكن أن تحتوي البنية على عدة معدات أو عدة روابط تحت نفس التحكم وتوفر حماية حقيقية ضد بعض الأعطال. هذه الحماية يمكن أن تكون قيمة. لكنها لا تغطي بالضرورة عطلاً مشتركًا يؤثر على نفس المشغل أو نفس الموقع أو نفس خندق الألياف أو نفس خطة التحكم. لا تصف المصادر السيناريوهات المغطاة.

بالنسبة للمشتري، لا ينبغي أن يكون السؤال فقط: "هل يوجد رابط ثان؟" يجب أن يسأل من يديره، وأين يمر، وأين ينتهي، وما السعة التي يحتفظ بها أثناء العطل، ومتى تم اختبار التبديل. كما يجب معرفة ما إذا كانت الخدمات المعنية بالعقد تستخدم هذه المسارات فعليًا. توفر البيانات العامة نقطة انطلاق مع AS43754، وليس الإجابات الكاملة.

الجار المرئي هو أيضًا تذكير بأن الانتشار الواسع للبادئات ليس مرادفًا للتنوع الكبير. يمكن لطريق أن يصل إلى 324 من أقران RIS عبر اعتماد مركز في أعلى المنبع. يرى الجامعون نتيجة الانتشار؛ لا يكشفون عن جميع نقاط الضعف المادية التي تسبق هذا الانتشار.

PeeringDB يوثق بشكل أساسي ما لا يتم الكشف عنه

كان لدى PeeringDB بطاقة شبكة حالية لـ ASN 60077 باسم Asre Dadeha Asiatech. الحقولstatus=okوrir_status=okتشير إلى أن التسجيل كان سليمًا في إطار المنصة والسجل المعني. وجود البطاقة هو إشارة هوية إضافية.

لكن المحتوى التشغيلي العام لهذه البطاقة كان محدودًا جدًا. أشار PeeringDB إلىix_count=0وfac_count=0. لم يتم توفير أي موقع ويب أو looking glass أو خادم توجيه أو عنوان URL للسياسة. كما لم تكشف البطاقة عن تقدير لحركة المرور أو النطاق. بالنسبة لقاعدة بيانات مصممة لوصف التوصيلات البينية، فإن نقص التفاصيل يترك القليل من العناصر القابلة للاستخدام لإعادة بناء موقع.

يجب قراءة الأصفار كأصفار إعلان في هذا المصدر، وليس كدليل على الغياب المادي. يعتمد PeeringDB على المعلومات التي يدخلها ويحافظ عليها المشاركون. يمكن للشبكة استخدام موقع دون نشره في بطاقتها، أو الاتصال بشكل خاص، أو اختيار عدم تفصيل سياستها.fac_count=0لا يعني بالتالي "لا مركز بيانات".

بنفس الطريقة،ix_count=0لا يثبت عدم وجود أي ربط. يعني أن البطاقة لم تُعلن عن ارتباط عام بنقطة تبادل. علاقات العبور والتوصيلات الخاصة لا تقتصر على خطوط نقاط التبادل. الجار الوحيد AS43754 الذي رصده RIPEstat يقدم نوعًا آخر من الإشارات، لكنه لا يزال لا يقدم موقعًا.

لهذا الغياب عن الكشف نتيجة عملية مع ذلك. لا يمكن للمحلل الخارجي استخدام PeeringDB للتحقق من المبنى الأصلي أو التنوع الحضري أو فصل مداخل الألياف أو المشاركة في مصفوفة تبادل عامة. الطريق مرئي على نطاق الإنترنت، بينما تظل نقطة انطلاقه المادية معتمة في هذه القاعدة.

البطاقة لا توفر أيضًا looking glass يسمح لطرف ثالث بفحص رؤية التوجيه من داخل الشبكة نفسها. لا تنشر سياسة تشرح شروط التبادل. هذا النقص لا يثبت سوء التشغيل؛ إنه ببساطة يقلل من إمكانيات التحقق المستقل من المعلومات المفتوحة.

بالنسبة للعناية الواجبة، يعمل PeeringDB هنا بشكل أقل كخريطة وأكثر كحد وثائقي. يؤكد أن هوية الشبكة لديها بطاقة حالية، ثم يُظهر أن الحقول القادرة على ربط هذه الهوية بمواقع وتبادلات فارغة. هذا المزيج يعزز أطروحة المقال: سيطرة IPv4 مرئية، لكن المسار المادي ليس كذلك.

يمكن للمشغل تقليل هذا الشك من خلال نشر معلومات دقيقة، لكن النشر وحده لا يثبت المرونة بعد. يجب تقريب إعلان الموقع من دليل على الحضور الحالي؛ وإعلان نقطة التبادل من بيانات التوصيل. عندها سيكون PeeringDB دليلاً أفضل، وليس شهادة عالمية.

Cloud.ir يمتلك سطحًا تجاريًا نشطًا وقابلاً للتحديد

الجانب التجاري من الملف ليس مجرد أرشيف. كان موقع Cloud.ir يستجيب عبر HTTPS في وقت الجمع. شكلت صفحته الرئيسية وصفحة التعريف به وصفحة الاتصال وخريطة موقع الخدمات سطحًا يمكن الوصول إليه من قبل العملاء المحتملين والعملاء. هذا التوفر يميز العرض عن علامة تجارية لا تترك سوى آثار تاريخية.

أشارت خريطة الموقع إلى صفحات مخصصة للخادم السحابي وVPS ومركز البيانات السحابي والمفتاح السحابي وإدارة النطاقات وCDN والتخزين السحابي. كانت قيمlastmodللصفحات الرئيسية في 2025 و2026. هذه التواريخ لا تضمن تعديل كل منتج بعمق، لكنها تُظهر أن الكتالوج يتم الحفاظ عليه في فترة حديثة.

تشير الصفحات الرسمية إلى أن الخدمة السحابية بدأت خلال العام 1399 من التقويم الإيراني وأنها تقدم أكثر من عشرين منتجًا. وتؤكد أيضًا أن العرض يعمل على مراكز بيانات Asiatech في إيران. تصف هذه العناصر السرد التشغيلي للشركة وتسمح بفهم كيفية تقديم اعتمادها على بنية Asiatech التحتية.

وبالتالي، يدعم الملف ملاحظتين منفصلتين. من ناحية، يمتلك AS60077 حضورًا عامًا IPv4 منسوبًا إلى Asre Dadeha Asiatech. من ناحية أخرى، يقدم Cloud.ir حاليًا كتالوجًا سحابيًا مرتبطًا، في نصوصه الخاصة، بمراكز بيانات Asiatech. تقارب الأسماء والتصريحات يجعل التقارب ذا صلة.

مع ذلك، لا يشكل هذا التقارب تطابقًا خدمة بخدمة. لا تقول المصادر إن كل عنوان خادم سحابي ينتمي إلى إحدى البادئات الثمانية عشر. لا تقول إن VPS وCDN والتخزين يستخدمون نفس الشبكة تمامًا. لا تكشف عن الأنظمة المستقلة المحتملة المستخدمة للوظائف الخارجية أو التخفيف أو التوزيع.

صفحة الاتصال تضيف سطح علاقة، لكن المصادر لا تقيس جودة أو وقت الاستجابات. صفحة قابلة للوصول تثبت أن قناة منشورة؛ لا تثبت أن فريقًا يرد في كل ساعة ولا أن حادثًا معقدًا سيُحل في وقت محدد. ينطبق نفس التمييز على أي عنصر تجاري مرئي.

اهتمام الكتالوج حقيقي لكنه محدود. يثبت أن Cloud.ir يبيع ويصف مجموعة من الخدمات. يساعد في تحديد المنتجات التي يجب إجراء عناية واجبة أكثر دقة بشأنها. لا يحل محل بنية كل منتج. كلما كان الكتالوج أوسع، أصبح الإسناد العالمي لمسار شبكي واحد أكثر خطورة.

ادعاءات مركز البيانات تبقى تصريحات من المشغل

تستخدم صفحات Cloud.ir إشارات إلى ISO27001 وTIA-942 ومستويات مقدمة بمفردات من نوع Tier 2/3. كما تربط الخدمات بمراكز بيانات Asiatech في إيران. هذه الادعاءات ذات صلة لأنها تشير إلى المعايير والمرونة التي يرغب المشغل في إبرازها.

مع ذلك، لا تحتوي المجموعة على شهادة مستقلة، ولا تقرير تدقيق، ولا قائمة دقيقة بالمواقع التي ينطبق عليها كل ادعاء. لا توفر نطاق أي شهادة محتملة، أو فترة صلاحيتها، أو الكيان المعتمد، أو الاستثناءات. الإشارة إلى معيار على صفحة خدمة لا تكفي لإثبات أن كل مكون من كل منتج مغطى.

ينطبق نفس الحذر على مستويات من نوع Tier 2/3. يمكن لهذه التعبيرات أن تصف تصميمًا أو طموحًا أو مستوى مدّعًى أو تصنيفًا مطبقًا على موقع معين. بدون مستند مستقل وبدون تحديد الموقع، من المستحيل معرفة بالضبط ما تم تقييمه. لذلك يجب أن تُنسب المقالة إلى Cloud.ir، ولا تُقدم كنتائج تم التحقق منها بواسطة المصادر العشرين.

البيانات لا تصف أيضًا طوبولوجيا التغذية والتبريد. لا تعطي عدد المسارات الكهربائية، أو مدة الطوارئ، أو فصل المجموعات، أو السعة الحرارية المتاحة. لا توثق مداخل الألياف، أو المسافة بين المواقع، أو التبعيات المشتركة. كل هذه العناصر ضرورية لتحويل ادعاء مركز بيانات إلى تحليل مرونة.

غياب هذه القطع لا يدحض الادعاءات. إنه يشير فقط إلى أن المراقب العام لا يمكنه التحقق منها بهذه المجموعة. الاستنتاج السلبي المطلق سيكون غير مبرر مثل القبول دون تحفظ. الصياغة الصحيحة هي أن الصفحات تقدم هذه الادعاءات وأن المجموعة لا تتحقق منها بشكل مستقل.

هذا الإسناد الصريح يحمي أيضًا قيمة الأدلة المستقبلية. إذا نشر Cloud.ir لاحقًا شهادة يكون نطاقها وموقعها وتاريخها واضحين، يمكن إثراء الملف دون إعادة كتابة الملاحظة الحالية. إذا أكد مصدر آخر موقعًا، يمكن إضافته كتأكيد. اليوم، تظل الطبقة المادية ادعاءً بحاجة إلى التحقق.

بالنسبة للعميل، تعتمد الحاجة إلى الدقة على المنتج. النطاق المُدار والآلة الافتراضية الحرجة ونسخة الاحتياط ليست لها نفس المتطلبات. يجب معرفة في أي موقع يقع كل مكون، وما الضوابط المطبقة، وما التبعيات المشتركة. العلامة التجارية العالمية لمركز بيانات لا تلبي هذه الدقة.

لا يوجد مستند يربط بعد كل منتج بمساره وموقعه

أكبر فراغ في الملف يقع بين أدلة الشبكة وصفحات الخدمة. من ناحية، تقدم المصادر قائمة ببادئات ونظام مستقل. من ناحية أخرى، تقدم أسماء منتجات ووعودًا تجارية. بينهما تفتقر مصفوفة إسناد.

مثل هذه المصفوفة ستحدد، للخادم السحابي، النطاقات المستخدمة، والنظام المستقل الأصلي، والموقع أو المواقع، وأعلى المنبع الرئيسي، وآلية الطوارئ. ستفعل نفس الشيء لـ VPS والتخزين وCDN والخدمات الأخرى. ستوضح أيضًا ما إذا كانت خطة التحكم وخطة البيانات تشتركان في نفس التبعيات.

بدون هذه المصفوفة، تظل عدة بنى ممكنة. قد تستخدم بعض المنتجات AS60077 مباشرة. قد يعتمد البعض الآخر على AS43754، أو على شبكات طرف ثالث، أو على موارد غير مرئية في المجموعة. قد يكون لـ CDN توزيع مختلف عن الخادم السحابي. قد يكون للتخزين مسار داخلي مختلف. لا تسمح المصادر بالاختيار بين هذه الاحتمالات.

هذا الشك يمنع استخدام نجاح توجيه كبديل لاختبار منتج. حقيقة أن193.151.156.0/24مرئي على نطاق واسع وصالح RPKI لا تثبت أن مثيلًا معينًا متاح. بالمقابل، المثيل المتاح لا يثبت أنه يقع في هذه البادئة. يجب أن يبدأ التقييم من المورد الذي تم شراؤه فعليًا.

يمكن أن تبدأ طريقة التحقق من العناوين التي يلاحظها العميل. يقارنها بالبادئات وأصلها وحالة RPKI. ثم يطلب من المشغل تأكيد الموقع والمسارات المطبقة. أخيرًا، يقارن هذه الإجابات بالالتزامات التعاقدية واختبارات التبديل. كل خطوة من هذه الخطوات تغطي طبقة مختلفة.

يجب أن يشمل التحكم أيضًا وظائف الإدارة. قد يعتمد البوابة وAPI ونظام النسخ الاحتياطي وحركة الجهاز على شبكات مختلفة. عطل يوفر خطة البيانات لكنه يصيب المصادقة يمكن أن يمنع التدخل. الصفحات المدروسة لا تقدم هذا التحليل؛ وبالتالي لا تسمح بإسناد استقلالية غير مُظهرة.

تشرح هذه الفجوة الوثائقية لماذا لا تتعلق الأطروحة بوجود Cloud.ir. العرض والشبكة مرئيان بوضوح. تتعلق بالصلة بينهما. تصبح البنية التحتية السحابية مُقيَّمة من طرف إلى طرف فقط عندما يمكن ربط المسارات والمواقع والسعة وإجراءات التعافي بالخدمات المستخدمة فعليًا.

SLA يرسم حدودًا للمسؤولية أكثر من خطة تعافي

SLA لـ Cloud.ir هو قطعة أساسية لأنه يُظهر ما يختار المشغل تغطيته واستبعاده. يحد النص ضمانات التوفر بالشبكة والخادم السحابي في إطار العمليات العادية. هذا النطاق أضيق من الفكرة العامة لتوفر تجربة العميل بأكملها.

يستبعد المستند على وجه الخصوص برامج وأنظمة تشغيل العميل وأخطاء التكوين وأعطال المعدات المملوكة للعميل. هذا التوزيع كلاسيكي في نموذج بنية تحتية: يحمي المزود طبقات معينة، بينما يظل العميل مسؤولاً عما يثبته ويديره. لكنه يعني أن انقطاعًا مرئيًا للمستخدم قد يقع خارج الضمان إذا كان سببه يُعزى إلى طبقة العميل.

هجمات رفض الخدمة مدرجة أيضًا ضمن الاستثناءات. هذا الذكر مهم لخدمة مكشوفة على الإنترنت. لا يعني عدم وجود حماية؛ يشير إلى أن الضمان الموصوف لا يجب أن يُقرأ كتغطية عالمية لهذا السيناريو. لا تفصل المصادر خدمة تخفيف أو الظروف التي يتم فيها التعامل مع الهجوم.

الصيانة والتصحيحات الحرجة مستبعدة أيضًا. وبالتالي، يمكن أن تنتج نافذة مخططة وتدخل عاجل عدم توفر دون أن تدخل ضمن نفس حساب العطل العادي. لتقييم التوفر المُعاش، يجب على العميل معرفة ليس فقط النسبة المئوية المُعلنة، ولكن أيضًا الفئات المسحوبة من الحساب وتكرار التدخلات والإشعار المسبق.

يذكر SLA أيضًا القوة القاهرة والتعليقات والإيقافات المطلوبة من قبل العميل وعدم الدفع وبعض الأوامر القانونية أو الأمنية. تُظهر هذه الاستثناءات أن الوصول إلى الخدمة يعتمد على عوامل فنية وتعاقدية وتنظيمية. يمكن لبنية أن تعمل بشكل صحيح مع أنها تصبح غير متاحة لسبب خارجي عن المعدات.

لا ينبغي تقديم هذه القائمة على أنها غير طبيعية في حد ذاتها. SLA يعمل بالضبط على تحديد حد. تكمن قيمته التحليلية في أنه يمنع تحويل وعد التوفر إلى ضمان مطلق. يمكن تصنيف حادثين متطابقين من وجهة نظر المستخدم بشكل مختلف حسب سببه والطرف المسؤول.

المستند الذي تمت استشارته لا يوفر تسلسلات التبديل لكل خدمة. لا يعطي هدف وقت الاسترداد أو هدف نقطة الاسترداد أو نتيجة تمرين أو تاريخ حوادث. لا يحدد السعة المتاحة عند فقدان مكون رئيسي. الحد التعاقدي مرئي؛ آلية الاسترداد الفنية تظل معتمة.

هذا التمييز مهم بشكل خاص للبيانات. ضمان توفر الخادم أو الشبكة لا يجيب تلقائيًا على سؤال الثبات أو النسخ أو الاستعادة. لا تسمح المجموعة بتحديد مكان وجود النسخ، أو إذا كانت تشترك في موقع، أو كيف يتم اختبارها. لذلك سيكون من غير الصحيح استنتاج استرداد البيانات من ضمان الوصول.

SLA لا يثبت أيضًا أن جميع منتجات الكتالوج تتمتع بنفس التغطية. لغته تركز على الشبكة والخادم السحابي في ظروف محددة. يجب على عميل VPS أو التخزين أو CDN التحقق من الالتزامات المطبقة على خدمته المحددة. لا ينبغي افتراض أن الكتالوج التجاري والنطاق التعاقدي متطابقان.

لمقارنة العروض، يجب على المشتري طلب ثلاث مجموعات من المعلومات. الأولى هي صيغة حساب التوفر مع الاستثناءات. الثانية هي بنية الاسترداد مع التبعيات. الثالثة هي دليل التشغيل في شكل اختبارات وحوادث موثقة. SLA المدروس يقدم جزءًا من المجموعة الأولى، لكن ليس المجموعتين الأخريين.

رؤية التحكم لا تتنبأ بالسلوك أثناء العطل

يمكن لـ AS60077 الاستمرار في الإعلان عن بادئاته الثمانية عشر بينما يواجه خدمة معينة مشكلة داخلية. على العكس، يمكن أن يتغير الطريق بينما تظل الخدمة متاحة عبر مسار آخر. يتطور BGP وتوفر التطبيق على مستويات مختلفة. يجب ملاحظة علاقتهما، لا افتراضها.

عطل الخادم أو التخزين أو البرنامج لا يزيل الطريق بالضرورة. سيستمر الجامعون في رؤية الأصل، حتى لو لم يعد العميل قادرًا على استخدام موارده. عطل في أعلى المنبع يمكن، على العكس، أن يغير الرؤية مع ترك الأنظمة الداخلية في حالة. لا تحتوي المصادر على تسلسل زمني للحوادث يسمح بمقارنة هذه الإشارات.

ينطبق نفس التحفظ على التبديل. يمكن أن يوجد جهاز ثانٍ أو موقع ثانٍ دون تحمل الحمل بشكل صحيح. الدليل المفيد ليس فقط وجوده، بل نتيجة تمرين أو حدث حقيقي. يجب معرفة وقت الكشف ووقت القرار ووقت التقارب وحالة البيانات بعد الاسترداد.

الجار العام الوحيد المرصود، AS43754، يركز الانتباه على مسار أعلى المنبع، لكنه لا يسمح بنمذجة كل السلوك. قد يتدخل تكرار مخفي. قد يحد تبعية مشتركة من التبديل. بدون طوبولوجيا وبدون اختبار، يظل الفرضان مفتوحين. يجب على التحليل تسجيل هذا الشك بدلاً من اختيار السيناريو الأكثر تفاؤلًا أو الأكثر إثارة للقلق.

رؤية RIS نفسها هي مؤشر خارجي. تُظهر أن العديد من نقاط المراقبة تتلقى الإعلان. لا تقيس زمن الوصول أو الفقدان أو التشبع أو نجاح اتصال بتطبيق. يمكن أن تكون الشبكة مرئية ومتدهورة. يجب استكمال قياس التحكم بقياسات البيانات والخدمة.

هذا التمييز يسمح بتجنب ارتباك شائع في اقتصاد السحابة. الموارد التي تجعل العرض قابلاً للبيع لا تقتصر على العنونة والتوجيه. تشمل الحوسبة والتخزين والطاقة والتبريد والعمليات والدعم والقدرة على استبدال مكون. تُظهر المجموعة جزءًا من المستوى الأول، لكن ليس الكل.

لذا لا ينبغي أن يكون الاستنتاج أن بيانات التوجيه ثانوية. إنها ضرورية لإسناد الشبكة ومراقبتها. تزداد فائدتها عند الاعتراف بحدودها. تكتشف بعض الانقطاعات وتجعل بعض الادعاءات قابلة للتحقق؛ لا تحل محل خطة الاستمرارية.

ما يمكن للمشتري التحقق منه من الأدلة المتاحة

الخطوة الأولى هي تحديد المنتج المعني فعليًا. المنظمة التي تشتري خادمًا سحابيًا ليست لها نفس التبعيات تمامًا مثل المنظمة التي تستخدم CDN أو التخزين. يجب الحصول على العناوين وأسماء الخدمة ونقاط الإدارة والالتزامات التعاقدية الخاصة بهذا المورد.

يمكن بعد ذلك مقارنة العناوين المرصودة بالبادئات الثمانية عشر لـ AS60077. إذا كانت موجودة فيها، يكون لدى المشتري رابط ملموس بين خدمته والبصمة المحللة. إذا لم تكن موجودة، لا يجب أن يستنتج تلقائيًا وجود خلل: قد تستخدم الخدمة أصلاً آخر. يجب أن يسأل عن الكيان والنظام المستقل اللذين يضمنان التسليم عندها.

بالنسبة للعناوين التي تندرج تحت AS60077، يمكن مراقبة أصل BGP وحالة RPKI. مثال193.151.156.0/24يُظهر كيفية تبادل RIPEstat وRIPE RDAP وROA. يجب إجراء نفس العمل على البادئة الدقيقة للعميل. الهدف هو التحقق من الإسناد والتغييرات، وليس استنتاج التوفر الكامل.

السؤال التالي يتعلق بالمواقع. أي مبنى يستضيف الخدمة الرئيسية؟ أين توجد النسخة الاحتياطية؟ هل يشترك الموقعان في التغذية أو التبريد أو مدخل ألياف أو مشغل؟ PeeringDB لا يقدم هذه الإجابات لـ AS60077. لذلك يجب أن تأتي من وثائق دقيقة أو دليل مستقل مناسب.

يجب معاملة أعلى المنبع بنفس الدقة. AS43754 هو الجار المرئي، لكن يجب على المشتري معرفة ما إذا كان هناك مسار آخر لخدمته، وما إذا كان نشطًا، وما إذا كانت سعته كافية، وما إذا كان يتبع طريقًا ماديًا متميزًا. سياسة Whois أو رقم AS إضافي لا يشكل دليلاً على التبديل.

يجب التعبير عن السعة بوحدات المنتج. للحوسبة، قد يشمل ذلك الموارد المضمونة وحدود الإفراط في التخصيص والاحتياطيات. للشبكة، يشمل السرعات ونقاط الاحتكاك والسعة المحتفظ بها أثناء العطل. للتخزين، يشمل النسخ والسلامة والاستعادة. العناوين IPv4 البالغ عددها 14080 لا تجيب على أي من هذه الأسئلة.

يجب التحقق من الاسترداد من خلال الأهداف والنتائج. ما المهلة المطبقة على حادث مغطى؟ ما أقصى فقدان للبيانات متوقع؟ متى تم اختبار التبديل؟ ما استثناءات SLA المطبقة؟ المجموعة تُظهر الاستثناءات، لكن لا تظهر نتائج الاختبار. يجب ربط الرد التجاري بالعقد وبخدمة محددة.

يتطلب IPv6 تحكمًا منفصلاً. الإشارة النقطية لـ2a05:1a30::/34لا تثبت عرضًا حاليًا؛ الغياب الحالي لأصل AS60077 لا يثبت غياب أي منتج IPv6. يجب على العميل طلب عناوين واختبار الاتصال على المورد الذي ينوي استخدامه.

أخيرًا، يجب على العميل الاحتفاظ بمسار للخروج. القدرة على تصدير البيانات ونقل DNS واسترداد التكوينات وإلغاء الوصول تقلل الاعتماد على التعافي المثالي للمزود. لا تصف المصادر آليات Cloud.ir في هذه النقاط. تُظهر لماذا يجب طرح هذه الأسئلة قبل وقوع حادث.

يحول هذا النهج الشك العام إلى برنامج عناية واجبة. لا يفترض أن الإجابات ستكون سلبية. إنه ببساطة يميز بين العناصر القابلة للملاحظة بالفعل والعناصر التي تتطلب تأكيدًا مباشرًا. الشبكة العامة توفر معالم؛ العقد والبنية والاختبارات يجب أن تكمل السلسلة.

ما لا تسمح المصادر العشرون بتأكيده

الملف لا يسمح بتأكيد المسار الدقيق إلى مركز بيانات. لا بادئة مرتبطة بعنوان موقع أو غرفة أو رف أو مدخل ألياف. صفحات Cloud.ir تتحدث عن مراكز بيانات Asiatech في إيران، لكنها لا تعطي رسم الخرائط اللازم لربط كل خدمة بمكان.

لا يسمح بتأكيد ملكية المنشآت أو المعدات. يمكن لمنظمة أن تشغل أو تستأجر أو تعيد بيع أو تشارك الموارد. سجلات الشبكة لا تحكم في هذه النماذج. المصطلحات التجارية لا تكفي أيضًا لإثبات حق الملكية.

لا يسمح بإثبات تكرار أعلى منبع مستقل. AS43754 هو الجار الوحيد المرصود؛ AS212895 يبقى تصريح Whois غير مرئي في BGP. مسارات غير عامة قد توجد، لكنها غير مثبتة. الاستقلال المادي والتشغيلي أقل توثيقًا.

لا يسمح بحساب السعة المتاحة للعملاء. عدد العناوين لا يقيس المعالجات أو الذاكرة أو التخزين أو الطاقة أو السرعة المتبقية. صفحات الخدمة لا تقدم، في المجموعة، مخزونًا محققًا يسد هذا النقص.

لا يسمح بتأكيد عدم وجود خدمة IPv6. يثبت فقط غياب أصل IPv6 لـ AS60077 مرئي حاليًا في الصورة ووجود إشارة نقطية في 13 يوليو 2026. البنى الأخرى غير مختبرة.

لا يسمح بتقديم ISO27001 أو TIA-942 أو مستويات من نوع Tier 2/3 على أنها معتمدة بشكل مستقل لكل العرض. هذه الإشارات تأتي من صفحات المشغل ونطاقها غير موثق بقطعة خارجية في المجموعة.

لا يسمح باستنتاج سلوك الاسترداد. SLA يصف حدودًا واستثناءات، لكن ليس تسلسل استعادة محققًا. لا يتم تضمين قياس تمرين ولا تاريخ مفصل ولا هدف لكل منتج.

لا يسمح أخيرًا بإسناد كل خدمات Cloud.ir إلى AS60077. العلاقة بين العلامة التجارية وAsre Dadeha Asiatech والشبكة مدعومة على عدة مستويات، لكن مصفوفة المنتج مفقودة. يجب أن يرافق هذا الحد أي استخدام للبصمة.

هذه المنع من الاستنتاج لا تشكل قائمة شكوك. إنها النتيجة الطبيعية لتحقيق يعتمد على مصادر عامة محدودة. تمنع أن يصبح غياب الدليل اتهامًا، كما تمنع أن يصبح التصريح يقينًا.

الإشارات التي من شأنها تقليل الشك

التحسين الأول سيكون رسم خرائط عام أو تعاقدي يربط المنتجات بالبادئات والأنظمة المستقلة. سيسمح بمعرفة أي الاستنتاجات حول AS60077 تنطبق فعليًا على الخادم السحابي وVPS والتخزين أو CDN. كما سيجعل التبعيات المختلفة بين المنتجات مرئية.

التحسين الثاني سيكون كشفًا دقيقًا للمواقع والتوصيلات البينية. بطاقة PeeringDB أكثر اكتمالاً يمكن أن توفر أدلة، لكن يجب تأكيدها. تأكيد الحضور وبنية المسارات ووصف مجالات العطل ستقدم دليلاً أقوى من مجرد اسم مركز بيانات.

التحسين الثالث سيتعلق بأعلى المنبع. الرصد المستقر لجار ثانٍ مستقل، مصحوبًا بوصف التنوع المادي واختبارات التبديل، سيغير التقييم. سياسة Whois وحدها لا تكفي. يجب إظهار أن المسار نشط ومصمم وقابل للاستخدام فعليًا عندما لا يكون AS43754 متاحًا.

بالنسبة لـ IPv6، إعلان مستقر لـ2a05:1a30::/34أو بادئة أخرى، مرئي في الحالة الحالية ومرتبط بمنتجات، سيشكل إشارة أقوى. عناوين مخصصة واختبارات ستكمل الملاحظة. عندها سيصبح الإدخال الفردي في 13 يوليو حلقة في مسار موثق بدلاً من إشارة معزولة.

ادعاءات مركز البيانات ستكتسب قيمة بشهادات يتم فيها تحديد النطاق والكيان والموقع والصلاحية بوضوح. عناصر حول التغذية والتبريد والألياف وسعات الطوارئ ستسمح بالانتقال من ملصق إلى بنية قابلة للتحليل.

أخيرًا، أهداف الاسترداد ونتائج الاختبارات وتواريخ الحوادث ستقلل الفجوة بين SLA والسلوك الحقيقي. الضمان يكون أكثر إفادة عندما يرتبط بكيفية عودة الخدمة والسعة المتاحة أثناء التدهور وجودة البيانات بعد الاستعادة.

يجب أن تبقى كل هذه الإشارات في طبقتها. طريق جديد لا يثبت شهادة موقع. شهادة لا تثبت تنوع أعلى المنبع. اختبار تبديل لا يثبت السعة التجارية الدائمة. قوة الملف ستأتي من مزيجها، وليس من تحويل مؤشر واحد إلى إجابة كاملة.

بصمة قابلة للتحقق، سلسلة تسليم لا تزال غير مكتملة

تُظهر حالة CLOUD Asre Dadeha Asiatech لماذا بيانات التوجيه قوية وغير كافية في آن واحد. تحدد AS60077، وتؤكد نشاط IPv4، وتفصل 18 إعلانًا، وتقيس رؤية لدى 324 من 325 من أقران RIS IPv4، وتقدم مثال RPKI صالح. كما تربط الأصل بكائنات RIPE RDAP وجهات اتصال Asiatech.

تثبت هذه النتائج سطح سيطرة عام حقيقي. تسمح بمتابعة الشبكة والتحقق من الإسناد وتمييز طريق مرصود عن مجرد تصريح. تشكل أساسًا أقوى من كتالوج تجاري بمفرده.

نفس البيانات تبرز حدود الرؤية. لم تكن أي بادئة IPv6 حالية مرئية كمنشأ من AS60077، على الرغم من إشارة نقطية. كان AS43754 الجار الوحيد المرصود. لم يكشف PeeringDB عن موقع أو نقطة تبادل. وبالتالي لم يمكن إعادة بناء المسار المادي أو السعة القابلة للاستخدام أو التنوع المستقل.

يضيف Cloud.ir سطح عميل نشط وكتالوج يضم أكثر من عشرين منتجًا مدعاة وصفحات تمت صيانتها مؤخرًا. SLA يوضح عدة استثناءات. لكن المجموعة لا تربط كل منتج بطريق وموقع وسعة وآلية استرداد. لا تتحقق بشكل مستقل من مراجع مركز البيانات.

وبالتالي فإن الاستنتاج الأكثر متانة غير متماثل. يوجد أدلة كافية للقول إن شبكة IPv4 لـ AS60077 نشطة ومرئية على نطاق واسع، وأن Cloud.ir يقدم عرضًا تجاريًا حاليًا. لا يوجد أدلة كافية للقول كيف تعبر كل خدمة المنشآت، وما التكرار المستقل الذي يحميها، وما السعة القابلة للتعبئة، أو كيف تتعافى بعد عطل.

هذا التباين ليس حكمًا بالضعف ولا موافقة على المرونة. إنه حد معرفي. لتجاوزه، يجب على المشتري ربط خدمته الملموسة بالبادئات والمواقع والمسارات والعقد والاختبارات. طالما لم يتم تقديم هذه السلسلة، فإن AS60077 يجعل Cloud.ir مرئيًا على الإنترنت دون جعل كل البنية التحتية التي تقدم خدماته شفافة.