VGW أم TGW؟ أين ينتهي نفق IPsec لخدمة AWS Site-to-Site

يسأل الناس عن الموضع الذي يتوقف فيه نفق AWS Site-to-Site VPN عن حماية الرزمة، ويتوقعون جوابًا واحدًا: عند البوابة. والنسخة المفيدة من ذلك الجواب تسمّي أي بوابة، لأن البوابة الخاصة الافتراضية وبوابة العبور ترتيبان مختلفان بكائني ربط مختلفين، والمراجع الذي يفترض الخطأ يبني بقية التقييم على مخطط غير موجود. نفّذ الفحوص الثلاثة أدناه بالترتيب. كل فحص إما يؤكد الحدّ أو يخبرك بأن الجواب السابق كان عن مورد آخر.

سمِّ النقاط الطرفية الثلاث قبل أن تقيّم أي شيء

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

بوابة العميل ملكك وإعدادها مرئي لك. أما هدف AWS فهو مورد مُدار، والخطأ هو افتراضه: يمكن لاتصال VPN أن يرتبط ببوابة خاصة افتراضية أو مباشرةً ببوابة عبور، ولا يستلزم أي منهما الآخر. النقطة الطرفية الثالثة هي التي يتخطاها الناس، وهي الوحيدة التي تجيب عن السؤال الفعلي بشأن بيانات التطبيق.

الفحص 1: أي بوابة تنهي النفق فعليًا

الترتيبان مدعومان و دليل هندسة Site-to-Site VPN يصفهما جنبًا إلى جنب، فاسأل واجهة API بدلًا من مخطط غالبًا ما يكون عمره سنة. يعيد استعلام للقراءة فقط على اتصال واحد حقول هدف VPN:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

المُميّز هو TransitGatewayId وليس VpnGatewayId. الاتصال الذي يكون فيه TransitGatewayId فارغًا ينتهي عند بوابة خاصة افتراضية مستقلة، بينما الاتصال الذي يكون فيه ذلك الحقل مضبوطًا ينتهي عند مرفق VPN لبوابة العبور، وقد يظل VpnGatewayId مملوءًا في تلك الحالة لأنه قد يسمّي البوابة الداعمة للمرفق. اقرأ حقل TGW أولًا، ثم أكّد نوع المرفق من قائمة المرفقات لا من اسم حقل، لأن مرفق VPC على بوابة العبور تلك ليس مرفق VPN. العثور على نسخة الوجهة داخل VPC مرتبطة لا يخبرك بشيء عن مرفق VPN الذي حمل الرزمة.

وأثناء وجودك هناك، افحص الأنفاق. يحمل الاتصال نفقَي IPsec للتكرار، والاتصال الذي لم ينهض نفقُه الثاني قط يمثّل نتيجة حقيقية بشأن التوافر حتى لو لم يغيّر شيئًا في حدّ التشفير:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

الفحص 2: ما الذي تحمله الرزمة الداخلية بعد ذلك

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

افحص الآن ما كان في الداخل. إذا كانت الرزمة الداخلية بروتوكول تطبيق بنص صريح، فلا شيء في المصبّ يضيف سرية حتى يشفّرها شيء آخر. وإذا كانت الرزمة الداخلية تحمل جلسة TLS أصلًا، فإن إزالة IPsec الخارجي لا تغيّر شيئًا في تلك الجلسة: تبقى محمية حتى نقطة نهايتها الخاصة، أينما كانت.

التصحيح المفرط الشائع هو الاستنتاج بأن كل شيء خلف البوابة مكشوف. ليس كذلك. نقل الخدمة وتشفير التخزين وTLS التطبيق آليات منفصلة بشروط منفصلة، وكل منها يجب تقييمه بشروطه بدلًا من استنتاجه من شكل VPN. ومدخل سجل التدفق الذي يُظهر ACCEPT يثبت أن التوجيه عمل، ولا يقول شيئًا عن السرية، وهو بالضبط الخطأ الذي توجد هذه القائمة لمنعه.

الفحص 3: ما الذي ينهي TLS خلف البوابة

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

اختبر نقطة النهاية التي تهمّك فعليًا من داخل VPC، بالاسم الذي يستخدمه التطبيق لا بعنوان IP حلّلته مرة واحدة:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

كرّر ذلك لكل قفزة يمر بها الطلب. إذا اختلف الجواب بين الاسم المواجه للعميل واسم الخلفية، فقد وجدت بالضبط المقطع الذي لم يغطه VPN قط، وتلك هي النتيجة التي يجب كتابتها.

سجّل النتيجة كمقاطع لا كحكم

ناتج قائمة التحقق هذه جدول صغير بصف لكل مقطع: بوابة العميل إلى هدف AWS VPN، والبوابة إلى الحمل، والحمل إلى مخزن البيانات، وأي قفزة وكيل بينها. كل صف يقول ما يحميه وما تعتمد عليه تلك الحماية. وكلمة "مشفّر" بلا آلية وبلا نقطة نهاية ليست صفًا.

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

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