انتقل إلى المحتوى الرئيسي

مختبر: سيناريوهات استكشاف الأخطاء وإصلاحها في EC2

أهداف المختبر​

هذا المختبر يضعك أمام سيناريوهات أعطال واقعية. لكل سيناريو، يجب عليك:

  • تحليل الأعراض
  • صياغة الفرضيات
  • اقتراح اختبارات تشخيصية
  • تحديد الحل
تمرين نظري

هذا المختبر هو تمرين تحليلي. لا حاجة للوصول إلى AWS - اعمل على الورق أو الوثيقة.

المدة المقدرة​

من 1.5 إلى 2 ساعة

السيناريو 1: الموقع الإلكتروني غير متاح​

السياق​

الوضع:
- تم إطلاق مثيل EC2 منذ ساعة
- AMI: Amazon Linux 2023
- النوع: t3.micro
- تم تثبيت Apache وتشغيله
- يمكنك الاتصال عبر SSH
- لكن http://52.1.2.3 لا يستجيب (انتهاء المهلة)

التكوين الحالي:
- VPC: vpc-default
- الشبكة الفرعية: عامة (مع IGW)
- مجموعة الأمان: sg-web

المعلومات المتاحة​

حالة المثيل: يعمل
فحوصات الحالة: 2/2 ناجحة

مجموعة الأمان sg-web:
قواعد الوارد:
- SSH (22): 0.0.0.0/0
- HTTP (80): 10.0.0.0/8

قواعد الصادر:
- كل الحركة: 0.0.0.0/0

الأسئلة​

  1. ما هو العرض الدقيق؟

  2. اذكر 3 فرضيات بترتيب الاحتمالية

  3. ما هو السبب الأكثر احتمالاً؟

  4. ما هي الأمر/الإجراء الذي يصحح المشكلة؟

  5. كيف تتحقق من أن المشكلة قد حُلت؟

📋 عرض الحل

1. العرض: انتهاء مهلة HTTP نحو 52.1.2.3 المنفذ 80، بينما يعمل SSH.

2. الفرضيات:

  1. مجموعة الأمان لا تسمح بـ HTTP من الإنترنت (عالية)
  2. Apache لا يستمع على المنفذ الصحيح (متوسطة)
  3. جدار الحماية iptables على المثيل (منخفضة)

3. السبب: مجموعة الأمان تسمح بـ HTTP (المنفذ 80) فقط من 10.0.0.0/8 (شبكة خاصة)، وليس من الإنترنت (0.0.0.0/0).

4. التصحيح:

aws ec2 authorize-security-group-ingress \
    --group-id sg-web \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

5. التحقق:

curl http://52.1.2.3
# أو
افتح http://52.1.2.3 في متصفح

السيناريو 2: SSH غير ممكن​

السياق​

الوضع:
- تم إطلاق مثيل جديد
- قمت بتنزيل المفتاح .pem
- المثيل: يعمل، فحوصات الحالة OK
- IP العامة: 52.2.3.4

الأمر المنفذ:
$ ssh -i cle.pem ec2-user@52.2.3.4
ssh: connect to host 52.2.3.4 port 22: Connection timed out

المعلومات المتاحة​

تفاصيل المثيل:
- ID: i-0123456789
- الحالة: يعمل
- IP العامة: 52.2.3.4
- الشبكة الفرعية: subnet-abc123 (10.0.2.0/24)
- مجموعة الأمان: sg-default

مجموعة الأمان sg-default:
قواعد الوارد:
- (لا توجد قواعد)

قواعد الصادر:
- كل الحركة: 0.0.0.0/0

الشبكة الفرعية subnet-abc123:
- جدول التوجيه: rtb-main
- التوجيهات:
  - 10.0.0.0/16 → محلي
  - (لا توجد توجيهات أخرى)

الأسئلة​

  1. حدد جميع المشاكل في هذا التكوين

  2. رتبها حسب أولوية التصحيح

  3. اقترح الأوامر لتصحيح كل مشكلة

📋 عرض الحل

1. المشاكل المحددة:

المشكلة أ - مجموعة الأمان: لا توجد قواعد واردة = المنفذ 22 محظور

المشكلة ب - جدول التوجيه: لا توجد توجيه نحو بوابة الإنترنت = لا يوجد وصول للإنترنت

2. الأولوية:

  1. جدول التوجيه (بدون توجيه، حتى مع SG OK، لن يعمل)
  2. مجموعة الأمان

3. التصحيحات:

# 1. إنشاء/إرفاق بوابة إنترنت (إذا لم يتم ذلك)
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-xxx --internet-gateway-id igw-xxx

# 2. إضافة التوجيه نحو IGW
aws ec2 create-route \
    --route-table-id rtb-main \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id igw-xxx

# 3. إضافة قاعدة SSH إلى مجموعة الأمان
aws ec2 authorize-security-group-ingress \
    --group-id sg-default \
    --protocol tcp \
    --port 22 \
    --cidr 0.0.0.0/0

السيناريو 3: المثيل الذي ينتهي فوراً​

السياق​

الوضع:
- تقوم بإطلاق مثيل
- ينتقل من "pending" إلى "running" ثم "terminated"
- كل ذلك في أقل من 30 ثانية
- حاولت 3 مرات، نفس النتيجة

التكوين:
- AMI: ami-custom-xyz (AMI مخصص)
- النوع: t3.large
- المنطقة: us-east-1

المعلومات المتاحة​

وحدة التحكم EC2 → سبب انتقال الحالة:
"Client.VolumeLimitExceeded: Volume limit exceeded"

أحجام EBS الحالية لديك:
- 45 حجم كل منها 100 جيجابايت
- الإجمالي: 4.5 تيرابايت

AMI الخاص بك ami-custom-xyz:
- تم إنشاؤه منذ 6 أشهر
- حجم الجذر: 200 جيجابايت
- يستخدم اللقطة snap-olddata

الأسئلة​

  1. ما هو سبب الإنهاء؟

  2. كيف تتحقق من حدود حسابك؟

  3. ما هي الحلول الممكنة؟ (على الأقل 3)

📋 عرض الحل

1. السبب: الرسالة "Volume limit exceeded" تشير إلى أنك وصلت إلى حصة تخزين EBS لحسابك.

2. التحقق من الحدود:

aws service-quotas get-service-quota \
    --service-code ebs \
    --quota-code L-D18FCD1D

# أو عبر وحدة التحكم:
# Service Quotas → Amazon Elastic Block Store (EBS)

3. الحلول:

الحل أ - حذف الأحجام غير المستخدمة:

# قائمة الأحجام غير المرفقة
aws ec2 describe-volumes \
    --filters "Name=status,Values=available"

# حذف
aws ec2 delete-volume --volume-id vol-xxx

الحل ب - طلب زيادة الحصة:

aws service-quotas request-service-quota-increase \
    --service-code ebs \
    --quota-code L-D18FCD1D \
    --desired-value 10000

الحل ج - استخدام منطقة أخرى: الحصص حسب المنطقة. إطلاق في eu-west-1 على سبيل المثال.

الحل د - استخدام نوع مثيل مع تخزين المثيل: بعض المثيلات لديها تخزين محلي، وليس EBS.

السيناريو 4: قاعدة البيانات غير قابلة للوصول​

السياق​

الهيكلية:
- مثيل ويب (شبكة فرعية عامة): 10.0.1.10
- مثيل قاعدة البيانات (شبكة فرعية خاصة): 10.0.2.20
- كلاهما في نفس VPC

المشكلة:
- من مثيل الويب، لا يمكن الاتصال بـ MySQL
- telnet 10.0.2.20 3306 → انتهاء المهلة

مثيل قاعدة البيانات يعمل:
- فحوصات الحالة OK
- MySQL يعمل (تم التحقق عبر مدير الجلسة)

المعلومات المتاحة​

مجموعة الأمان sg-web (مثيل الويب):
الوارد: HTTP 80، SSH 22
الصادر: كل الحركة 0.0.0.0/0

مجموعة الأمان sg-database (مثيل قاعدة البيانات):
الوارد: MySQL (3306) من 0.0.0.0/0
الصادر: كل الحركة 0.0.0.0/0

NACL للشبكة الفرعية الخاصة (nacl-private):
قواعد الوارد:
  القاعدة 100: DENY TCP 3306 من 0.0.0.0/0
  القاعدة 200: ALLOW ALL من 0.0.0.0/0
قواعد الصادر:
  القاعدة 100: ALLOW ALL إلى 0.0.0.0/0

الأسئلة​

  1. لماذا تفشل الاتصال؟

  2. اشرح لماذا لا تكفي قاعدة مجموعة الأمان

  3. كيف تصحح المشكلة؟

📋 عرض الحل

1. السبب: NACL يحظر المنفذ 3306 بقاعدة DENY (القاعدة 100) التي يتم تقييمها قبل قاعدة ALLOW (القاعدة 200).

2. التفسير:

  • يتم تقييم مجموعات الأمان معًا (جميع القواعد)
  • يتم تقييم NACLs بترتيب أرقام القواعد
  • القاعدة 100 (DENY 3306) يتم تقييمها قبل القاعدة 200 (ALLOW ALL)
  • لذا يتم حظر المنفذ 3306 رغم SG

3. التصحيح: حذف أو تعديل القاعدة 100 من NACL:

# الخيار أ: حذف القاعدة DENY
aws ec2 delete-network-acl-entry \
    --network-acl-id nacl-private \
    --rule-number 100 \
    --ingress

# الخيار ب: تعديل للسماح من الشبكة الفرعية للويب
aws ec2 replace-network-acl-entry \
    --network-acl-id nacl-private \
    --rule-number 100 \
    --protocol tcp \
    --port-range From=3306,To=3306 \
    --cidr-block 10.0.1.0/24 \
    --rule-action allow \
    --ingress

السيناريو 5: رفض الإذن (تحدي)​

السياق​

الوضع:
- مثيل Amazon Linux 2023 تم إطلاقه بمفتاح "ma-cle"
- ملف ma-cle.pem موجود على جهازك
- إذن الملف: 400 (OK)

الأمر:
$ ssh -i ma-cle.pem ec2-user@52.5.6.7
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

الاختبارات المنفذة:
- مجموعة الأمان: المنفذ 22 مفتوح نحو 0.0.0.0/0
- المثيل: يعمل، الحالة OK
- Ping: يعمل

المعلومات الإضافية​

لديك ملفان مفتاح في مجلدك:
- ma-cle.pem (تم إنشاؤه أمس)
- ma-cle.pem.bak (تم إنشاؤه الأسبوع الماضي)

تم إطلاق المثيل الأسبوع الماضي.

الأسئلة​

  1. ما هو السبب المحتمل؟

  2. كيف تتحقق من فرضيتك؟

  3. ما هي الخيارات لاستعادة الوصول؟

📋 عرض الحل

1. السبب المحتمل: أنت تستخدم المفتاح الخاطئ. الملف "ma-cle.pem" الحالي (تم إنشاؤه أمس) ليس المفتاح الذي تم ربطه بالمثيل (تم إطلاقه الأسبوع الماضي).

2. التحقق:

# انظر أي مفتاح مرتبط بالمثيل
aws ec2 describe-instances --instance-ids i-xxx \
    --query 'Reservations[].Instances[].KeyName'

# قارن بصمة مفتاحك
ssh-keygen -l -f ma-cle.pem
ssh-keygen -l -f ma-cle.pem.bak

3. خيارات الاستعادة:

الخيار أ - استخدام المفتاح الصحيح:

ssh -i ma-cle.pem.bak ec2-user@52.5.6.7

الخيار ب - EC2 Instance Connect (إذا كانت AMI متوافقة): وحدة التحكم → المثيل → اتصال → EC2 Instance Connect

الخيار ج - Systems Manager Session Manager: إذا كان وكيل SSM مثبتًا ودور IAM مكونًا.

الخيار د - إنشاء AMI وإعادة الإطلاق:

  1. إنشاء AMI من المثيل
  2. إطلاق مثيل جديد بمفتاح جديد
  3. تركيب حجم المثيل القديم
  4. تعديل ~/.ssh/authorized_keys

مخرجات المختبر​

تقرير استكشاف الأخطاء وإصلاحها (لـ 2 سيناريو من اختيارك)​

لكل سيناريو مختار، وثق:

# السيناريو X: [العنوان]

## 1. العرض المحدد
[وصف دقيق]

## 2. الفرضيات المصاغة
1. [الفرضية 1] - الاحتمالية: عالية/متوسطة/منخفضة
2. [الفرضية 2]
3. [الفرضية 3]

## 3. اختبارات التشخيص
- الاختبار 1: [الأمر/الإجراء] → النتيجة المتوقعة
- الاختبار 2: [الأمر/الإجراء] → النتيجة المتوقعة

## 4. السبب الجذري
[تفسير السبب الحقيقي]

## 5. الحل
[الأوامر أو الإجراءات للتصحيح]

## 6. التحقق
[كيف تتحقق من أن المشكلة قد حُلت]

## 7. الوقاية
[كيف تتجنب هذه المشكلة في المستقبل]

جدول التقييم​

المعيارالنقاط
العرض محدد جيدًا2
فرضيات ذات صلة ومرتبة3
اختبارات التشخيص صحيحة3
السبب الجذري محدد3
الحل صحيح3
التحقق المقترح2
الوضوح والبنية2
المجموع لكل سيناريو18

تهانينا! لقد أكملت مختبر استكشاف الأخطاء وإصلاحها في EC2.