ZEROSPACE Christian Wittenberg يتداول باسم Zerospace Cloud يبيع سعة مستضافة لا تزال تعتمد على الرفوف والنقل ونوافذ الإصلاح

ملخص

• تحدد RIPE RDAPAS201801كـ ZEROSPACE وتربطه بـ Christian Wittenberg المتداول باسم Zerospace Cloud في فيلدوفن، هولندا؛ أفادنظرة عامة على ASمن RIPEstat بأن الـ AS تم الإعلان عنه في 15 يوليو 2026.
• الحيز المسار صغير لكنه مرئي: أظهرتحالة التوجيهبادئة IPv4 واحدة، 256 عنوان IPv4، ثمانية /48 IPv6 وجيران ملحوظان، بينما أدرجتالبادئات المعلن عنها185.140.53.0/24 بالإضافة إلى ثمانية /48 IPv6 مرئية.
• نظافة مصدر التوجيه هي نقطة قوة: أرجع RIPEstat حالة صالحة لـ RPKI لـ185.140.53.0/24ولـ2a07:1a84::/48، مع اعتماد التحقق من IPv6 على ROA عبر 2a07:1a84::/44 وبحد أقصى /48.
• الدليل التشغيلي ضعيف: يسردPeeringDBZerospace Cloud لكنه يظهر عدد صفر من نقاط التبادل العامة وصفر من المرافق؛ يقومالجيوفيدبتعيين شرائح العناوين عبر عشر تسميات حضرية، لكنه لا يثبت وجود رفوف محلية أو طاقة أو أجهزة أو دعم أو قدرة ترحيل العملاء في تلك المدن.

الشركة لديها هوية شبكة حقيقية، لكن الهوية جديدة

الحقيقة الأولى التي تستحق الفصل عن الضوضاء هي أن Zerospace Cloud ليست مجرد عبارة تسويقية. يسجل RIPE RDAP علىhttps://rdap.db.ripe.net/autnum/201801AS201801 باسم ZEROSPACE، الحالة نشطة، مع حدث تسجيل في 30 يناير 2026 وحدث آخر تغيير في 13 مارس 2026. الكيان التنظيمي في نفس استجابة RDAP هو Christian Wittenberg المتداول باسم Zerospace Cloud، مع فيلدوفن، هولندا، كتسمية العنوان العام. تسمي استجابة RDAP أيضًا عمليات شبكة Zerospace Cloud كجهة اتصال إدارية وفنية وقسم إساءة استخدام Zerospace Cloud كجهة اتصال إساءة. بالنسبة لمزود صغير للخدمات السحابية أو الاستضافة، هذا خط أساس مفيد: هناك منظمة مسماة، وشبكة مسماة، وأدوار اتصال تشغيلية مسماة.

تطابق سجلات العناوين هوية AS. يحدد RIPE RDAP علىhttps://rdap.db.ripe.net/ip/185.140.53.0/24185.140.53.0 إلى 185.140.53.255 باسم ZEROSPACE-CLOUD، معينة PA، البلد NL، الحالة نشطة، مع ملاحظات تشير إلى جيوفيد علىhttp://download.zerospace.cloud/ipam/geofeed.csv. يحدد RIPE RDAP علىhttps://rdap.db.ripe.net/ip/2a07:1a84::/442a07:1a84::/44 باسم ZEROCLOUD، مجمعة بواسطة LIR، البلد NL، الحالة نشطة، مع نفس التنظيم ونفس مرجع الجيوفيد. يحدد نظرة عامة على البادئة من RIPEstat لـhttps://stat.ripe.net/data/prefix-overview/data.json?resource=185.140.53.0/24AS201801 كحامل الأصل لـ /24 IPv4.

هذه السجلات لا تثبت وجود حوزة استضافة ناضجة. إنها تثبت حامل مسار حالي مع موارد مسجلة حية. العمر مهم. تم تسجيل النظام الذاتي وتجميع IPv6 في أواخر يناير 2026، وتم تسجيل /24 IPv4 في فبراير 2026. هذا حديث بما يكفي بحيث يجب على العملاء التعامل مع الأدلة التشغيلية العامة على أنها لا تزال قيد التشكل. يمكن لمقدمي البنية التحتية الجدد أن يكونوا قادرين؛ يمكن أن يكونوا أيضًا في مرحلة التوجيه والعلامة التجارية وعمليات الدعم وعقود الموردين المادية لا تزال قيد التعزيز. السؤال الصحيح ليس ما إذا كان AS201801 موجودًا. إنه موجود. السؤال الصحيح هو أي خدمات العملاء يمكن وضعها بأمان فوقه.

إشارة المسار العام حية. أبلغت نظرة عامة على AS من RIPEstat علىhttps://stat.ripe.net/data/as-overview/data.json?resource=AS201801عن الحامل باسم ZEROSPACE Christian Wittenberg المتداول باسم Zerospace Cloud وتم الإعلان عن AS في استعلام 15 يوليو 2026. أبلغت حالة التوجيه من RIPEstat علىhttps://stat.ripe.net/data/routing-status/data.json?resource=AS201801عن رؤية عامة واسعة: 324 من 326 من أقران IPv4 RIS و 322 من 322 من أقران IPv6 RIS كانوا يرون الحيز المسار. هذه ليست بصمة تسجيل غير مستخدم. إنها بصمة شبكة صغيرة مرئية لنظام التوجيه العالمي.

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

الحوزة المسارة صغيرة ومرئية ومعلن عنها بشكل غير متساوٍ

صورة IPv4 مضغوطة. أظهرت بيانات البادئات المعلن عنها من RIPEstat علىhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201801أن 185.140.53.0/24 تم الإعلان عنها باستمرار خلال فترة 1 يوليو إلى 15 يوليو 2026. حسبت حالة التوجيه ذلك كبادئة IPv4 واحدة و 256 عنوان IPv4. بالنسبة لخدمة استضافة أو سحابية، يمكن أن يكون /24 مفيدًا تشغيليًا، لكنه صغير. يمكنه دعم خدمة مركزة مثل anycast أو بوابات NAT أو نقاط نهاية إدارة العملاء أو مجموعة من عقد VPS أو عدد محدود من عناوين العملاء المخصصة مباشرة. إنه ليس بحد ذاته دليلاً على حوزة حوسبة كبيرة.

صورة IPv6 أوسع في رياضيات العناوين وأكثر دقة في الرؤية الحالية. يغطي سجل RDAP 2a07:1a84::/44، الذي يحتوي على ستة عشر /48 محتملاً. يسرد كائن الشبكة في PeeringDB علىhttps://www.peeringdb.com/api/net?asn=201801بادئة IPv4 واحدة وستة عشرة بادئة IPv6 في الملف الشخصي. ومع ذلك، أظهرت نقطة نهاية البادئات المعلن عنها من RIPEstat ثمانية /48 IPv6 مرئية خلال فترة المراجعة: 2a07:1a84::/48،:1::/48،:2::/48،:3::/48،:4::/48،:5::/48،:6::/48 و:9::/48. أضافت عرض اتساق توجيه AS من RIPEstat علىhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201801التفاصيل المفيدة أن 2a07:1a84::/44 كان في whois لكنه ليس في BGP نفسه، بينما كانت العديد من /48 في كل من whois و BGP والعديد من /48 الأخرى في whois لكنها ليست في BGP.

هذا الاختلاف مهم للسعة المثبتة مقابل القابلة للاستخدام. سعة العناوين المثبتة هي /44 IPv6 المسجل وبيان PeeringDB لستة عشر بادئة IPv6. سعة التوجيه القابلة للاستخدام هي المجموعة الفرعية المرئية بالفعل في BGP خلال الفترة ذات الصلة. سعة العميل القابلة للاستخدام أضيق: البادئات التي يمكن للعميل التعاقد عليها وتوجيهها عبر موقع معروف وحمايتها بـ RPKI ومراقبتها ودعمها ونقلها إذا فشل مزود أو مرفق أو مزود علوي. يمكن أن يبدو /44 ضخمًا على الورق بينما يتم تنشيط فقط /48 محددة في التوجيه العام ومجموعة فرعية أصغر مرتبطة بخدمات الإنتاج.

يشير توقيت IPv6 أيضًا إلى شبكة تحت تغيير نشط. أظهر RIPEstat 2a07:1a84::/48 و 2a07:1a84:5::/48 مرئية من بداية يوليو، مع:5::/48 يظهر فجوة قصيرة بين 3 يوليو و 5 يوليو. أظهر العديد من /48 الأخرى بدء الرؤية في 12 يوليو 2026. هذا لا يثبت عدم الاستقرار بمعنى التأثير على العملاء؛ غالبًا ما تأتي مواقع IPv6 الجديدة أو عقد الخدمة عبر الإنترنت في موجات. هذا يعني أن العميل يجب أن يسأل عن /48 التي تعتبر إنتاجية، وأيها هي تخصيصات اختبار أو مرحلة، وأيها مرتبطة بتسمية مدينة، وأيها لديها تجاوز فشل مُختبر.

التحقق من مصدر المسار هو أحد أفضل أجزاء سجل Zerospace. أرجع RIPEstat حالة صالحة لـ 185.140.53.0/24 علىhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=185.140.53.0/24، مع أصل AS201801 والحد الأقصى للطول /24. أرجع حالة صالحة لـ 2a07:1a84::/48 علىhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=2a07:1a84::/48، مع التحقق من صحة ROA عبر 2a07:1a84::/44 وبحد أقصى /48. RPKI لا يبقي الخوادم قيد التشغيل، لكنه يعطي مرشحات المسار طريقة لتمييز إعلانات الأصل المصرح بها من غير المصرح بها. بالنسبة لشبكة صغيرة جديدة، هذه النظافة مهمة.

صورة المزود العلوي مرئية، لكن صورة المرفق ليست كذلك

سجل المزود العلوي أوضح من سجل المرفق. أظهر جيران ASN من RIPEstat علىhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201801جارين ملحوظين: AS57758 و AS63473. تحدد نظرة عامة على AS من RIPEstat AS57758 باسم CBWS Holding B.V. و AS63473 باسم HostHatch, LLC. يسرد عرض whois علىhttps://stat.ripe.net/data/whois/data.json?resource=AS201801أيضًا إدخالات سياسة الاستيراد والتصدير لـ AS20473 و AS63473 و AS57758، بينما أظهرت ملاحظة الجيران العامة AS57758 و AS63473 في وقت الفحص. AS20473 هو The Constant Company, LLC في نظرة عامة على AS من RIPEstat، المرتبط عادةً بـ Vultr في اسم AS.

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

يُعمق PeeringDB هذا الحذر. يسجل سجل شبكة Zerospace Cloud علىhttps://www.peeringdb.com/api/net?asn=201801AS201801، موقع الويبhttps://zerospace.cloud، IRR as-set AS201801:AS-ZEROSPACE-CLOUD، بادئة IPv4 واحدة، ستة عشر بادئة IPv6، policy_general Open، حالة ok، طابع زمني للإنشاء في أكتوبر 2022 وطابع زمني للتحديث في 8 فبراير 2026. لكن نقطة نهاية LAN التبادل في PeeringDB علىhttps://www.peeringdb.com/api/netixlan?asn=201801أرجع عدم وجود صفوف LAN تبادل عامة، ونقطة نهاية المرفق علىhttps://www.peeringdb.com/api/netfac?net_id=31374أرجع عدم وجود صفوف مرفق عامة. PeeringDB يُدار بواسطة المشغلين ويمكن أن يكون غير مكتمل، لذا قائمة المرافق الفارغة ليست دليلاً على عدم وجود مرفق. إنها دليل على أن دليل المرفق العام غائب.

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

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

يصف الجيوفيد تسميات المدن، وليس البنية التحتية المحلية المضمونة

الجيوفيد علىhttps://download.zerospace.cloud/ipam/geofeed.csvهو واحد من أكثر القطع الأثرية العامة إفادة في سجل Zerospace. يعين 185.140.53.0/29 إلى أمستردام، 185.140.53.8/29 إلى لندن، 185.140.53.16/29 إلى ستوكهولم، 185.140.53.24/29 إلى سيول، 185.140.53.32/29 إلى سنغافورة، 185.140.53.40/29 إلى هونغ كونغ، /32s محددة في 185.140.53.48 إلى 185.140.53.55 إلى طوكيو، 185.140.53.56/29 إلى سيدني، 185.140.53.64/29 إلى نيويورك و 185.140.53.72/29 إلى لوس أنجلوس. يعين /48 IPv6 إلى نفس نمط المدينة: 2a07:1a84::/48 إلى أمستردام،:1::/48 إلى لندن،:2::/48 إلى ستوكهولم،:3::/48 إلى سيول،:4::/48 إلى سنغافورة،:5::/48 إلى هونغ كونغ،:6::/48 إلى طوكيو،:7::/48 إلى سيدني،:8::/48 إلى نيويورك و:9::/48 إلى لوس أنجلوس.

هذه إشارة منطقة خدمة عالمية، وليس دليل قدرة عالمية. على IPv4، معظم إدخالات المدينة هي /29s، مما يعني ثمانية عناوين لكل منها. إدخالات IPv4 في طوكيو هي /32s فردية أو مجموعات صغيرة جدًا، ولا يغطي الجيوفيد كل عنوان في /24 باسم مدينة صريح. أظهرت الجغرافيا من RIPEstat علىhttps://stat.ripe.net/data/geoloc/data.json?resource=185.140.53.0/24وعرض MaxMind GeoLite علىhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=185.140.53.0/24انتشارًا مشابهًا، لكنه أظهر أيضًا حصة كبيرة من /24 IPv4 كالسويد بدون مدينة في العرض المطلوب. هذا يعني أن صورة الموقع العام مختلطة: بعض شرائح العناوين لها تسميات مدينة دقيقة؛ الكثير من مساحة عناوين IPv4 لا تظهر كخريطة حوسبة مفصلة مدينة بمدينة.

عرض موقع IPv6 يحتاج أيضًا إلى قراءة دقيقة. أظهرت الجغرافيا من RIPEstat لـhttps://stat.ripe.net/data/geoloc/data.json?resource=2a07:1a84::/44وعرض MaxMind GeoLite علىhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=2a07:1a84::/44أن /44 مقسم عبر عدة /48 مسماة بمدن، مع حصة كبيرة من التجميع تظهر كالسويد بدون مدينة. يسرد الجيوفيد:7::/48 لسيدني و:8::/48 لنيويورك، بينما لم تُظهر نقطة نهاية البادئات المعلن عنها تلك /48 بين البادئات الثمانية المرئية خلال فترة المراجعة هذه. ليس هذا بالضرورة تناقضًا؛ يمكن لإدخالات الجيوفيد وصف محلية مقصودة أو مسجلة بينما تتغير رؤية التوجيه بمرور الوقت. إنه تذكير بأن ادعاءات المحلية يجب أن تكون مرتبطة بحالة المسار الحالية.

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

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

يكشف موقع الويب وسجل DNS عن تبعية توفر منفصلة

الموقع الرئيسي يحتاج أيضًا إلى أن يبقى منفصلاً عن بنية العميل التحتية. أظهرت نقطة نهاية سلسلة DNS من RIPEstat علىhttps://stat.ripe.net/data/dns-chain/data.json?resource=zerospace.cloudأن zerospace.cloud يستخدم خوادم أسماء موثوقة من Cloudflare، ali.ns.cloudflare.com و rudy.ns.cloudflare.com، مع سجلات A 172.67.142.47 و 104.21.87.70 وسجلات AAAA 2606:4700:3035::ac43:8e2f و 2606:4700:3036::6815:5746 في وقت استعلام 15 يوليو 2026. أظهرت نقطة نهاية سلسلة DNS لـhttps://stat.ripe.net/data/dns-chain/data.json?resource=download.zerospace.cloudنفس العناوين الموجهة عبر Cloudflare لمضيف التنزيل. أرجع نقطة النهاية لـhttps://stat.ripe.net/data/dns-chain/data.json?resource=www.zerospace.cloudخوادم أسماء Cloudflare الموثوقة لكن لا توجد سجلات أمامية لـwww.zerospace.cloud.

أثناء فحص HTTPS المباشر في 15 يوليو 2026، لم يُرجعhttps://zerospace.cloudصفحة قابلة للاستخدام خلال مهلة 15 ثانية من هذا البيئة. يمكن أن تظهر فحوصات Cloudflare السابقة أخطاء 522 لعدم الوصول إلى الأصل عندما لا يستجيب الأصل لـ Cloudflare. حتى بدون الاعتماد على أي نتيجة HTTP عابرة، يظهر دليل DNS أن مسار موقع الويب العام بوساطة Cloudflare. هذا شائع وغالبًا معقول. وهذا يعني أيضًا أن توفر موقع الويب ليس نفس توفر مسار AS201801.

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

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

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

التبعيات المادية مخفية في الغالب خلف طبقة الشبكة

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

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

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

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

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

مسارات الفشل: المسار، المزود العلوي، المرفق، الدعم والترحيل

مسار الفشل الأول هو قابلية الوصول العلوية. كان لدى AS201801 جاران ملحوظان في RIPEstat، AS57758 و AS63473، وقائمة سياسات whois التي سميت أيضًا AS20473. إذا فقدت AS57758 أو AS63473 جلسة، تعتمد النتيجة على ما إذا كان كلا الجارين يحملان البادئات المتأثرة، وما إذا كانت هندسة حركة المرور متماثلة بما يكفي لمسارات العودة، وما إذا كان الخطأ معزولاً في مزود علوي واحد. إذا انتهت كلتا الجلستين في نفس الموقع أو تعتمدان على نفس التسليم المحلي، فقد يكون التكرار أقل فائدة مما يشير إليه عدد AS. يجب على العملاء طلب مخطط توجيه يظهر أي مزود علوي يحمل كل بادئة إنتاجية وأين تعيش هذه الجلسات.

مسار الفشل الثاني هو ترخيص المسار أو التصفية. RPKI صالح لـ /24 IPv4 ونمط /44-to-/48 IPv6، وهو أمر جيد. لكن يجب على العملاء أن يسألوا عما إذا كانت Zerospace تراقب تسربات المسار أو الإعلانات غير الصالحة أو أخطاء الحد الأقصى للطول أو انحراف الموقع. يمكن أن يصبح ROA الصالح مؤلمًا تشغيليًا إذا أعلن المزود لاحقًا عن مسار أكثر تحديدًا يتجاوز الحد الأقصى للطول، أو إذا قام مزود علوي بالتصفية بشكل غير متوقع، أو إذا تمت إضافة /48 خاص بمدينة بدون ترخيص مسار مطابق. حالة RPKI الحالية هي عنصر تحكم إيجابي؛ إنها ليست بديلاً عن التحكم في التغيير.

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

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

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

السعة المثبتة والسعة القابلة للاستخدام والسعة المشتراة هي أشياء مختلفة

دليل Zerospace هو مثال مفيد على سبب وجود ثلاث طبقات لسعة السحابة. السعة المثبتة هي ما يمكن للمزود أن يدعي بشكل معقول أنه يمتلك أو يسيطر عليه: AS201801، 185.140.53.0/24، 2a07:1a84::/44، سياسة المسار المسجلة وملف PeeringDB. سعة الشبكة القابلة للاستخدام هي ما يظهر في التوجيه العام ويمكن الوصول إليه بترخيص أصل صالح: /24 IPv4 واحد، ثمانية /48 IPv6 مرئية في فترة المراجعة، جاران ملحوظان ورؤية واسعة عبر RIPE RIS. السعة المشتراة هي ما يمكن للعميل استهلاكه فعليًا بموجب العقد، مع شروط الحوسبة والتخزين وعرض النطاق والدعم والترحيل المرفقة.

المسافة بين هذه الطبقات هي حيث يختبئ الخطر. قد يرى العميل عشر مدن في الجيوفيد ويفترض عشر مناطق إنتاجية. الأدلة لا تدعم هذا الافتراض. قد يرى العميل ستة عشر بادئة IPv6 في PeeringDB ويفترض أن جميعها حية. أظهر RIPEstat ثمانية /48 مرئية خلال هذه النافذة، مع بعض /48 المدرجة في whois غير موجودة في BGP. قد يرى العميل جارين علويين ملحوظين ويفترض تكرار المسار. هذا صحيح فقط إذا كان الجاران مستقلين لبادئات العميل ومجال الفشل. قد يرى العميل RPKI صالحًا ويفترض المرونة التشغيلية. يساعد RPKI في أصالة المسار، وليس إصلاح الخادم.

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

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

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

محلية البيانات معلنة عبر الجيوفيد، لكن المحلية القانونية والتشغيلية لا تزال مفتوحة

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

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

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

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

من يتأثر إذا فشلت الخدمة

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

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

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

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

ما من شأنه رفع درجة الأدلة

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

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

يجب أن يظل RPKI نقطة قوة. Zerospace لديها بالفعل ترخيص مصدر مسار صالح لمسارات IPv4 و IPv6 التي تمت مراجعتها. يجب أن تحافظ الأدلة العامة المستقبلية على هذا الانضباط مع ظهور /48 جديدة. إذا كان من المفترض أن تصبح:7::/48 و:8::/48 مواقع مدينة حية، يجب أن تتماشى رؤية المسار والتحقق مع الجيوفيد. إذا كانت بعض إدخالات الجيوفيد محجوزة أو مخططة، يجب على المزود أن يقول ذلك بدلاً من ترك العملاء يستنتجون محلية الإنتاج من ملف موقع عنوان.

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

الخلاصة للمشغلين المعتمدين

لدى Zerospace Cloud أدلة عامة كافية لتعامل كشبكة موجهة حقيقية، وليس كافية لتعامل كمنصة استضافة عالمية مثبتة. تربط سجلات RIPE AS201801 و 185.140.53.0/24 و 2a07:1a84::/44 بـ Christian Wittenberg المتداول باسم Zerospace Cloud. يظهر RIPEstat أن الـ AS معلن عنه برؤية واسعة لـ IPv4 و IPv6. RPKI صالح للأصول IPv4 و IPv6 التي تمت مراجعتها. يسرد PeeringDB كائن شبكة Zerospace Cloud. الجيوفيد مفصل وحالي بما يكفي لدعم أسئلة جادة حول تصميم الخدمة الجغرافي.

الحذر واضح بنفس القدر. حوزة IPv4 هي /24 واحد. تغطي رؤية IPv6 ثمانية /48 في فترة المراجعة، وليس كل /48 التي يوحي بها /44 والملف الشخصي. لا يظهر PeeringDB أي صفوف مرفق عامة أو نقاط تبادل. لم يكن الموقع الرئيسي مصدرًا موثوقًا لتفاصيل الخدمة أثناء الفحص. الجيوفيد يعين مدناً، لكنه لا يثبت وجود رفوف أو طاقة أو تبريد أو أجهزة أو دعم أو قدرة ترحيل في تلك المدن. صورة المزود العلوي الحالية تظهر جارين ملحوظين، لكن بيانات التوجيه العامة لا تثبت مجالات فشل مستقلة.

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

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