إعداد GatewaySubnet في Azure: احجز النطاق قبل البوابة

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

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

ابدأ بمساحة العناوين

اكتب بادئة الشبكة الظاهرية والشبكات الفرعية لأحمال العمل وحجز البوابة في سطر واحد قبل كتابة أي شيء. الشبكة الظاهرية على 10.60.0.0/16 لديها مساحة؛ اختر نطاقًا في النهاية كي يبقى نمو أحمال العمل متصلاً.

على سبيل المثال، يترك 10.60.255.192/26 64 عنوانًا للبوابة بينما تبقى أحمال العمل في 10.60.0.0/20. هذا مثال على تخطيط العناوين، وليس وعدًا بالحجم. تشترط Microsoft حاليًا /27 أو أكبر لبوابات VPN غير الأساسية، حيث يعني الأكبر عناوين أكثر: يمنح /26 عددًا قدره 64، بينما يمنح /28 عددًا قدره 16. قرّب إلى الأعلى، لا إلى الأسفل أبدًا، ما دام مخطط العناوين قيد التعديل.

أنشئ الشبكة الفرعية بالاسم الدقيق

في المدخل، أضف شبكة فرعية واكتب الاسم GatewaySubnet تمامًا، بحرف G كبير وحرف S كبير، دون مسافات أو لاحقة. تطابق Azure ذلك النص، لذا يُنتج Gateway-Subnet أو gateway شبكة فرعية لن تستخدمها خدمة البوابة.

الخطوة نفسها من واجهة سطر الأوامر، وهي أسهل في وضعها في مراجعة:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

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

أبقِ الشبكة الفرعية المُدارة خالية من قواعد أحمال العمل

لا تُرفق مجموعة أمان شبكة بهذه الشبكة الفرعية؛ تُصنّف Microsoft ذلك غير مدعوم. لا تربط جدول مسارات يرسل مساره الافتراضي 0.0.0.0/0 إلى مكان ما، لأن ذلك قد يعطّل تشغيل البوابة، وأبقِ نشر مسارات البوابة ممكّنًا.

ضع قيود الوصول التي أردتها فعلاً على الشبكة الفرعية لأحمال العمل أو عند حدّ تفتيش. معاملة GatewaySubnet كشبكة فرعية عادية هي الخطأ الذي ينتج بوابة تُنشر بنجاح ثم لا تمرر أي حركة.

للأنفاق القسرية تصميمها الموثّق. والمسار الافتراضي المرتجل على الشبكة الفرعية للبوابة ليس هو.

تحقّق من التبعيات التي لا يعرضها المدخل

قبل أن تضغط إنشاء، راجع القائمة: الاسم الدقيق، والبادئة داخل مساحة الشبكة الظاهرية، وعدم التداخل مع النطاقات المحلية، وعدم وجود موارد أحمال عمل بالداخل، وعدم وجود NSG، وعدم وجود جدول مسارات بمسار افتراضي. كل واحد من ذلك قد كسر عملية نشر حقيقية. ثم أكّد التصميم الأوسع: بوابة الشبكة المحلية للجانب المحلي، ومساحات العناوين التي تتوقع توجيهها، وما إذا كان التصميم نشط-نشط أو التعايش مخططًا له. تلك الخيارات تغيّر الحديث عن الحجم، وحسمها الآن أرخص بكثير.

تُعد مرجع إعدادات البوابة في Azure الصفحة التي تستشهد بها عندما يسأل أحدهم لماذا لا يمكن للشبكة الفرعية استيعاب جهاز ظاهري.

إذا كانت البوابة موجودة بالفعل

تغيير حجم الشبكة الفرعية للبوابة أو استبدالها ليس تعديلًا للقناع. تحقق أولاً من إجراء التغيير المدعوم لطراز البوابة وجيلها، وأدرج الكائنات التابعة: الاتصالات وعناوين IP العامة والتوجيه وأي متطلب استرداد.

إذا كان الإجراء يتطلب إعادة إنشاء البوابة، فخطط له كترحيل خدمة بنافذة زمنية وخطة تراجع. سجّل الحجز الذي اخترته، وسبب الحجم، والقواعد التي لم تُرفقها عمدًا، كي لا يُصلح المراجع التالي الشبكة الفرعية الفارغة بإضافة NSG.