عنوان Elastic IP في EC2 ليس عنوان VPN الخاص بالمثيل

للمثيل عنوان خاص، وعنوان Elastic IP مرتبط به، ويُضاف مسار لهذا العنوان العام /32 إلى الـ VPN على أمل أن يصبح الاثنان الشيء نفسه. لكنهما لا يصبحان. إن Elastic IP ترجمة تُنفَّذ خارج الضيف، بواسطة بوابة الإنترنت، على حركة المرور التي تسلك مسار الإنترنت. ولا يرى نظام تشغيل الضيف هذا العنوان مُهيَّأً على أي واجهة أبدًا. وإضافته إلى واجهة نفق لا تعيد إنتاج الترجمة التي تحدث في المنبع، بل تنشئ هوية ثانية متعارضة للجهاز نفسه.

عنوانان، مثيل واحد

تحمل واجهة شبكة المثيل عنوانًا خاصًا داخل الـ VPC، وهذا هو العنوان الذي يعرفه الضيف. أما Elastic IP فهو مرتبط بالواجهة نفسها لكنه يعيش على الجانب العام من التعيين.

كل ما يصل إلى المثيل عبر الإنترنت يصل مترجمًا إلى العنوان الخاص. وكل ما يرسله المثيل إلى الإنترنت يخرج وعنوان Elastic IP هو مصدره، مرة أخرى بسبب تلك الترجمة.

داخل الضيف يوجد عنوان واحد. وخارجه يوجد عنوانان. هذا التفاوت يفسر معظم الالتباس في هذا المجال. لا يستطيع الضيف تهيئة ما تترجمه البوابة. ولا يستطيع إلا الرد على العنوان الذي يحمله فعلاً.

ما تفعله بوابة الإنترنت فعلاً

تصف وثائق بوابة الإنترنت من AWS هذا الترتيب: المثيل على علم بعنوان IPv4 الخاص به، وتوفّر البوابة ترجمة IPv4 العام أو Elastic IP المقابلة لحركة المرور على مسار الإنترنت.

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

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

لماذا تفشل حيلة واجهة النفق

تخصيص Elastic IP لواجهة نفق يطلب من الضيف معاملة عنوان عام كأنه محلي. الآن شيءان يطالبان بالعنوان نفسه: ترجمة البوابة على مسار الإنترنت والواجهة المحلية داخل النفق. وليس لحركة العودة جواب متسق عن أيّهما ينطبق.

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

لم يكن العنوان هو المشكلة قط. اختيار المسار هو الذي كان.

ثلاثة أهداف، ثلاثة تصاميم

إذا كان الهدف طرفًا عامًا للـ VPN، فإن Elastic IP هو الأداة الصحيحة: يتصل الأقران البعيدون به عبر الإنترنت وينتهي النقل المشفّر على المثيل. ثم تستخدم حركة التطبيق الداخلية العنوان الخاص.

وإذا كان الهدف وصولاً خاصًا إلى التطبيق، فالوجهة هي العنوان الخاص أو اسم DNS خاص يُحل إليه، ويجب أن يتفق مسار VPN ومجموعة الأمان ومسار العودة جميعًا. ولا يظهر Elastic IP في ذلك التصميم إطلاقًا.

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

تحقق من المسار الذي اخترته

للوصول الخاص، تأكد من أن مسار VPN يغطي البادئة الخاصة، وأن جدول مسارات الـ VPC يعيد حركة المرور إلى النفق، وأن مجموعة الأمان تسمح بمصدر العميل، وأن جدار الحماية الخاص بالعميل يسمح بالرد. ثم اختبر طلبًا حقيقيًا واحدًا بدلاً من ping.

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

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