Azure / أساسي: النطاق والهوية والموقع والموارد / الدرس 4

الشبكات الافتراضية والشبكات الفرعية وقرارات الحزم

افهم عناوين Azure Virtual Network وحدود المرور قبل القواعد. افصل التوجيه وأمن الشبكة وDNS وتعرض الخدمة وتصريح التطبيق.

وقت القراءة التقريبي: 3 دقيقةتاريخ مراجعة المحتوى 2026-10-25

في هذه الصفحة

أهداف الدرس

تخطيط عناوين غير متداخلة وسعة الشبكات الفرعية.
تمييز المسار من قاعدة السماح.
شرح حدود نموذج شبكة ساكن.

العناوين قيد لاتصال المستقبل

توفر Azure Virtual Network سياق شبكة منطقية خاصة بعناوين وشبكات فرعية. خطط مجالات غير متداخلة للربط والهجين والنمو، لا التطبيق الأول فقط. ليست الفرعية حداً لتصريح التطبيق تلقائياً. وثّق الوضع والتفويض والحجز والطلب على العناوين. تختلف IPv4 وIPv6؛ فلا تعمم حساب الأولى. لا تعين عناوين المثال لواجهات أو تفحص مسارات لتثبت حساباً تعليمياً.

العناوين القابلة للاستخدام ليست حجم CIDR كله

تحجز Azure أول أربعة عناوين وآخر عنوان في الفرعية IPv4 المعتادة. لذا تحوي/24 عدد256 ويظل251 بعد حجز المنصة وقبل متطلبات الحمل. قد تحتاج خدمة فرعية مخصصة أو أكبر؛ فهذا بدء لا ضمان حجم. يحلل المثال بادئة مصطنعة ويطرح خمسة بلا طلب شبكة. أدخل التوسع وتداخل الاستبدال والنقاط الخاصة والمستهلكين الآخرين بالخطة وتحقق من القواعد الحالية.

python حساب حجز IPv4 محلياً

from ipaddress import ip_network
subnet = ip_network("10.20.1.0/24")
reserved = 5
print(subnet.num_addresses, subnet.num_addresses - reserved)

الناتج المتوقع

256 251

يطبق قاعدة IPv4 المعلنة فقط دون تخصيص أو إثبات حجم فرعية لخدمة محددة.

يجيب التوجيه والأمان وDNS عن أسئلة مختلفة

يختار التوجيه القفزة التالية، ويسمح الأمان أو يرفض، ويحل DNS الاسم. قد يصل IP وتفشل الخدمة لاسم DNS أوTLS خاطئ. مجموعات الأمان ذات حالة وأولوية واتجاه، ولا تستبدل جدار تطبيق أو إذن بيانات. قد يسمح حد ويرفض آخر. خطط الخروج صراحة ولا تفترض الإنترنت لكل إعداد. تتبع المصدر والوجهة والبروتوكول والمنفذ في التشخيص.

تكشف مصفوفة مرور ساكنة القرارات الغائبة

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

json مصفوفة مرور مصطنعة قابلة للمراجعة

{
  "model": "traffic-requirements-only",
  "flows": [
    {
      "from": "web",
      "to": "application",
      "decision": "allow-required-port"
    },
    {
      "from": "application",
      "to": "data",
      "decision": "allow-required-port"
    },
    {
      "from": "external-client",
      "to": "data",
      "decision": "deny"
    }
  ]
}

الناتج المتوقع

two intended paths; direct external data path denied

ليس النموذج نشراً أو فحص حزم؛ وتبقى المنافذ والهوية قرارات منفصلة عمداً.

يحتاج الربط والوصول الخاص بنية صريحة

يربط peering الشبكات الداعمة ولا يصير انتقالياً تلقائياً عبر سلسلة. يحتاج الهجين والخدمات الخاصة توجيهاً وDNS. تختلف private endpoints وservice endpoints وضبط العام وسندرسها لاحقاً. لا تستنتج التشفير والإذن من العنوان الخاص. وثّق موضع العميل والمحلل. لا تنفذ الدورة فحص اتصال أو حزم أو تعديل مسار أوCLI؛ فتثبت الأمثلة الحساب والقصد فقط.

الأخطاء الشائعة وإصلاحها

افتراض أن المسار يمنح إذن المرور

لماذا يحدث؟: خلط اختيار الطريق بسياسة الأمن.
كيف تصلحه؟: مراجعة التوجيه وكل حد سماح ورفض مستقلاً.
كيف تتجنب تكراره؟: توثيق المصدر والوجهة والمنفذ والبروتوكول والهوية.

تخطيط/24 كـ256 عنوان IPv4 صالحاً

لماذا يحدث؟: إغفال حجز المنصة.
كيف تصلحه؟: طرح الحجز والتحقق من حاجات الخدمة.
كيف تتجنب تكراره؟: إدراج النمو وتداخل الاستبدال بالحجم.

اعتبارpeering توجيهاً انتقالياً تلقائياً

لماذا يحدث؟: افتراض السلوك من سلسلة مرسومة.
كيف تصلحه؟: تصميم الطريق المدعوم المقصود والتحقق منه.
كيف تتجنب تكراره؟: مراجعة كل زوج مطلوب واعتماد.

اختبر فهمك

1. كم عنواناً يبقى في/24 بعد حجز Azure IPv4 المعتاد؟

اعرض الحل المشروح

يوجد256؛ وبعد طرح خمسة يبقى251 قبل متطلبات الحمل. لا يثبت ملاءمة خدمة أو قابلية تخصيص الجميع للتطبيق. تحقق من الفرعية المخصصة وقواعد الخدمة منفصلاً.

2. للتطبيق دور بيانات مسموح ولا يتصل. ما الذي لا يثبته الدور؟