شبكات AWS والهوية

استكشاف أخطاء الشبكة على AWS

18 دقيقة الدرس 9 من 28

استكشاف أخطاء الشبكة على AWS

تكلّف إخفاقات الاتصال في بيئات الإنتاج أموالاً حقيقية. المهندس في شركة تقنية من الدرجة الأولى لا يبدأ بتعديل قواعد مجموعات الأمان عشوائياً — بل يجمع الأدلة بمنهجية، ويستخدم أدوات التشخيص المتخصصة التي تقدمها AWS، ويصيغ فرضية قبل لمس أي مورد. هذا الدرس يعلّمك تلك المنهجية: VPC Flow Logs للتحليل الجنائي للحركة، وVPC Reachability Analyzer لتحليل المسار على مستوى التكوين المنطقي، والنموذج الذهني لفئات إخفاقات الاتصال الخمس الشائعة في AWS.

هرم التشخيص

قبل لمس أي شيء في مستوى التحكم، اجمع البيانات أولاً. تقدم AWS ثلاث طبقات لمراقبة الشبكة:

  • Reachability Analyzer — تحليل المسار المنطقي. يخبرك فوراً إذا كان بإمكان الحزمة الوصول إلى وجهتها بالنظر إلى التكوين الحالي، دون إرسال حركة حقيقية.
  • VPC Flow Logs — أدلة مستوى البيانات الفعلي. تلتقط البيانات الوصفية لكل تدفق مقبول أو مرفوض عبر واجهة شبكية (ENI) أو شبكة فرعية أو VPC بأكمله.
  • CloudWatch Metrics / Network Monitor — إشارات صحة مجمّعة (الحزم المُسقطة، زمن الاستجابة، معدلات الأخطاء).

هذه الأدوات مكملة لبعضها لا بدائل. يخبرك Reachability Analyzer لماذا لا تصل الحركة إلى الهدف بتحليل نموذج التكوين لديك. تخبرك Flow Logs بما اجتازته الحركة فعلياً (أو ما أُسقط منها) على الشبكة. استخدم Analyzer أولاً للتحقق المنطقي السريع؛ وادرس Flow Logs لتأكيد السلوك الواقعي أو للتحقيق في مشاكل متقطعة.

VPC Reachability Analyzer

يُجري Reachability Analyzer اجتياز رمزي حتمياً لرسم بيانات تكوين شبكة AWS لديك. يُنمذج كل مكون VPC — مجموعات الأمان، وقوائم التحكم بالوصول الشبكي (NACLs)، وجداول التوجيه، وبوابات NAT، ومرفقات VPN/TGW، والتناظر (Peering) — ويُعيد إما مسار توجيه مفصلاً بالكامل مع كل نقطة ملابسة، أو شرحاً دقيقاً للمكون الحاجب. لا يضخ حزم اختبارية؛ بل يقرأ حالة مستوى التحكم لديك.

إنشاء مسار باستخدام واجهة سطر الأوامر:

# إنشاء مسار إمكانية وصول: من EC2 instance إلى RDS في نفس VPC aws ec2 create-network-insights-path \ --source i-0abc123456789def0 \ --destination i-0rds456789abc0def \ --protocol TCP \ --destination-port 5432 \ --region us-east-1 # تشغيل التحليل (يُعيد NetworkInsightsAnalysisId) aws ec2 start-network-insights-analysis \ --network-insights-path-id nip-0a1b2c3d4e5f67890 \ --region us-east-1 # انتظر حتى يصبح Status = succeeded aws ec2 describe-network-insights-analyses \ --network-insights-analysis-ids nia-0a1b2c3d4e5f67890 \ --region us-east-1 \ --query 'NetworkInsightsAnalyses[0].{Status:Status,Reachable:NetworkPathFound,Explanations:Explanations}'

عندما تكون NetworkPathFound بقيمة false، يحتوي مصفوفة Explanations على كائن أو أكثر بقيم ExplanationCode مثل SECURITY_GROUP_RULE_BLOCKED أو ROUTE_TABLE_MISSING_ROUTE أو ACL_RULE_BLOCKED. كل كائن يُعرّف ARN المورد المحدد — قاعدة مجموعة الأمان أو NACL بالضبط، أو جدول التوجيه، أو الشبكة الفرعية. هذا وحده يلغي 80% من التخمينات أثناء الحوادث الحية.

نمط إنتاجي: ادمج Reachability Analyzer في خط أنابيب البنية التحتية كرمز (IaC). شغّل تحليلاً كاختبار دخان بعد النشر في كل مرة تتغير فيها مجموعة أمان أو جدول توجيه. يمكن أن يُوقف التحليل الفاشل تطبيق Terraform أو يحجب مرحلة في خط أنابيب النشر قبل أن يصل أي عميل إلى المسار المكسور.

VPC Flow Logs

تلتقط Flow Logs سجل بيانات وصفية لكل تدفق شبكي: عنوان IP المصدر/الوجهة والمنفذ، البروتوكول، البايتات، الحزم، وبشكل حاسم — الحقل action: إما ACCEPT أو REJECT. يمكن تحديد نطاقها لواجهة شبكية، أو شبكة فرعية، أو VPC بأكمله. تُسلَّم السجلات إلى CloudWatch Logs أو S3 أو Kinesis Data Firehose.

تفعيل Flow Logs على مستوى VPC مع حقول مخصصة لتحليل جنائي أغنى:

# تفعيل VPC Flow Logs إلى CloudWatch Logs مع مجموعة حقول موسّعة aws ec2 create-flow-logs \ --resource-type VPC \ --resource-ids vpc-0abc12345def67890 \ --traffic-type ALL \ --log-destination-type cloud-watch-logs \ --log-group-name /vpc/flow-logs/prod \ --deliver-logs-permission-arn arn:aws:iam::123456789012:role/FlowLogsRole \ --log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${vpc-id} ${subnet-id} ${instance-id} ${tcp-flags} ${pkt-srcaddr} ${pkt-dstaddr} ${flow-direction} ${traffic-path}' \ --region us-east-1 # استعلام عن الحركة المرفوضة إلى وجهة محددة باستخدام CloudWatch Logs Insights aws logs start-query \ --log-group-name /vpc/flow-logs/prod \ --start-time $(date -d '1 hour ago' +%s) \ --end-time $(date +%s) \ --query-string 'fields @timestamp, srcaddr, dstaddr, dstport, action | filter action = "REJECT" and dstaddr = "10.0.4.22" | sort @timestamp desc | limit 50'

الحقول الأساسية لتضمينها دائماً: ${tcp-flags} (يميّز رفض SYN-فقط عن RST — مفيد لتشخيص التوجيه غير المتماثل)، ${traffic-path} (يُخبرك إذا دخلت الحزمة عبر NAT Gateway أو IGW أو VPN)، و${pkt-srcaddr} / ${pkt-dstaddr} (العناوين الأصلية قبل NAT، على عكس srcaddr/dstaddr التي تعكس القيم بعد NAT). هذه الفروق مهمة جداً في هياكل متعددة المناطق وTransit Gateway.

مخاطرة إنتاجية: Flow Logs لها تأخير تسليم يتراوح بين 5 و15 دقيقة لـ CloudWatch Logs وحتى 10 دقائق لـ S3. هي ليست سجل جدار حماية فوري. أثناء الحادثة النشطة، استخدم Reachability Analyzer للتحليل الفوري للتكوين. Flow Logs هي طبقة الأدلة والتحليل الجنائي بعد الحدث، وليست تغذية مباشرة.

تشريح فئات الإخفاق الشبكي الخمس الشائعة

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

  1. قاعدة مفقودة في مجموعة الأمان — الأكثر شيوعاً. لم تُضَف خدمة مصغرة جديدة أو منفذ جديد إلى مجموعة الأمان المعنية. يُعيد Reachability Analyzer SECURITY_GROUP_RULE_BLOCKED فوراً. الحل: أضف قاعدة واردة تستند إلى معرّف SG المصدر (وليس CIDR حيثما أمكن).
  2. عدم تناسق NACL — NACLs عديمة الحالة (stateless)، لذا يجب وجود قاعدة واردة وقاعدة صادرة مطابقة للمنافذ الوقتية (1024–65535 لحركة الإرجاع). تبدو NACL التي تحجب الاستجابات الصادرة الوقتية تماماً كاتصال أحادي الاتجاه من جانب العميل. ستُظهر Flow Logs REJECT في الاتجاه الصادر.
  3. مسار مفقود أو ميت — جدول التوجيه يفتقر إلى مسار للـ CIDR المستهدف، أو يشير مسار إلى مورد محذوف أو متوقف (مثل NAT instance متوقف). يُعيد Reachability Analyzer ROUTE_TABLE_MISSING_ROUTE أو ROUTE_TABLE_BLACKHOLE_ROUTE.
  4. مشاكل MTU / التجزئة — شائعة في المسارات عبر مرفقات VPN أو Transit Gateway. للمسار MTU أصغر (غالباً 1500 → 8500 لـ TGW peering بين المناطق، أو 1500 → 1436 لـ VPN). التطبيقات التي تستخدم أحجام نوافذ TCP كبيرة تعاني من تعليق أو انتهاء مهلة. العَرَض: الاتصال يُنشأ لكن نقل البيانات يتعطل. الحل: ضبط MSS clamping على VPN/TGW أو تعيين net.ipv4.tcp_mtu_probing=1 على الـ instances. Flow Logs وحدها لن تكشف ذلك — تحتاج إلى استكشاف مسار MTU نشط.
  5. إخفاقات تحليل DNS — تقنياً ليست على مستوى الشبكة لكنها تشكّل نسبة كبيرة من تذاكر "الخدمة غير قابلة للوصول". المناطق المستضافة الخاصة غير مرتبطة بـ VPC الصحيح، أو Route 53 Resolver لا يُحيل إلى DNS المحلي، أو enableDnsSupport / enableDnsHostnames معطّلان على الـ VPC. تحقق دائماً بـ dig أو nslookup من داخل VPC قبل افتراض مشكلة توجيه أو جدار حماية.

مخطط سير عمل استكشاف الأخطاء

AWS Network Troubleshooting Decision Flow Report: Connectivity Failure Gather source, dest, port, protocol Run Reachability Analyzer Logical path — no traffic injected Blocked Inspect Explanation SG / NACL / Route fix Reachable Query VPC Flow Logs Filter: REJECT on src/dst IP + port REJECT NACL Asymmetry Add ephemeral return rule ACCEPT Investigate App / DNS / MTU dig, tracepath, curl -v, MSS tuning Issue Resolved
مخطط القرار المنظّم: Reachability Analyzer ثم Flow Logs ثم طبقة التطبيق/DNS/MTU.

دليل عملي: "Instance لا تستطيع الوصول إلى RDS"

هذا هو التسلسل الدقيق الذي يتبعه مهندس SRE أول عندما يُبلّغ تطبيق ما بعدم قدرته على الاتصال بقاعدة بياناته:

# 1. تأكيد معرّفات الـ instance وENI الخاص بـ RDS aws ec2 describe-instances --filters "Name=tag:Name,Values=app-server-prod" \ --query 'Reservations[].Instances[].{ID:InstanceId,IP:PrivateIpAddress,SG:SecurityGroups[].GroupId}' aws rds describe-db-instances --db-instance-identifier prod-postgres \ --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,SG:VpcSecurityGroups[].VpcSecurityGroupId}' # 2. تشغيل Reachability Analyzer (المصدر=ENI التطبيق، الوجهة=ENI RDS، المنفذ 5432) # أولاً: البحث عن معرّفات ENI APP_ENI=$(aws ec2 describe-network-interfaces \ --filters "Name=attachment.instance-id,Values=i-0abc123456789def0" \ --query 'NetworkInterfaces[0].NetworkInterfaceId' --output text) RDS_ENI=$(aws ec2 describe-network-interfaces \ --filters "Name=description,Values=*prod-postgres*" \ --query 'NetworkInterfaces[0].NetworkInterfaceId' --output text) aws ec2 create-network-insights-path \ --source $APP_ENI --destination $RDS_ENI \ --protocol TCP --destination-port 5432 \ --tag-specifications 'ResourceType=network-insights-path,Tags=[{Key=incident,Value=INC-0042}]' # 3. إذا كانت Reachable=true، استخرج Flow Logs للـ ENI الخاص بـ RDS تحديداً aws logs start-query \ --log-group-name /vpc/flow-logs/prod \ --start-time $(date -d '30 minutes ago' +%s) \ --end-time $(date +%s) \ --query-string 'fields @timestamp, srcaddr, dstaddr, srcport, dstport, action, tcp-flags | filter interface-id = "eni-0rds456789abc0def" | filter dstport = 5432 or srcport = 5432 | sort @timestamp desc | limit 100' # 4. اختبار تحليل DNS من داخل VPC (يتطلب SSM Session Manager) aws ssm start-session --target i-0abc123456789def0 \ --document-name AWS-StartInteractiveCommand \ --parameters command="dig prod-postgres.cluster-abc123.us-east-1.rds.amazonaws.com +short"
ضع علامات على مسارات التحليل بمعرّفات الحوادث. مسارات Reachability Analyzer وتحليلاتها تبقى في حسابك. في البيئات الخاضعة للتنظيم (SOC 2، PCI-DSS) يُنشئ هذا مسار تدقيق تلقائياً يُظهر بالضبط التكوين الموجود وقت الحادثة والمسار المنطقي آنذاك. احفظ معرّف التحليل في تذكرة الحادثة.

اعتبارات التكلفة والتشغيل

تُولّد Flow Logs عند حجم حركة مرتفع تكاليف ضخمة لاستيعاب CloudWatch Logs. أفضل الممارسات الإنتاجية: أرسل Flow Logs إلى S3 لكفاءة التكلفة (تكاليف تسليم السجلات ~0.50 دولار/GB مقارنة بـ 0.50 دولار/GB للاستيعاب في CWL بالإضافة إلى 0.03 دولار/GB تخزيناً)، وفعّل صيغة Parquet لتسليم S3 لتمكين استعلامات Athena دون تحويل، واحدد النطاق لحركة REJECT فقط ما لم تكن بحاجة إلى تغطية جنائية كاملة. يُفرض على Reachability Analyzer رسوم لكل تحليل (0.10 دولار للتحليل)، وهو مبلغ زهيد مقارنة بوقت الهندسة الذي يوفره — استخدمه بحرية.

الدرس السابق الوصول عبر الحسابات وخدمة STS
الدرس التالي مشروع: تصميم VPC للإنتاج
العودة للدورة