فحص المصدر/الوجهة بوابة واحدة، وليس مسار VPN بأكمله
تحتاج نسخة إعادة التوجيه إلى إذن من AWS وإلى مسارات Linux وقواعد جدار الحماية. افحص التحقق من المصدر/الوجهة على النسخة التي تعيد التوجيه.
ينتهي نفق VPN على نسخة EC2، ويمكنك الوصول إلى عنوان النفق لتلك النسخة، بينما تختفي الحركة المفترض أن تمر عبرها نحو مضيف خاص آخر. هذان اختباران مختلفان، وخلطهما يضيع ساعات. يسأل الأول ما إذا كان بإمكانك الوصول إلى النسخة؛ ويسأل الثاني أن تعيد توجيه الحركة نحو وجهة ليست وجهتها، وهو ما يحتاج إلى إعادة توجيه Linux، وسياسة جدار حماية، ومسار على الجانب الآخر، وإذن على مستوى AWS لا علاقة له بنظام تشغيل الضيف. لا شيء في وحدة التحكم يلفت الانتباه إلى هذا الفرق. تبدو العَرَض كخلل في التوجيه، وهي في الغالب ليست كذلك.
افصل الاختبارين قبل أن تغيّر أي شيء
الوصول إلى البوابة يثبت النفق، والمسار إلى عنوانها، ومجموعة الأمان التي تسمح بالتبادل. إعادة التوجيه لمضيف آخر لا تثبت أيًا من ذلك: فهي تستخدم عنوان مصدر مختلفًا، ووجهة مختلفة، ونسخة تعمل بدور لم تُبنَ له بالضرورة. اكتب الاختبارين بشكل منفصل ولاحظ أيهما يفشل، لأن التصحيح لكل منهما موجود في وحدة تحكم مختلفة. نسخة البوابة المبنية فقط لإنهاء الأنفاق ليس لديها سبب لإعادة التوجيه لأي شيء آخر، وإعداداتها الافتراضية تعكس ذلك. ولهذا يحتاج الاختبار الثاني إلى إعداد خاص به بدلًا من تعديل بسيط للأول.
اختبار ping ينجح نحو البوابة واختبار ping يفشل نحو المضيف الذي بعدها ليس مشكلة متقطعة. إنه السلوك المتوقع لنسخة لم يُبلَّغ أنها قد تعيد التوجيه.
اكتب المسار قبل لمس أي إعداد
سجّل بادئة العميل، ونسخة إعادة التوجيه أو واجهة الشبكة، والشبكة الفرعية الهدف، ومسار الرد. لا يُعدّ إدخال جدول مسارات VPC الذي يشير إلى نسخة تهيئةً لنظام تشغيل النسخة لإعادة التوجيه، ونواة ضيف مع تمكين إعادة التوجيه لا تنشئ مسار VPC. يجب أن يوجد طرفا هذه العلاقة، وكلاهما يُحرَّر في أماكن مختلفة بواسطة أشخاص لديهم صلاحيات مختلفة.
ثم افحص إعداد فحص المصدر/الوجهة على مكوّن إعادة التوجيه الفعلي، لا على كل نسخة في VPC. توثّق AWS سبب حاجة النسخة التي تعيد توجيه حركة الآخرين إلى تعطيل هذا الفحص، وأيضًا سبب كون الإعداد قرارًا لكل نسخة بدلًا من كونه إعدادًا افتراضيًا على مستوى VPC.
أربع حدود، والفحص واحد منها فقط
تعامل مع المسار كأربعة أسئلة وأجب عنها بالترتيب. أول إجابة فاشلة هي موضع العمل، ولن تعوّض عنها أي إجابة أخرى.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
الترتيب مهم لأنه رخيص التحقق: المسارات مرئية في صفحة واحدة، والفحص سمة واحدة، ورأي الوجهة هو عادة آخر ما يسأل عنه أحد.
الترجمة تغيّر أي مصدر تراه الوجهة
التصميم الموجّه يحافظ على عنوان مصدر العميل، لذا تحتاج الوجهة إلى مسار عودة إلى بادئة العميل. أما التصميم المترجم فيعرض عنوان البوابة بدلًا من ذلك، ما يزيل هذا الشرط ويستبدله بجدول حالة على البوابة. قرّر وفق البنية التي تنويها، بدلًا من إضافة الترجمة لأن مثالًا غير ذي صلة استخدمها وبدا ناجحًا.
إذا ترجمت، فحدّد القاعدة ببادئة العميل والوجهة المقصودة. وإذا حافظت، فتأكد من أن الجانب الآخر يعرف المسار فعلًا بدلًا من افتراض أنه سيتعلمه.
اختبر من العميل الأصلي، ثم احتفظ بالتغيير
يمكن أن ينجح طلب يُنشأ على البوابة بينما يفشل طلب مُعاد توجيهه، لأنه مصدر مختلف وحالة إعادة توجيه مختلفة. بعد تصحيح مستهدف، كرر اختبار العميل إلى المورد نفسه الذي فشل، من العميل نفسه، وتأكد من عودة الرد وليس فقط من وصول الطلب.
أخيرًا، ضع الإعداد في تهيئة البوابة المُدارة حتى تستقبله نسخة بديلة. الاختبار الناجح الذي يعتمد على استثناء يدوي هو اختبار ينتهي عند أول إعادة بناء، والشخص الذي اكتشفه لن يكون هناك ليتذكر السبب.