كيف حللنا مشكلة بوابة NAT في AWS

في Deriv، قررنا أن نصبح مستقلين عن السحابة من خلال نقل بعض خدماتنا من AWS إلى GCP. لا تزال غالبية خدماتنا وقواعد بياناتنا تعمل على بنية AWS التحتية.

كان من أبرز مخاوفنا الأمنية ألا نعرض خدماتنا للشبكة العامة. لذا، قررنا إدارة حركة المرور عبر شبكة خاصة من خلال إنشاء نفق VPN بين GCP وAWS باستخدام بروتوكول IPSec لتأمين قناة الاتصال.

اتصال VPN من موقع إلى موقع:

المفاهيم الرئيسية المستخدمة على AWS للتواصل مع GCP تنقسم إلى مجموعتين.

أولاً، لدينا المفاهيم الرئيسية لـ VPN من موقع إلى موقع المستخدمة على AWS:

• اتصال VPN: اتصال آمن بين السحب الأخرى ومجموعات VPC على AWS
• نفق VPN: رابط مشفر حيث يمكن للبيانات الانتقال من الشبكة الأخرى إلى أو من AWS
• بوابة العملاء: مورد AWS يوفر معلومات لـ AWS حول جهاز البوابة لديك. في حالتنا، هو بوابة VPN نظيرة لـ GCP. بوابات Cloud VPN الخاصة بـ GCP مرتبطة بهذه البوابة على AWS.
• البوابة الخاصة الافتراضية: بوابة خاصة افتراضية هي نقطة النهاية لشبكة VPN على جانب أمازون من اتصال VPN الخاص بك بين الموقعين والتي يمكن ربطها بمجموعات VPC واحدة.

ثم، هناك المفاهيم الرئيسية المستخدمة في نهاية GCP للتواصل مع AWS:

• Cloud Router: خدمة Google Cloud موزعة بالكامل ومدارة لتوفير التوجيه الديناميكي باستخدام BGP لشبكات VPC الخاصة بك.
• Cloud NAT: إنها خدمة من Google تسمح لبعض الموارد التي ليس لديها عناوين IP خارجية بإنشاء اتصالات خارجة إلى الإنترنت.
• Cloud VPN gateway: بوابة VPN تديرها Google تعمل على Google Cloud. كل بوابة Cloud VPN هي مورد إقليمي لها واجهة أو اثنتان. استخدمنا واجهتين، كل واحدة منهما بعنوان IP خارجي خاص بها: الواجهة 0 و1. كل بوابة Cloud VPN متصلة ببوابة VPN نظيرة. عناوين IP العامة لأنفاق AWS مرتبطة بهذه البوابة.
• بوابة VPN النظير: إنها بوابة متصلة ببوابة Cloud VPN. جميع الأنفاق هي من طرف GCP تستخدم هذه البوابة. يجب أن يكون لكل نفق عنوان IP خارجي واحد.
• Cloud VPN tunnels: نفق VPN يربط بين بوابتين VPN (AWS وGCP) ويعمل كنفق افتراضي تمر من خلاله حركة المرور المشفرة.

التوافر العالي للأنفاق:

التوافر العالي (HA) هو جانب تحدي وحاسم عند بناء أي بنية تحتية حرجة.

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

التحديات التي واجهناها أثناء المشروع:

عادةً ما تقوم تطبيقاتنا بأكثر من 100 مكالمة API في الثانية والعديد من الاتصالات المتزامنة من GCP إلى الخوادم والخدمات وقواعد البيانات المستضافة على AWS. لم ندرك أن ذلك سيكون عنق زجاجة.

تم إعادة توجيه الحركة إلى أعباء عمل GCP ببساطة عن طريق تغيير بعض سجلات DNS على Cloudflare. لكن التطبيقات كانت تعمل بشكل جيد لبعض الوقت، ثم تراكمت قائمة انتظار API، وبدأت التطبيقات تستجيب ببطء للمستخدمين.

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

التحسينات التي حلت عنق الزجاجة:

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

انظر كيفية استخدام بوابات Cloud NAT لعناوين IP والمنافذ بمزيد من التفصيل.

نظرًا لأن خوادم GCP لدينا تنشئ أكثر من 100 اتصال إلى الخوادم المستضافة على AWS، كانت الاتصالات تُرفض بمجرد الوصول إلى العدد الافتراضي 64.

أخيرًا، قررنا زيادة حد الحد الأدنى للمنافذ لكل مثيل VM إلى 1,024، مما ساعد في حل المشكلة.

الآن، خدماتنا تعمل على كل من AWS وGCP.