كشفت شركة ” كلاودفلير” أن طرق بروتوكول بوابة الحدود أو border gateway protocol routes والتي تعرف اختصارًا بـ”BGP” تساعد الشبكات على اختيار أفضل مسار لتوصيل حركة مرور الإنترنت – “تم سحبها من الإنترنت” ، نعرض أدناه المقال الذي شرحت فيه أسباب العطل :
فكرنا لثانية واحدة: “لا يمكن أن يكون فيسبوك معطلًا ، أليس كذلك؟”
اليوم في الساعة 1651 بالتوقيت العالمي، فتحنا حادثة داخلية بعنوان “بحث فيسبوك DNS يعيد SERVFAIL” لأننا كنا قلقين من وجود خطأ ما في محلل DNS 1.1.1.1. ولكن بينما كنا على وشك النشر على صفحة الحالة العامة الخاصة بنا، أدركنا أن شيئًا آخر أكثر خطورة كان يحدث.
سرعان ما ازدحمت وسائل التواصل الاجتماعي ، حيث أبلغت عما أكده مهندسونا بسرعة أيضًا. في الواقع ، كان فيسبوك والخدمات التابعة له واتسآب و إنستغرام كلها معطلة. توقف حل أسماء DNS الخاصة بهم ، ولم يكن من الممكن الوصول إلى عناوين IP الخاصة بالبنية التحتية الخاصة بهم. كان الأمر كما لو أن شخصًا ما “سحب الكابلات” من مراكز البيانات الخاصة به دفعة واحدة وفصلها عن الإنترنت.
كيف هذا ممكن حتى؟
تعرّف على BGP
يرمز BGP إلى بروتوكول بوابة الحدود. إنها آلية لتبادل معلومات التوجيه بين الأنظمة المستقلة (AS) على الإنترنت. تحتوي أجهزة التوجيه الكبيرة التي تجعل الإنترنت تعمل على قوائم ضخمة ومحدثة باستمرار للطرق المحتملة التي يمكن استخدامها لتوصيل كل حزمة شبكة إلى وجهاتها النهائية. بدون BGP ، لن تعرف أجهزة توجيه الإنترنت ما يجب القيام به ، ولن يعمل الإنترنت.
الإنترنت عبارة عن شبكة من الشبكات حرفيًا، وهي مرتبطة ببعضها بواسطة BGP. يسمح BGP لشبكة واحدة (مثل فيسبوك) بالإعلان عن وجودها للشبكات الأخرى التي تشكل الإنترنت. نظرًا لأننا نكتب أن فيسبوك لا يعلن عن وجوده، لا يمكن لمزودي خدمة الإنترنت والشبكات الأخرى العثور على شبكة فيسبوك وبالتالي فهي غير متوفرة.
تحتوي كل الشبكات الفردية على ASN: رقم نظام مستقل. النظام الذاتي (AS) هو شبكة فردية ذات سياسة توجيه داخلية موحدة. يمكن أن ينشئ AS البادئات (لنفترض أنها تتحكم في مجموعة من عناوين IP) ، بالإضافة إلى بادئات النقل (لنفترض أنهم يعرفون كيفية الوصول إلى مجموعات معينة من عناوين IP).
ASN الخاص بـ Cloudflare هو AS13335. يحتاج كل ASN إلى الإعلان عن مسارات البادئة الخاصة به إلى الإنترنت باستخدام BGP ؛ خلاف ذلك ، لن يعرف أحد كيفية الاتصال وأين يجدنا.
يقدم مركز التعلم الخاص بنا نظرة عامة جيدة على ماهية BGP و ASNs وكيفية عملها.
في هذا الرسم التخطيطي المبسط ، يمكنك رؤية ستة أنظمة مستقلة على الإنترنت وطريقان محتملان يمكن أن تستخدمهما حزمة واحدة للانتقال من البداية إلى النهاية. AS1 → AS2 → AS3 هو الأسرع ، و AS1 → AS6 → AS5 → AS4 → AS3 هو الأبطأ ، ولكن يمكن استخدام ذلك إذا فشلت الأولى.
في 1658 بالتوقيت العالمي ، لاحظنا أن فيسبوك قد توقف عن الإعلان عن المسارات إلى بادئات DNS الخاصة بهم. وهذا يعني ، على الأقل ، أن خوادم DNS الخاصة بـ فيسبوك لم تكن متاحة. بسبب 1.1.1.1 لمحلل DNS الخاص بـ Cloudflare لم يعد بإمكانه الرد على الاستفسارات التي تطلب عنوان IP الخاص بـ facebook.com أو instagram.com.
route-views>show ip bgp 185.89.218.0/23
% Network not in table
route-views>
route-views>show ip bgp 129.134.30.0/23
% Network not in table
route-views>
وفي الوقت نفسه ، ظلت عناوين IP الأخرى على فيسبوك موجهة ولكنها لم تكن مفيدة بشكل خاص لأنه بدون DNS ، لم يكن فيسبوك والخدمات ذات الصلة متاحة فعليًا:
route-views>show ip bgp 129.134.30.0
BGP routing table entry for 129.134.0.0/17, version 1025798334
Paths: (24 available, best #14, table default)
Not advertised to any peer
Refresh Epoch 2
3303 6453 32934
217.192.89.50 from 217.192.89.50 (138.187.128.158)
Origin IGP, localpref 100, valid, external
Community: 3303:1004 3303:1006 3303:3075 6453:3000 6453:3400 6453:3402
path 7FE1408ED9C8 RPKI State not found
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
route-views>
نحن نتتبع جميع تحديثات وإعلانات BGP التي نراها في شبكتنا العالمية. على نطاقنا ، تعطينا البيانات التي نجمعها نظرة على كيفية اتصال الإنترنت والمكان المقصود من تدفق حركة المرور من وإلى كل مكان على هذا الكوكب.
تُعلم رسالة BGP UPDATE الموجّه بأي تغييرات أجريتها على إعلان البادئة أو تسحب البادئة تمامًا. يمكننا أن نرى هذا بوضوح في عدد التحديثات التي تلقيناها من فيسبوك عند التحقق من قاعدة بيانات BGP المتسلسلة الزمنية. عادةً ما يكون هذا المخطط هادئًا إلى حد ما: لا يُجري فيسبوك الكثير من التغييرات على شبكته من دقيقة إلى دقيقة.
ولكن في حوالي الساعة 15:40 بالتوقيت العالمي ، رأينا ذروة تغييرات التوجيه من فيسبوك. وذلك عندما بدأت المشكلة.
إذا قمنا بتقسيم طريقة العرض هذه عن طريق إعلانات الطرق وعمليات السحب ، فإننا نحصل على فكرة أفضل عما حدث. تم سحب المسارات ، وانقطع اتصال خوادم DNS الخاصة بـ فيسبوك ، وبعد دقيقة واحدة من حدوث المشكلة ، كان مهندسو Cloudflare في غرفة يتساءلون لماذا لم يتمكن 1.1.1.1 من حل facebook.com ويقلقون من أنه كان خطأً بطريقة ما في أنظمتنا.
مع عمليات السحب هذه ، انفصل فيسبوك ومواقعه فعليًا عن الإنترنت.
يتأثر DNS
كنتيجة مباشرة لذلك ، توقف محللو DNS في جميع أنحاء العالم عن حل أسماء النطاقات الخاصة بهم.
➜ ~ dig @1.1.1.1 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @1.1.1.1 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
➜ ~ dig @8.8.8.8 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @8.8.8.8 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
يحدث هذا لأن DNS ، مثل العديد من الأنظمة الأخرى على الإنترنت ، لديه أيضًا آلية التوجيه الخاصة به. عندما يكتب شخص ما عنوان URL https://facebook.com في المتصفح ، فإن محلل DNS ، المسؤول عن ترجمة أسماء النطاقات إلى عناوين IP فعلية للاتصال بها ، يتحقق أولًا مما إذا كان يحتوي على شيء ما في ذاكرة التخزين المؤقت الخاصة به ويستخدمه. إذا لم يكن الأمر كذلك ، فإنه يحاول الحصول على الإجابة من خوادم أسماء النطاقات ، التي يستضيفها عادةً الكيان الذي يمتلكها.
إذا تعذر الوصول إلى خوادم الأسماء أو فشلت في الاستجابة لسبب آخر ، فسيتم إرجاع SERVFAIL ، ويصدر المتصفح خطأ للمستخدم.
مرة أخرى ، يقدم مركز التعلم الخاص بنا شرحًا جيدًا لكيفية عمل DNS.
بسبب توقف فيسبوك عن الإعلان عن مسارات بادئة DNS الخاصة بهم من خلال BGP ، لم يكن لدى محللي DNS الخاصين بنا وأي شخص آخر طريقة للاتصال بخوادم الأسماء الخاصة بهم. وبالتالي ، فإن 1.1.1.1 و 8.8.8.8 ومحللي DNS الرئيسيين الآخرين بدأوا في إصدار (والتخزين المؤقت) استجابات SERVFAIL.
لكن هذا ليس كل شيء. الآن يبدأ السلوك البشري ومنطق التطبيق ويسبب تأثيرًا أسيًا آخر. يتبع تسونامي حركة مرور DNS إضافية.
حدث هذا جزئيًا لأن التطبيقات لن تقبل خطأ للحصول على إجابة وتبدأ في إعادة المحاولة ، أحيانًا بقوة ، وجزئيًا لأن المستخدمين النهائيين لن يأخذوا أي خطأ للحصول على إجابة ويبدأون في إعادة تحميل الصفحات ، أو قتلها وإعادة تشغيلها التطبيقات ، أحيانًا بقوة أيضًا.
هذه هي الزيادة في حركة المرور (في عدد الطلبات) التي رأيناها في 1.1.1.1:
لذلك الآن ، نظرًا لأن فيسبوك ومواقعهم كبيرة جدًا ، لدينا محلل DNS في جميع أنحاء العالم يتعاملون مع استعلامات أكثر من المعتاد بمقدار 30 ضعفًا ومن المحتمل أن يتسببوا في حدوث مشكلات تتعلق بزمن الانتقال وانتهاء المهلة للأنظمة الأساسية الأخرى.
لحسن الحظ ، تم تصميم 1.1.1.1 ليكون مجانيًا وخاصًا وسريعًا (كما يمكن أن يشهد مراقب DNS المستقل DNSPerf) وقابل للتطوير ، وتمكنا من الاستمرار في خدمة مستخدمينا بأقل قدر من التأثير.
استمرت الغالبية العظمى من طلبات DNS في الحل في أقل من 10 مللي ثانية. في الوقت نفسه ، شهد جزء ضئيل من النسب المئوية p95 و p99 أوقات استجابة متزايدة ، وربما يرجع ذلك إلى انتهاء صلاحية TTLs التي اضطرت إلى اللجوء إلى خوادم أسماء فيسبوك ووقت انتهاء المهلة. إن حد مهلة DNS البالغ 10 ثوانٍ معروف جيدًا بين المهندسين.
التأثير على الخدمات الأخرى
يبحث الأشخاص عن بدائل ويريدون معرفة المزيد أو مناقشة ما يجري. عندما أصبح فيسبوك غير قابل للوصول ، بدأنا في رؤية استعلامات DNS متزايدة إلى Twitter و Signal وأنظمة المراسلة والوسائط الاجتماعية الأخرى.
يمكننا أيضًا أن نرى تأثيرًا جانبيًا آخر لعدم إمكانية الوصول في حركة مرور WARP الخاصة بنا من وإلى ASN 32934 المتأثر على فيسبوك. اختفت حركة WARP من وإلى شبكة فيسبوك في جميع أنحاء العالم.
الإنترنت
تمثل أحداث اليوم تذكيرًا لطيفًا بأن الإنترنت نظام معقد للغاية ومترابط يضم ملايين الأنظمة والبروتوكولات التي تعمل معًا. هذه الثقة والتوحيد القياسي والتعاون بين الكيانات هي في صميم جعلها تعمل لما يقرب من خمسة مليارات مستخدم نشط في جميع أنحاء العالم.
تحديث
في حوالي الساعة 21:00 بالتوقيت العالمي ، رأينا نشاط BGP متجددًا من شبكة فيسبوك والذي بلغ ذروته في الساعة 21:17 بالتوقيت العالمي.
مما لا شك فيه أن خدمات فيسبوك و واتسآب و إنستغرام ستستغرق المزيد من الوقت لتظهر على الإنترنت ولكن اعتبارًا من الساعة 21:28 UTC ، يبدو أن فيسبوك قد أعيد الاتصال بالإنترنت العالمي و DNS يعملان مرة أخرى.
مصدر المقال: اضغط هنا
