لماذا تفشل GRE وESP عبر بوابة NAT في AWS

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

مجموعة القواعد ليست مجموعة البروتوكولات

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

تسرد مواصفات بروتوكول بوابة NAT الخاصة بـ AWS بروتوكولات TCP وUDP وICMP للخدمة المُدارة. هذه هي المجموعة المدعومة بأكملها. ولا يمكن لقاعدة سماح ببروتوكول IP آخر أن توسّعها، لأن القاعدة تُقيَّم قبل وقت طويل من الوصول إلى مسار التمرير في البوابة.

يهم هذا التمييز لأن الفشلين يبدوان متطابقين من جهة العميل ولهما إصلاحان مختلفان تمامًا.

PPTP يبين لماذا يكذب اختبار المنفذ

PPTP هو أوضح مثال قديم على اختبار منفذ لا يثبت شيئًا. يفتح اتصال تحكم TCP على المنفذ 1723 ثم ينقل بيانات النفق عبر GRE، وهو بروتوكول IP رقم 47. البروتوكول 47 ليس منفذ TCP رقم 47، والرقمان لا علاقة لهما أحدهما بالآخر سوى مشاركة الأرقام.

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

ينطبق المنطق نفسه على أي بروتوكول تكون قناة التحكم فيه TCP أو UDP بينما مسار بياناته ليس كذلك.

IPsec يبقى فقط كـ UDP

IPsec هو الحالة التي يكون فيها الجواب مشروطًا لا رفضًا قاطعًا. توثق AWS اجتياز NAT كترتيب مدعوم لـ IPsec عبر بوابة NAT. ومع التفاوض على NAT-T، تُغلَّف ESP داخل UDP وترى البوابة UDP عادية بدل البروتوكول 50.

السماح بـ UDP 4500 لا يجعل نقاط النهاية تستخدم اجتياز NAT. إنه يسمح بالحزم فقط إذا كانت مشكّلة على هذا النحو بالفعل. تحقق من مخرجات التفاوض الخاصة بالعميل أي تغليف تم اختياره، وتحقق من جهة الاستقبال أن الطرف النظير قبله. ستواصل نقطتا نهاية مُهيأتان لـ ESP الأصلية إرسال ESP الأصلية مهما قال مجموعة القواعد.

الـ VPN القائم على TCP أو UDP يتناسب مع مجموعة النقل الموثقة ويمكن أن يفشل مع ذلك لأسباب تتعلق بالتوجيه أو التصفية أو المصادقة. ملاءمة المجموعة ضرورية لا كافية.

تحقق من المسار قبل توسيع السياسة

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

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

لا تفتح كل حركة المرور لتعويض نقل لا تستطيع الخدمة حمله. لن يصلح تغيير القاعدة ذلك، وسيبقى بعد الحادث.

عندما لا يتناسب النقل

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

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

ترتيب العمل: سمِّ البروتوكول الخارجي، وتحقق من القفزة التالية، وقارنه بالمجموعة الموثقة، ثم غيّر البنية أو النقل. لا يمكن لرقم منفذ مختلف تحويل GRE إلى TCP، ولا يمكن لقاعدة أكثر تسامحًا تحويل تبادل تحكم مكتمل إلى قناة بيانات عاملة.