نظرة عامة على الشبكات لقاعدة بيانات Azure ل PostgreSQL - خادم مرن
توضح هذه المقالة مفاهيم الاتصال والشبكات لقاعدة بيانات Azure ل PostgreSQL - خادم مرن.
عند إنشاء قاعدة بيانات Azure ل PostgreSQL - مثيل خادم مرن ( خادم مرن)، يجب عليك اختيار أحد خيارات الشبكة التالية: الوصول الخاص (تكامل VNet ) أو الوصول العام (عناوين IP المسموح بها).
ملاحظة
لا يمكنك تغيير خيار الشبكة بعد إنشاء الخادم.
تنطبق الخصائص التالية سواء اخترت استخدام الوصول الخاص أو خيار الوصول العام:
- تحتاج الاتصالات من عناوين IP المسموح بها إلى المصادقة على خادم PostgreSQL باستخدام بيانات اعتماد صالحة.
- يتم فرض تشفير الاتصال لحركة مرور الشبكة.
- يحتوي الخادم على اسم نطاق مؤهل بالكامل (FQDN). بالنسبة للخاصية
hostnameفي سلاسل الاتصال، نوصي باستخدام FQDN بدلا من عنوان IP. - يتحكم كلا الخيارين في الوصول على مستوى الخادم، وليس على مستوى قاعدة البيانات أو الجدول. يمكنك استخدام خصائص أدوار PostgreSQL للتحكم في قاعدة البيانات والجدول والوصول إلى الكائنات الأخرى.
ملاحظة
نظرا لأن قاعدة بيانات Azure ل PostgreSQL هي خدمة قاعدة بيانات مدارة، لا يتم تزويد المستخدمين بالوصول إلى المضيف أو نظام التشغيل لعرض ملفات التكوين أو تعديلها مثل pg_hba.conf. يتم تحديث محتوى الملفات تلقائيا استنادا إلى إعدادات الشبكة.
الوصول الخاص (تكامل VNet)
يمكنك نشر خادم مرن في شبكة Azure الظاهرية (VNet). تساعد شبكات Azure الظاهرية على توفير اتصال شبكة خاص وآمن. يمكن للموارد الموجودة في شبكة ظاهرية الاتصال من خلال عناوين IP الخاصة التي تم تعيينها على هذه الشبكة.
حدد خيار الشبكة هذا إذا كنت تريد الإمكانات التالية:
- الاتصال من موارد Azure في نفس الشبكة الظاهرية إلى خادمك المرن باستخدام عناوين IP خاصة.
- استخدم VPN أو Azure ExpressRoute للاتصال من موارد غير Azure بخادمك المرن.
- تأكد من أن الخادم المرن لا يحتوي على نقطة نهاية عامة يمكن الوصول إليها عبر الإنترنت.
في الرسم التخطيطي السابق:
- يتم حقن الخوادم المرنة في الشبكة الفرعية 10.0.1.0/24 من الشبكة الظاهرية VNet-1.
- يمكن للتطبيقات التي يتم نشرها على شبكات فرعية مختلفة داخل نفس الشبكة الافتراضية الوصول إلى خوادم مرنة مباشرة.
- لا تتمتع التطبيقات التي يتم نشرها على شبكة ظاهرية مختلفة (VNet-2) بإمكانية الوصول المباشر إلى خوادم مرنة. يجب عليك إجراء نظير الشبكة الظاهرية لمنطقة DNS خاصة قبل أن يتمكنوا من الوصول إلى الخادم المرن.
مفاهيم الشبكة الافتراضية
تحتوي شبكة Azure الظاهرية على مساحة عنوان IP خاصة تم تكوينها لاستخدامك. يجب أن تكون شبكتك الظاهرية في نفس منطقة Azure مثل الخادم المرن. لمعرفة المزيد حول الشبكات الظاهرية، راجع نظرة عامة على شبكة Azure الظاهرية.
فيما يلي بعض المفاهيم التي يجب أن تكون على دراية بها عند استخدام الشبكات الافتراضية مع خوادم PostgreSQL المرنة:
الشبكة الفرعية المفوضة. تحتوي الشبكة الظاهرية على شبكات فرعية (شبكات فرعية). تمكنك الشبكات الفرعية من تقسيم شبكتك الافتراضية إلى مساحات عناوين أصغر. يتم نشر موارد Azure في شبكات فرعية محددة داخل شبكة ظاهرية.
يجب أن يكون الخادم المرن في شبكة فرعية مفوضة. أي أن قاعدة بيانات Azure فقط لمثيلات PostgreSQL - Flexible Server يمكنها استخدام هذه الشبكة الفرعية. لا يمكن أن تكون أي أنواع موارد Azure أخرى في الشبكة الفرعية المفوضة. تقوم بتفويض شبكة فرعية عن طريق تعيين خاصية التفويض الخاصة بها ك
Microsoft.DBforPostgreSQL/flexibleServers. أصغر نطاق CIDR يمكنك تحديده لشبكة فرعية هو /28 ، والذي يوفر أربعة عشر عنوان IP ، ولكن لا يمكن تعيين العنوان الأول والأخير في أي شبكة أو شبكة فرعية لأي مضيف فردي. يحتفظ Azure بخمسة عناوين IP لاستخدامها داخليا بواسطة شبكات Azure، والتي تتضمن اثنين من عناوين IP التي لا يمكن تعيينها للمضيف، المذكورة أعلاه. هذا يترك لك أحد عشر عنوان IP متاحا ل /28 نطاق CIDR ، في حين أن خادما مرنا واحدا مع ميزات التوفر العالي يستخدم 4 عناوين.هام
الأسماء
AzureFirewallSubnet، ،AzureBastionSubnet،AzureFirewallManagementSubnetويتمGatewaySubnetحجزها داخل Azure. لا تستخدم أيا من هذه كاسم الشبكة الفرعية الخاصة بك.مجموعة أمن الشبكات (NSG). تمكنك قواعد الأمان في NSGs من تصفية نوع حركة مرور الشبكة التي يمكن أن تتدفق داخل وخارج الشبكات الفرعية للشبكة الافتراضية وواجهات الشبكة. لمزيد من المعلومات، راجع نظرة عامة على مجموعة موردي المواد النووية.
تسهل مجموعات أمان التطبيقات (ASGs) التحكم في أمان الطبقة 4 باستخدام NSGs للشبكات المسطحة. يمكنك بسرعة:
- ضم الأجهزة الظاهرية إلى ASG، أو إزالة الأجهزة الظاهرية من ASG.
- تطبيق القواعد ديناميكيا على تلك الأجهزة الظاهرية، أو إزالة القواعد من تلك الأجهزة الظاهرية.
لمزيد من المعلومات، راجع نظرة عامة على ASG.
في الوقت الحالي، لا ندعم NSGs حيث يكون ASG جزءا من القاعدة مع قاعدة بيانات Azure ل PostgreSQL - الخادم المرن. ننصح حاليا باستخدام تصفية المصدر أو الوجهة المستندة إلى IP في NSG.
هام
ميزات عالية التوفر لقاعدة بيانات Azure ل PostgreSQL - يتطلب الخادم المرن القدرة على إرسال/استقبال حركة المرور إلى منافذ الوجهة 5432، 6432 داخل الشبكة الفرعية لشبكة Azure الظاهرية حيث يتم نشر قاعدة بيانات Azure ل PostgreSQL - خادم مرن، وكذلك إلى تخزين Azure لأرشفة السجلات. إذا قمت بإنشاء مجموعات أمان الشبكة (NSG) لرفض تدفق حركة المرور من أو إلى قاعدة بيانات Azure ل PostgreSQL - خادم مرن داخل الشبكة الفرعية حيث تم نشرها، فيرجى التأكد من السماح بحركة المرور إلى منافذ الوجهة 5432 و6432 داخل الشبكة الفرعية، وكذلك إلى تخزين Azure باستخدام علامة الخدمة Azure Storage كوجهة.
تكامل منطقة DNS الخاصة. يسمح لك تكامل منطقة DNS الخاصة في Azure بحل DNS الخاص داخل الشبكة الظاهرية الحالية أو أي شبكة ظاهرية نظيرة داخل المنطقة حيث يتم ربط منطقة DNS الخاصة.
استخدام منطقة DNS خاصة
إذا كنت تستخدم مدخل Azure أو Azure CLI لإنشاء خوادم مرنة مع شبكة ظاهرية، توفير منطقة DNS خاصة جديدة تلقائيا لكل خادم في اشتراكك باستخدام اسم الخادم الذي قدمته.
إذا كنت تستخدم واجهة برمجة تطبيقات Azure أو قالب Azure Resource Manager (قالب ARM) أو Terraform، فقم بإنشاء مناطق DNS خاصة تنتهي ب .postgres.database.azure.com. استخدم هذه المناطق أثناء تكوين خوادم مرنة مع وصول خاص. على سبيل المثال، استخدم النموذج [name1].[name2].postgres.database.azure.com أو [name].postgres.database.azure.com. إذا اخترت استخدام النموذج [name].postgres.database.azure.com، فلا يمكن أن يكون الاسم هو الاسم الذي تستخدمه لأحد خوادمك المرنة أو ستظهر رسالة خطأ أثناء إدارة الحسابات. لمزيد من المعلومات، راجع نظرة عامة على مناطق DNS الخاصة.
عند استخدام الوصول إلى الشبكة الخاصة مع شبكة Azure الظاهرية، يكون توفير معلومات منطقة DNS الخاصة إلزاميا عبر واجهات مختلفة، بما في ذلك واجهة برمجة التطبيقات وARM وTerraform. لذلك، بالنسبة لقاعدة بيانات Azure الجديدة لإنشاء خادم PostgreSQL المرن باستخدام الوصول إلى الشبكة الخاصة باستخدام واجهة برمجة التطبيقات أو ARM أو Terraform، قم بإنشاء مناطق DNS خاصة واستخدمها أثناء تكوين خوادم مرنة مع وصول خاص. راجع مزيد من المعلومات حول مواصفات واجهة برمجة تطبيقات REST ل Microsoft Azure. إذا كنت تستخدم مدخل Azure أو Azure CLI لإنشاء خوادم مرنة، فيمكنك إما توفير اسم منطقة DNS خاص قمت بإنشائه مسبقا في نفس الاشتراك أو اشتراك مختلف أو إنشاء منطقة DNS خاصة افتراضية تلقائيا في اشتراكك.
باستخدام Azure Portal أو CLI أو ARM، يمكنك أيضا تغيير منطقة DNS الخاصة من المنطقة التي قدمتها عند إنشاء قاعدة بيانات Azure ل PostgreSQL - خادم مرن إلى منطقة DNS خاصة أخرى موجودة بنفس الاشتراك أو اشتراك مختلف.
التكامل مع خادم DNS مخصص
إذا كنت تستخدم خادم DNS مخصصا، فيجب عليك استخدام معيد توجيه DNS لحل FQDN لقاعدة بيانات Azure ل PostgreSQL - خادم مرن. يجب أن يكون عنوان IP الخاص بمعيد التوجيه هو 168.63.129.16.
يجب أن يكون خادم DNS المخصص داخل الشبكة الظاهرية أو يمكن الوصول إليه عبر إعداد خادم DNS الخاص بالشبكة الافتراضية. لمعرفة المزيد، راجع دقة الاسم التي تستخدم خادم DNS الخاص بك.
منطقة DNS الخاصة ونظير الشبكة الافتراضية
إعدادات منطقة DNS الخاصة ونظير الشبكة الظاهرية مستقلة عن بعضها البعض. إذا كنت ترغب في الاتصال بالخادم المرن من عميل تم توفيره في شبكة ظاهرية أخرى من نفس المنطقة أو منطقة مختلفة، فيجب عليك ربط منطقة DNS الخاصة بالشبكة الظاهرية. لمزيد من المعلومات، راجع ربط الشبكة الظاهرية.
ملاحظة
يمكن فقط ربط أسماء مناطق DNS الخاصة التي تنتهي postgres.database.azure.com بها. لا يمكن أن يكون اسم منطقة DNS الخاص بك هو نفسه الخادم (الخوادم) المرنة وإلا ستفشل دقة الاسم.
سيناريوهات الشبكة الظاهرية غير المعتمدة
فيما يلي بعض القيود المفروضة على العمل مع الشبكات الافتراضية:
- لا يمكن أن يحتوي الخادم المرن الذي يتم نشره على شبكة ظاهرية على نقطة نهاية عامة (أو IP أو DNS عام).
- بعد نشر خادم مرن على شبكة ظاهرية وشبكة فرعية، لا يمكنك نقله إلى شبكة افتراضية أو شبكة فرعية أخرى. لا يمكنك نقل الشبكة الظاهرية إلى مجموعة موارد أو اشتراك آخر.
- لا يمكن زيادة حجم الشبكة الفرعية (مساحات العناوين) بعد وجود الموارد في الشبكة الفرعية.
- لا يدعم الخادم المرن Azure Private Link. بدلا من ذلك ، فإنه يستخدم حقن الشبكة الافتراضية لجعل الخادم المرن متاحا داخل شبكة افتراضية.
هام
يدعم Azure Resource Manager القدرة على تأمين الموارد، كعنصر تحكم أمني. يتم تطبيق تأمين الموارد على المورد، وهي فعالة عبر كافة المستخدمين والأدوار. هناك نوعان من تأمين المورد: CanNotDelete و ReadOnly. يمكن تطبيق أنواع التأمين هذه إما على منطقة DNS خاصة أو على مجموعة سجلات فردية. قد يتداخل تطبيق قفل من أي نوع مقابل منطقة DNS الخاصة أو مجموعة سجلات فردية مع قدرة قاعدة بيانات Azure ل PostgreSQL - خدمة الخادم المرن على تحديث سجلات DNS والتسبب في حدوث مشكلات أثناء العمليات المهمة على DNS، مثل تجاوز فشل التوفر العالي من الأساسي إلى الثانوي. يرجى التأكد من أنك لا تستخدم منطقة DNS الخاصة أو أقفال السجلات عند استخدام ميزات التوافر العالي مع قاعدة بيانات Azure ل PostgreSQL - خادم مرن.
الوصول العام (عناوين IP المسموح بها)
عند اختيار طريقة الوصول العام، يتم الوصول إلى الخادم المرن من خلال نقطة نهاية عامة عبر الإنترنت. نقطة النهاية العامة عنوان DNS عام قابل للحل. تشير العبارة المسموح بها عناوين IP إلى مجموعة من عناوين IP التي تختارها لمنح الإذن للوصول إلى الخادم الخاص بك. تسمى هذه الأذونات قواعد جدار الحماية.
حدد خيار الشبكة هذا إذا كنت تريد الإمكانات التالية:
- الاتصال من موارد Azure التي لا تدعم الشبكات الظاهرية.
- الاتصال من موارد خارج Azure غير متصلة بواسطة VPN أو ExpressRoute.
- تأكد من أن الخادم المرن يحتوي على نقطة نهاية عامة يمكن الوصول إليها عبر الإنترنت.
تشمل خصائص طريقة الوصول العام ما يلي:
- فقط عناوين IP التي تسمح بها لديها إذن للوصول إلى خادم PostgreSQL المرن. بشكل افتراضي، لا يسمح بعناوين IP. يمكنك إضافة عناوين IP أثناء إنشاء الخادم أو بعده.
- يحتوي خادم PostgreSQL على اسم DNS قابل للحل بشكل عام.
- الخادم المرن الخاص بك ليس في إحدى شبكات Azure الظاهرية.
- حركة مرور الشبكة من وإلى الخادم الخاص بك لا تمر عبر شبكة خاصة. تستخدم حركة المرور مسارات الإنترنت العامة.
قواعد جدار الحماية
إذا كانت محاولة الاتصال تأتي من عنوان IP لم تسمح به من خلال قاعدة جدار حماية، فسيتلقى العميل الأصلي خطأ.
السماح بجميع عناوين IP الخاصة ب Azure
إذا لم يكن عنوان IP الصادر الثابت متاحا لخدمة Azure الخاصة بك، فيمكنك التفكير في تمكين الاتصالات من جميع عناوين IP لمراكز بيانات Azure.
هام
يقوم الخيار السماح بالوصول العام من خدمات Azure وموارده داخل Azure بتكوين جدار الحماية للسماح بجميع الاتصالات من Azure، بما في ذلك الاتصالات من اشتراكات العملاء الآخرين. عند تحديد هذا الخيار، تأكد من أن أذونات تسجيل الدخول والمستخدم تقصر الوصول على المستخدمين المصرح لهم فقط.
استكشاف مشكلات الوصول العام وإصلاحها
ضع في اعتبارك النقاط التالية عند عدم تصرف الوصول إلى قاعدة بيانات Azure لخدمة PostgreSQL كما تتوقع:
التغييرات التي تطرأ على القائمة المسموح بها لم تدخل حيز التنفيذ بعد. قد يكون هناك تأخير لمدة تصل إلى خمس دقائق للتغييرات التي تطرأ على تكوين جدار الحماية لقاعدة بيانات Azure لخادم PostgreSQL لتصبح سارية المفعول.
فشلت المصادقة. إذا لم يكن لدى المستخدم أذونات على قاعدة بيانات Azure لخادم PostgreSQL أو كانت كلمة المرور غير صحيحة، رفض الاتصال بقاعدة بيانات Azure لخادم PostgreSQL. لا يوفر إنشاء إعداد جدار حماية للعملاء سوى فرصة لمحاولة الاتصال بالخادم الخاص بك. لا يزال يتعين على كل عميل توفير بيانات اعتماد الأمان اللازمة.
عنوان IP الديناميكي للعميل يمنع الوصول. إذا كان لديك اتصال بالإنترنت باستخدام عنوان IP ديناميكي وكنت تواجه مشكلة في الوصول إلى جدار الحماية، فجرب أحد الحلول التالية:
- اسأل موفر خدمة الإنترنت (ISP) عن نطاق عنوان IP المعين لأجهزة الكمبيوتر العميلة التي تصل إلى قاعدة بيانات Azure لخادم PostgreSQL. ثم أضف نطاق عنوان IP كقاعدة جدار حماية.
- احصل على عنوان IP ثابت بدلا من ذلك لأجهزة الكمبيوتر العميلة، ثم أضف عنوان IP الثابت كقاعدة جدار حماية.
قاعدة جدار الحماية غير متوفرة لتنسيق IPv6. يجب أن تكون قواعد جدار الحماية بتنسيق IPv4. إذا قمت بتحديد قواعد جدار الحماية بتنسيق IPv6، فستحصل على خطأ في التحقق من الصحة.
اسم المضيف
بغض النظر عن خيار الشبكة الذي تختاره، نوصي دائما باستخدام FQDN كاسم مضيف عند الاتصال بالخادم المرن. لا يضمن عنوان IP الخاص بالخادم أن يظل ثابتا. سيساعدك استخدام FQDN على تجنب إجراء تغييرات على سلسلة الاتصال.
مثال يستخدم FQDN كاسم مضيف هو hostname = servername.postgres.database.azure.com. حيثما أمكن، تجنب استخدام hostname = 10.0.0.4 (عنوان خاص) أو hostname = 40.2.45.67 (عنوان عام).
TLS و SSL
قاعدة بيانات Azure ل PostgreSQL - يفرض الخادم المرن توصيل تطبيقات العميل بخدمة PostgreSQL باستخدام أمان طبقة النقل (TLS). TLS هو بروتوكول قياسي في الصناعة يضمن اتصالات الشبكة المشفرة بين خادم قاعدة البيانات وتطبيقات العميل. TLS هو بروتوكول محدث لطبقة المقابس الآمنة (SSL).
تدعم قاعدة بيانات Azure ل PostgreSQL TLS 1.2 والإصدارات الأحدث. في RFC 8996، تنص فرقة عمل هندسة الإنترنت (IETF) صراحة على أنه يجب عدم استخدام TLS 1.0 وTLS 1.1. تم إهمال كلا البروتوكولين بحلول نهاية عام 2019.
سيتم رفض جميع الاتصالات الواردة التي تستخدم إصدارات سابقة من بروتوكول TLS، مثل TLS 1.0 وTLS 1.1، بشكل افتراضي.
ملاحظة
تشهد شهادات SSL وTLS على أن اتصالك مؤمن باستخدام أحدث بروتوكولات التشفير. من خلال تشفير اتصالك على السلك ، فإنك تمنع الوصول غير المصرح به إلى بياناتك أثناء النقل. لهذا السبب نوصي بشدة باستخدام أحدث إصدارات TLS لتشفير اتصالاتك بقاعدة بيانات Azure ل PostgreSQL - الخادم المرن. على الرغم من أنه غير مستحسن، إذا لزم الأمر، لديك خيار لتعطيل TLS\SSL للاتصالات بقاعدة بيانات Azure ل PostgreSQL - خادم مرن عن طريق تحديث معلمة خادم require_secure_transport إلى OFF. يمكنك أيضا تعيين إصدار TLS عن طريق تعيين معلمات خادم ssl_min_protocol_version ssl_max_protocol_version .