تشخيص اتصال VPC الخاصة دون فتح الوصول للجميع

افهم الأسباب المحتملة

• قد تنتج الأعراض المتشابهة عن مسار مفقود أو غير مطابق، أو اختيار غير مناسب لمسار NAT أو نقطة النهاية، أو مجموعة أمان مقيّدة، أو قاعدة عودة في ACL عديمة الحالة، أو إعداد محلّل الأسماء، أو وجهة غير سليمة. قاعدة سماح واحدة لا تثبت عمل المسار كاملًا.

صِف تدفقًا واحدًا ومرحلة فشله

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

09:00:00 DNS lookup: api.example.test -> 198.51.100.25
09:00:01 TCP destination: 198.51.100.25:443
09:00:11 TCP result: connection timeout
TLS stage: not reached

تتبّع المسار المختار ومسار العودة

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

افحص ضوابط الحالة والضوابط عديمة الحالة منفصلة

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

استخدم الدليل المناسب للطبقة

يمكن لتحليل الإعدادات المساعدة في تحديد مسار افتراضي محجوب؛ ومن أمثلته Reachability Analyzer الذي تُحتسب تكلفته لكل تحليل. لكنه لا يغني عن فحص إجابات DNS وحالة نظام التشغيل وهوية TLS وسلامة التطبيق. ملاحظات التدفقات أدلة محدودة أيضًا: قبول تدفق شبكي لا يثبت إتمام التطبيق لعمله. قد تتضمن مسارات نقاط النهاية سياسة نقطة نهاية وتفويض الخدمة. إذا نجح الاتصال ثم أعادت الخدمة AccessDenied، فاحتفظ بالدليل الشبكي وانتقل إلى التحقيق في الهوية بدل توسيع قواعد الشبكة مرارًا.

صحّح المسار المقصود ووثّقه

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

{
  "source": "private-app-subnet",
  "required_flow": "HTTPS to approved external API",
  "hypothesis": "source subnet uses an unintended route-table association",
  "change": "review the intended association with the network owner",
  "rollback": "restore the recorded original association",
  "negative_check": "unsolicited inbound traffic remains unavailable"
}

امنع تكرار المشكلة

• احتفظ بجرد لتدفقات الاعتماد وارتباطات الشبكات الفرعية المراجَعة ومتطلبات شبكة صريحة. أدرج المسارات المسموحة والممنوعة في مراجعات التغيير لعزل الحادث التالي دون تعريض أحمال العمل الخاصة.