استكشاف أخطاء الاتصال داخل VPC

خادم تطبيق في subnet خاصة يعجز عن فتح اتصال بـ RDS في الـ VPC نفسه. قاعدة البيانات تعمل، وبيانات الاعتماد لم تتغيّر، والاتصال ينتهي بمهلة فقط. أمامك أربعة متّهمين وبلا دليل: مجموعة أمان، وقائمة network ACL، وroute table، واحتمال أن قاعدة البيانات لا تستمع أصلاً.

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

للمسار ترتيب، فليكن لك مثله

الطرد المغادر لـ instance في EC2 يمرّ بسلسلة ثابتة من البوّابات. كل واحدة منها تستطيع منعه، وكل منع يبدو من التطبيق متطابقاً مع غيره: انتهاء مهلة. فاعمل على السلسلة لا على حدسك.

1. مجموعة أمان المصدر، خروجاً. هل تسمح قاعدة خروج بعنوان الوجهة ومنفذها؟ المجموعات الافتراضية تسمح بكل الخروج، فلا تصير هذه متّهماً إلا في بيئة مقفلة. وحين تكون هي السبب فلأن أحدهم استبدل قاعدة الخروج الافتراضية ونسي منفذاً.
2. قائمة network ACL للـ subnet المصدر، خروجاً. هل تسمح قاعدة خروج بالطلب، وهل تسمح قاعدة دخول بالجواب على المنافذ العابرة؟ هذه القوائم عديمة الحالة، فالاتجاهان سؤالان منفصلان.
3. ‏route table المصدر. هل يوجد مسار يحتوي نطاق وجهته عنوان الهدف، وهل هدف ذلك المسار موجود ويعمل؟ غياب المسار يعني إسقاط الطرد قبل استشارة أي جدار.
4. الوسيط. ‏NAT gateway أو internet gateway أو VPC endpoint أو اتصال peering أو transit gateway. ولكلٍّ أعطاله الخاصة، وقد غطّتها المواضيع السابقة في هذا المجال.
5. قائمة network ACL للـ subnet الوجهة، دخولاً. السؤالان عديما الحالة نفساهما من الجهة البعيدة.
6. مجموعة أمان الوجهة، دخولاً. هل تسمح قاعدة دخول بالمصدر، سواء بنطاق عناوين أو بالإشارة إلى مجموعة أمان المصدر؟
7. سياسة المورد. سياسة endpoint، أو سياسة bucket في S3، أو سياسة على جهة الخدمة، قد ترفض طلباً وصلت طروده على أكمل وجه. وهذه تنتج خطأً لا انتهاء مهلة، وتلك إشارة نافعة وحدها.

ثم امشِ على مسار العودة. يبدو ذلك شكلياً حتى تلقى العطل الذي يمسكه: الطلب مقبول، والوجهة تجيب، والجواب يُمنَع بقاعدة خروج في network ACL لم يفكّر فيها أحد لأن التطبيق لا يبدأ الاتصال إلا في اتجاه واحد.

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

اقرأ العَرَض قبل أن تقرأ الإعدادات

ثلاثة من الأعطال أعلاه تنتج أعراضاً قابلة للتمييز إن نظرت إلى الشيء الصحيح.

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

‏Reachability Analyzer يقرأ المسار كله عنك

المشي على سبع بوّابات يدوياً عبر حسابين يستهلك وقتاً حقيقياً. وReachability Analyzer يفعل ذلك في نداء واحد.

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

أنت تعرّف path: مصدراً ووجهة، واختيارياً بروتوكولاً ومنفذ وجهة ومكوّنات وسيطة تُضمّن أو تُستثنى. ثم تشغّل analysis على ذلك المسار. والمصادر والوجهات المدعومة هي instances في EC2، وinternet gateways، وواجهات الشبكة، وtransit gateways وارتباطاتها، وvirtual private gateways، وخدمات VPC endpoint، وVPC endpoints، واتصالات peering، إضافةً إلى عنوان IP مجرّد كوجهة.

# 1. عرّف المسار مرة واحدة
aws ec2 create-network-insights-path \
  --source i-0a1b2c3d4e5f67890 \
  --destination i-09876fedcba543210 \
  --destination-port 3306 \
  --protocol tcp

# 2. شغّل تحليلاً عليه، كلما شئت
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc123def456789a

# 3. اقرأ الحكم والتفسيرات
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-0abc123def456789a \
  --query 'NetworkInsightsAnalyses[0].[NetworkPathFound,Explanations]'

وثلاث حقائق تشغيلية عنه تستحقّ الحمل:

• تُحاسَب على كل تشغيل تحليل لا على المسار، فكائن المسار مجاني الاحتفاظ به وإعادة تشغيله بعد كل تغيير. وهذا ما يجعله فحص انحدار لا أداة حوادث فقط.
• يجب أن يكون المصدر والوجهة في المنطقة نفسها، وفي الـ VPC نفسها أو في شبكتين مرتبطتين بـ peering أو بـ transit gateway. وقد يكونان في حسابين مختلفين داخل المؤسّسة نفسها في AWS Organizations إن فعّلت الوصول الموثوق.
• تُحذَف التحليلات تلقائياً بعد 120 يوماً من إنشائها. فإن كانت النتيجة دليلاً لتدقيق، صدّرها.

رموز التفسير تسمّي المكوّن المذنب

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

ورمزان من هذه يعلّمان أكثر من رسالتهما. فـ MORE_SPECIFIC_ROUTE هو درس التوجيه معاد صياغته كتشخيص: مسارك موجود وسليم وغير مستخدَم، لأن شيئاً أطول طابق قبله. وTGW_ATTACH_MISSING_TGW_RTB_ASSOCIATION هو تمييز الاقتران عن النشر من درس transit gateway وقد ظهر عطلاً ملموساً، لأن ارتباطاً ينشر مساراته ولا يقترن بشيء بلا route table يستشيره.

أين يتوقّف النموذج وتبدأ الطرود

‏Reachability Analyzer فاحص إعدادات، فهو أعمى عن كل ما ليس إعداداً. ومعرفة نقاطه العمياء هي ما يمنع نتيجة خضراء من تضليلك.

• لا يأخذ في حسبانه صحّة الأهداف المسجّلة. فموازن حمل تفشل كل أهدافه في فحوصات الصحّة سيُحلَّل على أنه قابل للوصول.
• لا يدعم إلا IPv4. فإن حمل المورد عائلتَي العناوين، لم تُحلَّل إلا جهة IPv4. والعطل الخاص بـ IPv6 يظهر بالرمز NO_PATH.
• بلا رؤية لـ DNS. فإن حلّ تطبيقك اسماً إلى العنوان الخطأ، بقي المسار إلى العنوان الصحيح قابلاً للوصول تماماً.
• يتوقّف عند ارتباطات Connect في transit gateway، والمسارات العابرة لـ endpoint من نوع Gateway Load Balancer تستثني موازن الحمل وأهدافه، وهي تحتاج تحليلاً خاصاً بها.
• دعم Network Firewall جزئي. فهو يعالج قواعد الخماسي stateful وstateless، لا قوائم النطاقات ولا قواعد Suricata ولا خيارات القواعد ولا مجموعات الموارد بالوسوم، ويقول ذلك في تفاصيل المسار حين يلقاه.
• لا يقول شيئاً عن التطبيق. عملية تستمع، ومصافحة TLS، وقاعدة بيانات ترفض بيانات الاعتماد: كل ذلك خارج النموذج.

فالقاعدة الصادقة هي: ‏Reachability Analyzer يثبت أن المسار مسموح، لا أن النداء سينجح. فحين يقول غير قابل للوصول، صار عندك الجواب وتستطيع التوقّف. وحين يقول قابلاً للوصول ويظلّ التطبيق فاشلاً، تكون قد تعلّمت شيئاً ثميناً أيضاً، وهو أن المشكلة فوق طبقة الشبكة، وسجلات الدرس التالي هي وجهتك.

أعطال ليست أعطال شبكة أصلاً

أربعة أسباب تفسّر حصّة كبيرة من التذاكر التي تصل بعنوان «اتصال VPC» ولا تلمس مجموعة أمان إطلاقاً.

‏DNS يحلّ إلى الشيء الخطأ. فـ private hosted zone تحتاج enableDnsSupport وenableDnsHostnames على الـ VPC كي تكون قابلة للاستخدام، وinterface endpoint معطَّل عليه private DNS يترك اسم الخدمة العام يُحَلّ إلى عنوان عام لا تستطيع subnet خاصة بلوغه. فيفشل الاتصال عند طبقة الشبكة، والإصلاح إعداد DNS.

‏Path MTU. اتصال يُفتح نظيفاً ثم يتوقّف لحظة بدء حمولة كبيرة لا يكون مشكلة صلاحيات تقريباً أبداً. فالمصافحات صغيرة وتتّسع في أي مكان. والأنفاق تقلّص حجم الطرد القابل للاستخدام، وإن أسقط جدار ناري رسائل ICMP التي تطلب التجزئة، عجز اكتشاف MTU للمسار عن إخبار المرسِل بإرسال طرود أصغر، فيتجمّد النقل ببساطة. افحص MTU قبل القواعد كلما اعتمد العَرَض على الحجم.

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

المنافذ العابرة على network ACL عديمة الحالة. غُطّيت كاملةً في درس مجموعات الأمان، وتعود هنا لأنها أشيع سبب منفرد لسماح network ACL بالطلب وقتل الجواب. فإن كانت الحركة صادرة ولم تسمح قواعد الدخول في network ACL بعودة المدى 1024 إلى 65535، لم يعمل شيء وقرأت كل قاعدة على أنها معقولة.

نصائح الاختبار

• مشي مرتّب، في كل مرة. مجموعة أمان المصدر، ثم network ACL المصدر، ثم route table، ثم الوسيط، ثم network ACL الوجهة، ثم مجموعة أمان الوجهة، ثم سياسة المورد، ثم مسار العودة. وأسئلة السيناريو تُبنى بكسر واحد من هذه بالضبط.
• «رفض الاتصال» ليس مشكلة شبكة. انتهاء المهلة يعني الإسقاط، والرفض يعني التسليم. والسؤال الذي يقول إن العميل يتلقّى رفضاً فورياً يشير إلى الخدمة لا إلى الـ VPC.
• ‏Reachability Analyzer يحلّل الإعدادات لا الطرود. فحين يسأل السؤال كيف تجد المكوّن المانع بلا توليد حركة وبلا تغيير شيء، فهو الجواب. وحين يسأل عمّا وقع فعلاً لحركة حقيقية، فالجواب سجلات التدفّق.
• ‏Reachability Analyzer لـ IPv4 فقط، وفي المنطقة نفسها، ويتجاهل صحّة الأهداف. وهذه القيود الثلاثة أرجح ما يختبره سؤال عنه.
• ‏MORE_SPECIFIC_ROUTE وNO_ROUTE_TO_DESTINATION توجيه، وSUBNET_ACL_RESTRICTION قائمة network ACL، وENI_SG_RULES_MISMATCH مجموعة أمان. والقدرة على ربط الرمز بالمكوّن تكفي.
• النطاقات المتداخلة لا تُربَط بـ peering، لأن المسار local يفوز دائماً داخل نطاق الـ VPC ولا يمكن تجاوزه.
• جهاز يوجّه مع إسقاط صامت يساوي فحص المصدر والوجهة.
• التوقّف عند عمليات النقل الكبيرة وحدها يساوي MTU لا جدراناً نارية.

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