توفر هذه المقالة أفضل الممارسات لبوابة Azure NAT. تستند الإرشادات إلى الركائز الخمس لتميز البنية: تحسين التكلفة، والتميز التشغيلي، وكفاءة الأداء، والموثوقية، والأمان.
نفترض أن لديك معرفة عملية ببوابة Azure NAT وأنك على دراية جيدة بالميزات المعنية. كتحديث، راجع المجموعة الكاملة من وثائق Azure NAT Gateway.
يرمز NAT إلى ترجمة عناوين الشبكة. راجع مقدمة حول ترجمة عناوين الشبكة.
تحسين التكلفة
يجب أن يكون الوصول إلى خدمات PaaS من خلال Azure Private Link أو نقاط نهاية الخدمة (بما في ذلك التخزين)، لتجنب استخدام بوابة NAT. لا يتطلب Private Link ونقاط نهاية الخدمة اجتياز بوابة NAT للوصول إلى خدمات PaaS. سيؤدي هذا الأسلوب إلى تقليل الرسوم لكل جيجابت من البيانات المعالجة، عند مقارنة تكاليف بوابة NAT بـ Private Link أو بنقاط نهاية الخدمة. هناك فوائد أمان إضافية لاستخدام Private Link أو نقاط نهاية الخدمة.
كفاءة الأداء
يقوم كل مورد من موارد بوابة NAT بتوفير ما يصل إلى 50 جيجابت في الثانية من معدل النقل. يمكنك تقسيم عمليات التوزيع إلى شبكات فرعية متعددة ويمكنك حينها تعيين بوابة NAT لكل شبكة فرعية أو مجموعة من الشبكات الفرعية لتوسيع نطاقها.
يوفر كل عنوان IP عام لبوابة NAT منفذًا من منافذ 64,512 SNAT. يمكن تعيين ما يصل إلى 16 عنوان IP إلى بوابة NAT. يمكن أن تكون عناوين IP عبارة عن عناوين IP عامة قياسية فردية أو بادئة IP العامة أو كليهما. بالنسبة للاتصالات التي تنتقل إلى نفس نقطة نهاية الوجهة، يمكن أن تدعم بوابة NAT ما يصل إلى 50000 تدفق متزامن لـ TCP وUDP على التوالي، لكل عنوان IP صادر معين. راجع القسم التالي في ترجمة عنوان الشبكة المصدر (SNAT) للحصول على التفاصيل. يرمز TCP إلى بروتوكول تحكم الإرسال، ويرمز UDP إلى بروتوكول مخطط بيانات المستخدم.
استهلاك SNAT
- تحتوي موارد بوابة NAT على مهلة خمول TCP افتراضية تبلغ 4 دقائق يمكن تهيئتها حتى 120 دقيقة. إذا تم تغيير هذا الإعداد إلى قيمة أعلى من القيمة الافتراضية، فستحتفظ بوابة NAT بالتدفقات لفترة أطول ويمكن أن تسبب ضغطا غير ضروري على مخزون منفذ SNAT.
- الطلبات الذرية (طلب واحد لكل اتصال) هي اختيار تصميم رديء، لأنها تحد من تغيّر الحجم، وتقلل من الأداء، وتقلل من الموثوقية. بدلًا من ذلك، إعادة استخدام اتصالات HTTP/S لتقليل عدد الاتصالات ومنافذ SNAT المقترنة. ستسمح إعادة استخدام الاتصال للتطبيق بتغيير الحجم بشكل أفضل. سيتحسن أداء التطبيق، بسبب انخفاض تأكيدات الاتصال والنفقات العامة وتكاليف عمليات التشفير عند استخدام TLS.
- يمكن أن تقدم عمليات بحث نظام أسماء المجالات (DNS) العديد من التدفقات الفردية في وحدة التخزين، عندما لا يقوم العميل بالتخزين المؤقت لنتيجة محللات DNS. استخدم التخزين DNS المؤقت لتقليل حجم التدفقات وتقليل عدد منافذ SNAT. DNS هو نظام التسمية الذي يعين أسماء المجالات إلى عناوين IP للموارد المتصلة بالإنترنت أو بشبكة خاصة.
- تستخدم تدفقات UDP، مثل عمليات بحث DNS، منافذ SNAT أثناء مهلة الخمول. تم تثبيت مؤقت مهلة الخمول UDP على 4 دقائق ولا يمكن تغييره.
- استخدم تجمعات اتصالات لتشكيل حجم الاتصال.
- لا تتخلى عن تدفق TCP بشكل صامت وتعتمد على مؤقت TCP لتنظيف التدفق. إذا لم تسمح لـ TCP بإغلاق الاتصال بشكل صريح، سيبقى اتصال TCP مفتوحًا. ستبقي الأنظمة الوسيطة ونقاط النهاية هذا الاتصال قيد الاستخدام، ما يجعل منفذ SNAT بدوره غير متوفر للاتصالات الأخرى. يمكن أن يؤدي هذا النمط المضاد إلى فشل التطبيق واستنفاد SNAT.
- لا تقم بتغيير قيم المؤقت ذات الصلة بإغلاق TCP على مستوى نظام التشغيل، دون معرفة كبيرة بالتأثير. أثناء استرداد مكدس TCP، يمكن أن يتأثر أداء التطبيق بشكل سلبي عندما يكون لدى نقاط النهاية للاتصال توقعات غير متطابقة. عادةً ما يكون تغيير قيم المؤقت علامة على وجود مشكلة أساسية في التصميم. إذا كان التطبيق الأساسي يحتوي على أنماط مضادة أخرى، يمكن أيضًا تضخيم استنفاد SNAT إذا تم تغيير قيم المؤقت.
راجع الإرشادات التالية لتحسين نطاق وموثوقية الخدمة:
- استكشف تأثير تقليل مهلة الخمول TCP إلى قيم أقل. يمكن لمهلة الخمول الافتراضية التي تبلغ 4 دقائق تحرير مخزون منفذ SNAT في وقت أَبْكَر.
- ضع في الاعتبار أنماط الاستقصاء غير المتزامنة للعمليات طويلة المدى لتحرير موارد الاتصال لعمليات أخرى.
- يجب أن تستخدم التدفقات طويلة الأمد، مثل اتصالات TCP المعاد استخدامها، استمرار تشغيل TCP أو استمرار تشغيل طبقة التطبيق لتجنب مهلة الأنظمة الوسيطة. ما عليك إلا زيادة مهلة الخمول كحل أخير، وقد لا تحل السبب الجذري. يمكن أن تتسبب المهلة الطويلة في فشل المعدل المنخفض، عند انتهاء المهلة، ويمكن أن تؤدي إلى تأخير وإخفاقات غير ضرورية. يمكن تمكين استمرار تشغيل TCP من جانب واحد من الاتصال من أجل الحفاظ على استمرار الاتصال من كلا الجانبين.
- بالنسبة للتدفقات طويلة الأمد مع حركة مرور UDP، يمكنك تمكين استمرار تشغيل UDP للحفاظ على استمرار الاتصال. ضع في اعتبارك أن جعل استمرار تشغيل UDP ممكن من جانب واحد من الاتصال يبقي الاتصال نشطًا من جانب واحد فقط. ينبغي تمكين استمرار تشغيل UDP من كلا جانبي الاتصال من أجل الحفاظ على الاتصال نشطًا.
- يجب استخدام أنماط إعادة المحاولة بأمان لتجنب عمليات إعادة المحاولة/الاندفاعات العدوانية أثناء الفشل العابر أو استرداد الفشل. يحدث النمط المضاد، المسمى الاتصالات الذرية، عند إنشاء اتصال TCP جديد لكل عملية HTTP. ستمنع الاتصالات الذرية تطبيقك من التوسع بشكل جيد وستهدر الموارد. قم دائمًا بتوجيه عمليات متعددة في نفس الاتصال. سيستفيد تطبيقك في سرعة المعاملات وتكاليف الموارد. عندما يستخدم تطبيقك تشفير طبقة النقل (على سبيل المثال، TLS)، هناك تكلفة كبيرة مرتبطة بمعالجة الاتصالات الجديدة. راجع أنماط تصميم السحابة من Azure للحصول على المزيد من أنماط أفضل الممارسات.
التميز التشغيلي
على الرغم من أنه يمكن استخدام بوابة NAT مع Azure Kubernetes Service، إلا أنها لا تتم إدارتها كجزء من AKS. إذا قمت بتعيين بوابة NAT إلى الشبكة الفرعية لواجهة شبكة الحاوية (CNI)، فستمكن حاويات AKS من الخروج من خلال بوابة NAT.
عند استخدام بوابات NAT متعددة عبر المناطق أو عبر الأقاليم، احتفظ بملكية عناوين IP الصادرة القابلة للإدارة باستخدام بادئات Azure Public IP أو بادئات BYOIP. لا يمكن تعيين حجم بادئة IP أكبر من 16 عنوان IP (حجم بادئة /28) إلى بوابة NAT.
استخدم تنبيهات Azure Monitor لمراقبة وتنبيه استخدام منفذ SNAT، والحزم التي تم معالجتها أو التي تم إسقاطها، وكمية البيانات المرسلة. استخدم سجلات تدفق NSG لمراقبة تدفق نسبة استخدام الشبكة الصادرة من مثيلات الجهاز الظاهري في شبكة فرعية مكونة من بوابة 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 لخدمة تلك الشبكة الفرعية. اطلع على الرسم التخطيطي التالي.
تمتد الشبكات الظاهرية والشبكات الفرعية إلى جميع مناطق التوفر في منطقة ما. لا تحتاج إلى تقسيمها حسب مناطق التوافر لاستيعاب الموارد المناطقية.
Security
باستخدام بوابة NAT لا تحتاج الأجهزة الظاهرية الفردية (أو موارد الحوسبة الأخرى)، إلى عناوين IP عامة ويمكن أن تظل خاصة. لا يزال بإمكان الموارد التي لا تحتوي على عنوان IP عام الوصول إلى مصادر خارجية خارج الشبكة الظاهرية. يمكنك إقران بادئة IP عامة للتأكد من استخدام مجموعة متقاربة من عناوين IP للاتصال الصادر. يمكن تكوين قواعد جدار الحماية الوجهة بناءً على قائمة IP التي يمكن التنبؤ بها.
يتمثل النهج الشائع في تصميم سيناريو الجهاز الظاهري للشبكة الصادرة فقط (NVA) باستخدام جدران الحماية التابعة لجهة خارجية أو مع خوادم الوكيل. عند نشر بوابة NAT إلى شبكة فرعية مع مجموعة مقياس جهاز ظاهري من الأجهزة الظاهري للشبكة، ستستخدم تلك الأجهزة الظاهري للشبكة عنوان بوابة NAT للاتصال الصادر، على عكس IP لموازن التحميل أو عناوين IP الفردية. لاستخدام هذا السيناريو مع Azure Firewall، راجع تكامل Azure Firewall مع Azure Standard Load Balancer.
يمكن لـ Microsoft Defender for Cloud مراقبة أي اتصال صادر مشبوه من خلال بوابة NAT. هذه إحدى ميزات التنبيه في Microsoft Defender for Cloud.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- إيثان هازليت | مهندس حلول سحابي أول
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.