توضح هذه المقالة أفضل الممارسات لبوابة Azure NAT. تستند الإرشادات إلى الركائز الخمس للتميز المعماري: تحسين التكلفة والتميز التشغيلي وكفاءة الأداء والموثوقية والأمان.
كشرط أساسي لهذه الإرشادات، يجب أن يكون لديك معرفة عملية ببوابة Azure NAT وفهم ميزاتها الخاصة. لمزيد من المعلومات، راجع وثائق Azure NAT Gateway.
تحسين التكلفة
تكوين الوصول إلى حلول النظام الأساسي كخدمة (PaaS) من خلال Azure Private Link أو نقاط نهاية الخدمة، بما في ذلك التخزين، بحيث لا تضطر إلى استخدام بوابة NAT. لا تتطلب نقاط نهاية الارتباط الخاص والخدمة اجتياز بوابة NAT للوصول إلى خدمات PaaS. يقلل هذا الأسلوب من تكلفة كل غيغابايت (GB) من البيانات المعالجة، مقارنة بتكلفة استخدام بوابة NAT. يوفر الارتباط الخاص ونقاط نهاية الخدمة أيضا مزايا الأمان.
كفاءة الأداء
يوفر كل مورد بوابة NAT ما يصل إلى 50 جيجابت في الثانية (جيجابت في الثانية) من معدل النقل. يمكنك تقسيم عمليات النشر إلى شبكات فرعية متعددة، ثم تعيين بوابة NAT لكل شبكة فرعية أو مجموعة من الشبكات الفرعية لتوسيع نطاقها.
يوفر كل عنوان IP عام لبوابة NAT 64512 منفذا لترجمة عناوين الشبكة المصدر (SNAT). يمكنك تعيين ما يصل إلى 16 عنوان IP إلى بوابة NAT، بما في ذلك عناوين IP العامة القياسية الفردية أو بادئة IP العامة أو كليهما. لكل عنوان IP صادر معين ينتقل إلى نفس نقطة النهاية الوجهة، يمكن أن تدعم بوابة NAT ما يصل إلى 50000 تدفق متزامن لبروتوكول التحكم في الإرسال (TCP) وبروتوكول مخطط بيانات المستخدم (UDP) على التوالي.
استهلاك SNAT
ضع في اعتبارك الإرشادات التالية للمساعدة في منع استنفاد SNAT:
موارد بوابة NAT لها مهلة خامول TCP افتراضية من أربع دقائق. يمكنك تكوين المهلة لمدة تصل إلى 120 دقيقة. إذا قمت بتغيير هذا الإعداد إلى قيمة أعلى من القيمة الافتراضية، فإن بوابة NAT تحتفظ بالتدفقات لفترة أطول، مما قد يؤدي إلى حدوث ضغط غير ضروري على مخزون منفذ SNAT.
حد الطلبات الذرية (طلب واحد لكل اتصال) وتقليل الأداء وتقليل الموثوقية. بدلا من الطلبات الذرية، يمكنك إعادة استخدام اتصالات HTTP أو HTTPS لتقليل عدد الاتصالات ومنافذ SNAT المقترنة. عند إعادة استخدام الاتصالات، يمكن للتطبيق تغيير الحجم بشكل أفضل. يتحسن أداء التطبيق بسبب انخفاض المصافحات والنفقات العامة وتكاليف عملية التشفير عند استخدام أمان طبقة النقل (TLS).
إذا لم تقم بتخزين نتائج محلل DNS مؤقتا، يمكن أن تقدم عمليات البحث في نظام أسماء المجالات (DNS) العديد من التدفقات الفردية في وحدة التخزين. استخدم التخزين DNS المؤقت لتقليل حجم التدفقات وتقليل عدد منافذ SNAT. DNS هو نظام التسمية الذي يعين أسماء المجالات إلى عناوين IP للموارد المتصلة بالإنترنت أو بشبكة خاصة.
تستخدم تدفقات UDP، مثل عمليات بحث DNS، منافذ SNAT أثناء مهلة الخمول. يتم إصلاح مؤقت مهلة الخمول UDP في أربع دقائق.
استخدم تجمعات اتصالات لتشكيل حجم الاتصال.
لتنظيف التدفقات، لا تتخلى بصمت عن تدفقات TCP أو تعتمد على مؤقتات TCP. إذا لم تسمح ل TCP بإغلاق اتصال بشكل صريح، يبقى اتصال TCP مفتوحا. تحافظ الأنظمة الوسيطة ونقاط النهاية على هذا الاتصال قيد الاستخدام، ما يجعل منفذ SNAT غير متوفر للاتصالات الأخرى. يمكن أن يؤدي هذا antipattern إلى فشل التطبيق واستنفاد SNAT.
لا تغير قيم المؤقت ذات الصلة بإغلاق TCP على مستوى نظام التشغيل إلا إذا كنت تعرف الآثار المترتبة على ذلك. إذا كانت نقاط نهاية الاتصال غير متطابقة مع التوقعات، يمكن استرداد مكدس TCP، ولكنه قد يؤثر سلبا على أداء التطبيق الخاص بك. عادة ما تكون لديك مشكلة تصميم أساسية إذا كنت بحاجة إلى تغيير قيم المؤقت. وإذا كان التطبيق الأساسي يحتوي على مضادات تناثر أخرى وقمت بتغيير قيم المؤقت، فقد تقوم أيضا بتسريع استنفاد SNAT.
راجع الإرشادات التالية لتحسين نطاق وموثوقية الخدمة:
ضع في اعتبارك تأثيرات تقليل مهلة الخمول TCP إلى قيمة أقل. يمكن لمهلة الخمول الافتراضية المكونة من أربع دقائق تحرير مخزون منفذ SNAT بشكل استباقي.
ضع في اعتبارك أنماط الاستقصاء غير المتزامنة للعمليات طويلة الأمد لتحرير موارد الاتصال الخاصة بك لعمليات أخرى.
ضع في اعتبارك استخدام TCP keepalives أو طبقة التطبيق keepalives لتدفقات TCP طويلة الأمد، مثل اتصالات TCP المعاد استخدامها، لمنع الأنظمة الوسيطة من المهلة. يجب عليك فقط زيادة مهلة الخمول كحل أخير، وقد لا تحل السبب الجذري. يمكن أن تتسبب المهلة الطويلة في فشل معدل منخفض عند انتهاء المهلة. كما يمكن أن يؤدي إلى تأخير وإخفاقات غير ضرورية. يمكنك تمكين TCP keepalives من جانب واحد من الاتصال للحفاظ على اتصال على قيد الحياة من كلا الجانبين.
ضع في اعتبارك استخدام UDP keepalives لتدفقات UDP طويلة الأمد لمنع الأنظمة الوسيطة من المهلة. عند تمكين UDP keepalives على جانب واحد من الاتصال، يظل جانب واحد فقط من الاتصال نشطا. يجب تمكين UDP keepalives على كلا جانبي الاتصال للحفاظ على اتصال على قيد الحياة.
ضع في اعتبارك أنماط إعادة المحاولة بأمان لتجنب عمليات إعادة المحاولة والاندفاعات العدوانية أثناء الفشل العابر أو استرداد الفشل. بالنسبة للاتصالات الذرية المضادة للتشتت، يمكنك إنشاء اتصال TCP جديد لكل عملية HTTP. تهدر الاتصالات الذرية الموارد وتمنع تطبيقك من التحجيم بشكل جيد.
لزيادة سرعة المعاملة وتقليل تكاليف الموارد للتطبيق الخاص بك، قم دائما بتدفق عمليات متعددة إلى نفس الاتصال. عندما يستخدم تطبيقك تشفير طبقة النقل، على سبيل المثال TLS، تزيد معالجة الاتصال الجديدة من التكلفة. لمزيد من أنماط أفضل الممارسات، راجع أنماط تصميم سحابة Azure.
التميز التشغيلي
يمكنك استخدام بوابة NAT مع خدمة Azure Kubernetes (AKS)، ولكن إدارة بوابة NAT غير مضمنة في AKS. إذا قمت بتعيين بوابة NAT إلى الشبكة الفرعية لواجهة شبكة الحاوية (CNI)، يمكنك تمكين حاويات AKS للخروج من خلال بوابة NAT.
عند استخدام بوابات NAT متعددة عبر المناطق أو المناطق، احتفظ بملكية IP الصادرة قابلة للإدارة باستخدام بادئات IP العامة Azure أو إحضار بادئات IP الخاصة بك (BYOIP). لا يمكنك تعيين حجم بادئة IP أكبر من 16 عنوان IP (/28 حجم بادئة) إلى بوابة NAT.
استخدم تنبيهات Azure Monitor لمراقبة وتنبيه استخدام منفذ SNAT، والحزم المعالجة أو التي تم إسقاطها، وكمية البيانات المرسلة. استخدم سجلات تدفق مجموعة أمان الشبكة (NSG) لمراقبة تدفق نسبة استخدام الشبكة الصادرة من مثيلات الجهاز الظاهري (VM) في شبكة فرعية مكونة من بوابة NAT.
عند تكوين شبكة فرعية ببوابة NAT، تحل بوابة NAT محل جميع الاتصالات الصادرة الأخرى بالإنترنت العام لجميع الأجهزة الظاهرية على تلك الشبكة الفرعية. تكون لبوابة NAT الأسبقية على موازن التحميل، بغض النظر عن القواعد الصادرة. البوابة أيضا لها الأسبقية على عناوين IP العامة التي يتم تعيينها مباشرة إلى الأجهزة الظاهرية. يتتبع Azure اتجاه التدفق ويمنع التوجيه غير المتماثل. تتم ترجمة نسبة استخدام الشبكة الواردة، مثل عنوان IP للواجهة الأمامية لموازن التحميل، بشكل صحيح، ويتم ترجمتها بشكل منفصل عن حركة المرور الصادرة من خلال بوابة NAT. يسمح هذا الفصل بين الخدمات الواردة والصادرة بالتعايش بسلاسة.
نوصي ببوابة NAT كبوابة افتراضية لتمكين الاتصال الصادر للشبكات الظاهرية. توفر بوابة NAT الكفاءة والبساطة التشغيلية مقارنة بتقنيات الاتصال الصادرة الأخرى في Azure. تخصص بوابات NAT منافذ SNAT عند الطلب وتستخدم خوارزمية أكثر كفاءة لمنع تعارضات إعادة استخدام منفذ SNAT. لا تعتمد على الاتصال الصادر الافتراضي المضاد للتركة الخاصة بك. بدلا من ذلك، حدد التكوين بشكل صريح باستخدام موارد بوابة NAT.
الموثوقيه
تتوفر موارد بوابة NAT بشكل كبير في منطقة توفر واحدة وتمتد عبر مجالات خطأ متعددة. يمكنك نشر بوابة NAT إلى أي منطقة حيث يقوم Azure تلقائيا بتحديد منطقة لوضع بوابة NAT أو عزل بوابة NAT إلى منطقة توفر معينة.
لتوفير عزل منطقة التوفر، يجب أن يكون لكل شبكة فرعية موارد داخل منطقة معينة فقط. لتنفيذ هذا النهج، يمكنك:
- نشر شبكة فرعية لكل منطقة من مناطق التوفر حيث يتم نشر الأجهزة الظاهرية.
- محاذاة الأجهزة الظاهرية النطاقية مع بوابات NAT المحلية المطابقة.
- إنشاء مكدسات مناطقية منفصلة.
في الرسم التخطيطي التالي، يوجد جهاز ظاهري في منطقة التوفر 1 على شبكة فرعية مع موارد أخرى موجودة أيضا في منطقة التوفر 1 فقط. يتم تكوين بوابة NAT في منطقة التوفر 1 لخدمة تلك الشبكة الفرعية.
تمتد الشبكات الظاهرية والشبكات الفرعية إلى جميع مناطق التوفر في منطقة ما. لا تحتاج إلى تقسيمها حسب مناطق التوافر لاستيعاب الموارد المناطقية.
الأمان
باستخدام بوابة NAT، لا تحتاج الأجهزة الظاهرية الفردية أو موارد الحوسبة الأخرى إلى عناوين IP عامة ويمكن أن تظل خاصة بالكامل. لا يزال بإمكان الموارد التي لا تحتوي على عنوان IP عام الوصول إلى مصادر خارجية خارج الشبكة الظاهرية. يمكنك إقران بادئة IP عامة للتأكد من استخدام مجموعة متقاربة من عناوين IP للاتصال الصادر. يمكنك تكوين قواعد جدار الحماية الوجهة استنادا إلى قائمة IP القابلة للتنبؤ هذه.
يتمثل النهج الشائع في تصميم سيناريو جهاز ظاهري للشبكة الصادرة فقط (NVA) باستخدام جدران الحماية غير التابعة ل Microsoft أو مع خوادم الوكيل. عند نشر بوابة NAT إلى شبكة فرعية مع مجموعة مقياس جهاز ظاهري من NVAs، تستخدم NVAs عنوان بوابة NAT واحد أو أكثر للاتصال الصادر بدلا من عنوان IP لموازن التحميل أو عناوين IP الفردية. لاستخدام هذا السيناريو مع Azure Firewall، راجع تكامل Azure Firewall مع موازن التحميل القياسي Azure.
يمكنك استخدام ميزة تنبيه Microsoft Defender for Cloud لمراقبة أي اتصال صادر مريب في بوابة NAT.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- إيثان هازليت | مهندس حلول سحابي أول
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
- Microsoft Well-Architected Framework
- البرنامج التعليمي: إنشاء بوابة NAT باستخدام مدخل Azure
- التوصيات لاستخدام مناطق التوفر والمناطق