أي عنوان IP مصدر تستخدمه بوابة NAT من AWS نحو VPN؟

تفتح وحدة تحكم VPC لأن أحد الشركاء سأل عن نطاق المصدر الذي سيصل عبر VPN من موقع إلى موقع. تعرض صفحة بوابات NAT بوابة عامة مرتبطة بعنوان مرن، والإغراء هو إرسال ذلك العنوان والاكتفاء به. إنه الجواب الصحيح لمسار الإنترنت والجواب الخاطئ لمسار VPN، والفرق هو البوابة التي يشير إليها جدول المسارات. تتبَّع المسار قبل أن تكتب قائمة السماح.

ابدأ من صفحة بوابات NAT، لا من قائمة السماح

تخبرك صفحة بوابات NAT بالشبكة الفرعية والنوع والعنوان المرن، وهذه الحقول الثلاثة كافية للبدء. ما لا تخبرك به هو المسار الذي يسلكه المرور بعد ذلك. يأتي ذلك من جداول المسارات المرتبطة بالشبكة الفرعية لبوابة NAT.

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

اتبع التحويلين

تحوّل بوابات NAT العامة والخاصة على حد سواء مصدر IPv4 الخاص لأحمال العمل إلى عنوان IPv4 الخاص ببوابة NAT نفسها. ويحدث هذا التحويل الأول بغض النظر عن النوع. التحويل الثاني هو الذي ينساه الناس: تسلّم بوابة NAT العامة المرور إلى بوابة الإنترنت، التي تربط العنوان بالعنوان المرن المرتبط بها.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

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

مسار VPN يعرض عادة العنوان الخاص

لحمل عمل في 10.20.1.0/24 يصل إلى بادئة شريك، يشير جدول مسارات الشبكة الفرعية لحمل العمل إلى بوابة NAT، ويشير جدول مسارات الشبكة الفرعية لبوابة NAT إلى مسار البوابة الخاصة. كلا القفزتين مهمتان، والثانية وحدها تحدد ما يراه الشريك. إذا لم يكن للشبكة الفرعية لـ NAT أي مسار إلى مسار VPN، فإن الحزمة لا تصل أبداً، وهذا فشل مختلف عن عنوان مصدر خاطئ.

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

عندما يغيّر تحويل ثانٍ الجواب

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

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

لا يمكن منح بوابة NAT خاصة خدمة إنترنت بتوجيهها إلى بوابة إنترنت؛ وتوثّق AWS أن مثل هذا المرور يُسقَط. اختر النوع من المسار الكامل، لا من كلمة VPN في المتطلب.

اكتب العقد الذي يستطيع شريكك التصرف بناءً عليه

للعقد القابل للاستخدام أربعة أجزاء: الاتجاه الذي تُبدأ منه التدفقات، والهوية المحوَّلة التي سيراها الشريك، ومسار العودة لتلك الهوية، ونطاق الحماية المطبق. تُبدأ تدفقات بوابة NAT من الجانب المنشئ المدعوم، لذا ليست هذه خدمة تحويل منافذ واردة لعرض حمل عمل خاص. والقول ذلك بصوت عالٍ مبكراً يمنع مراجعة تصميم يفترض فيها كل طرف أن الطرف الآخر هو المبادر.

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

ثم أعد فحص كلا جدولي المسارات بعد أي تغيير، لأن مرفقاً جديداً أو شبكة فرعية أعيد ربطها يعيد كتابة الجواب بصمت.