كيفية تجنب تداخل عناوين IP في شبكات Azure الهجينة
By Mirko Peters ·
تعرّف على كيفية منع تداخل عناوين IP الكارثي عند ربط شبكة المكتب المحلية بالشبكات الظاهرية في Azure، باستخدام تخطيط CIDR سليم.
Automatically translated with AI from the original post. Read the English original

عند ربط البنية التحتية المؤسسية المحلية بسحابة Microsoft، قد يؤدي تداخل نطاقات عناوين IP إلى تعطيل الاتصال الهجين فوراً. ويضمن التخطيط السليم لكتل CIDR، وتصميم الشبكات الفرعية بعناية، وتوزيع النطاقات بشكل استراتيجي، أن تتمكن شبكات Azure الظاهرية والمكاتب المحلية من التواصل دون تصادم في التوجيه.
النقاط الرئيسية
- يحدث تداخل عناوين IP عندما تستخدم شبكتك المحلية وشبكة Azure VNet نطاق الشبكة الفرعية نفسه، فيتعطل التوجيه تماماً.
- يجب تنسيق نطاقات IP الخاصة، مثل 192.168.x.x أو 10.x.x.x، بعناية بين البيئتين قبل إنشاء اتصال VPN أو ExpressRoute.
- إن اختيار حجم مناسب لكتلة CIDR منذ البداية يمنع مشاريع إعادة الترقيم المرهقة لاحقاً مع توسع بنيتك السحابية.
- تحجز Azure أول أربعة عناوين IP وآخر عنوان في كل شبكة فرعية، لذا فإن عدد المضيفات القابلة للاستخدام أقل مما توحي به الحسابات التقليدية.
- تقسيم الشبكة منطقياً لا يقل أهمية في السحابة عنه في المحوّل الفعلي في مكتبك.
خطر تداخل IP في البيئات الهجينة
عندما تجلس إلى مكتبك في مكتب تقليدي، يعمل جهازك داخل كتلة شبكة محلية محددة بوضوح يوزعها موجِّه محلي. يبدو كل شيء بسيطاً حتى تتبنى مؤسستك بنية سحابية هجينة. فمنذ اللحظة التي تنشئ فيها أول شبكة Azure Virtual Network (VNet) وتربطها بمركز البيانات أو المكتب الفعلي عبر VPN من موقع إلى موقع أو عبر ExpressRoute، تدخل ساحة شبكية عالية المخاطر.
الشبكتان اللتان تعملان على نطاق العناوين نفسه تشبهان أسرتين مستقلتين تتشاركان العنوان البريدي ورقم المنزل نفسيهما. عندما تغادر حزمة من خادمك المحلي متجهة إلى مورد في Azure، يفحص الموجِّه جدول التوجيه لديه ليعرف أين يقع الوجهة. وإذا كانت شبكة المكتب المحلية وشبكة Azure VNet تشغلان مساحة الشبكة الفرعية نفسها، مثل كتلة 192.168.1.0/24 الشائعة، فليس أمام الموجِّه أي وسيلة منطقية للتمييز بين الأجهزة المحلية وموارد السحابة. لا يعرف ساعي البريد أي باب يطرق، فينقطع الاتصال فوراً.
لماذا تسبب الإعدادات الافتراضية المنزلية صداعاً في المؤسسات
تأتي معظم أجهزة التوجيه المنزلية وإعدادات المكاتب الصغيرة بإعدادات افتراضية معقولة، إذ تُعيَّن العناوين تلقائياً ضمن النطاقين 192.168.0.0/24 و192.168.1.0/24. ولأن هذه الإعدادات الافتراضية غير مرئية للمستخدمين العاديين، فإن المسؤولين كثيراً ما يغفلون عنها عند إعداد العاملين عن بُعد الذين يتصلون عبر عملاء VPN، أو عند إنشاء روابط للفروع الصغيرة مع Azure.
إذا كان جهاز التوجيه المنزلي لأحد الموظفين عن بُعد يستخدم 192.168.1.0/24، وكانت بنيتك السحابية في Azure منشورة أيضاً على نطاق متعارض، فسيجد هذا الموظف نفسه محروماً تماماً من موارد السحابة المؤسسية كلما حاول نفق VPN الخاص به سد الفجوة. ولتجنب هذا الصداع يلزم قبل توفير أي موارد سحابية بوقت طويل إدارة دقيقة لعناوين IP (IPAM).
تخطيط كتل CIDR لشبكات Azure VNet
الانتقال من العالم المادي إلى السحابة يُلقي بمسؤولية تصميم الشبكة كاملةً على عاتقكم. ففي المنزل، يحدد مزوّد خدمة الإنترنت أو الموجّه المنزلي نطاق عناوينكم نيابةً عنكم. أما في Azure، فأنتم من يحدد الحدود، وأنتم من يتحمل نتائج ذلك.
عند تصميم بيئة Azure، يجب رسم مخطط هرمي للعناوين لا تتداخل فيه النطاقات. ويعني ذلك تقسيم مساحة عناوين IP الخاصة المتاحة لديكم، والتي تُؤخذ عادةً من مجموعات RFC 1918، إلى كتل منفصلة ومخصصة لـ:
- أحمال العمل الإنتاجية وخوادم التطبيقات الأساسية
- بيئات التجهيز والتطوير والاختبار
- البنية التحتية للإدارة، وأجهزة وحدات التحكم بالمجال، ومحطات القفز (Jump Boxes)
- خدمات التكامل والبوابات وأجهزة الأمان
عند التعامل مع بنية عناوين IP كمورد محدود، تضمنون إمكانية دمج فروع المكاتب المستقبلية، وشبكات الشركات التابعة المُستحوذ عليها، ومناطق السحابة الجديدة دون الحاجة إلى مشروع ضخم لإعادة ترقيم العناوين يعطّل أعمال المؤسسة.
الفارق في Azure: تعديلات حسابات الشبكات الفرعية
عند حساب أحجام الشبكات الفرعية في Azure، تتطلب الحسابات الشبكية القياسية تعديلاً جوهرياً. ففي الشبكة الفرعية النموذجية وفق المراجع الأكاديمية، يُحجز عنوانان من كل كتلة دائماً: الأول يمثل معرّف الشبكة، والأخير يمثل عنوان البث (Broadcast). وبناءً على ذلك، فإن كتلة /24 القياسية التي تحتوي على 256 عنواناً إجمالياً تتيح 254 عنوان مضيف قابلاً للاستخدام.
أما عند إنشاء شبكات فرعية داخل الشبكات الافتراضية (Virtual Networks) في Azure، فإن المنصة السحابية تقتطع عناوين إضافية لاحتياجاتها الداخلية للبنية التحتية والتوجيه. إذ تحجز Azure خمسة عناوين IP في كل شبكة فرعية:
- .0: عنوان الشبكة .1: تحجزه Azure للبوابة الافتراضية (Default Gateway) .2 و.3: تحجزهما Azure لربط عناوين DNS الخاصة بـ Azure .255: عنوان البث
وهذا يعني أن الشبكة الفرعية /24 في Azure توفّر 251 عنواناً قابلاً للاستخدام بدلاً من 254. ويساعد أخذ هذه العناوين المحجوزة في الحسبان على تفادي نقص غير متوقع في السعة عند نشر تطبيقات الويب المُوسّعة، أو مجموعات الحاويات، أو مجموعات مقاييس الأجهزة الافتراضية.
الخاتمة
إن إتقان تدوين CIDR وحدود الشبكات الفرعية أكثر من مجرد تمرين أكاديمي لشهادات تقنية المعلومات، بل هو المهارة الأساسية التي تُبقي بيئات السحابة الهجينة الحديثة تعمل بكفاءة. وبرسم مساحات العناوين بشكل استباقي وتجنب فخاخ التداخل الشائعة، تحمون بنيتكم التحتية من أعطال التوجيه الصامتة، وتضمنون تواصلاً سلساً بين مكاتبكم المحلية (On-premises) ومنصة Microsoft Azure.
للتعمق أكثر في كيفية ترابط الموجّهات المنزلية وأقنعة الشبكات وبنى السحابة، استمعوا إلى الحلقة كاملةً من البودكاست للحصول على شرح مبسّط خالٍ من المصطلحات المعقدة لأساسيات الشبكات.
الأسئلة المتداولة
ماذا يحدث إذا كانت شبكتي المحلية وشبكة Azure VNet تستخدمان نطاق IP نفسه؟
ستتعطل حركة المرور بين البيئتين تماماً. فلأن الموجّهات تعتمد على شبكات وجهة فريدة لتمرير الحزم، فإن النطاقات المتداخلة تربك جداول التوجيه، مما يجعل من المستحيل على الأنظمة معرفة الاتجاه الذي ينبغي إرسال البيانات إليه.
كم عدد عناوين IP التي تحجزها Azure في كل شبكة فرعية؟
تحجز Azure خمسة عناوين IP في كل شبكة فرعية: عنوان الشبكة، والبوابة الافتراضية، وعنوانان لربط DNS الداخلي الخاص بـ Azure، وعنوان البث.
هل يمكنني تغيير نطاق عناوين IP لشبكة Azure VNet لاحقاً بسهولة؟
لا. فتغيير مساحة العناوين الأساسية لشبكة Azure الافتراضية أو لشبكة فرعية قائمة أمر معقّد، ويتطلب غالباً إزالة الموارد وإعادة إنشائها، ولذلك يصبح التخطيط المسبق لتدوين CIDR ضرورياً.
ما نطاقات عناوين IP الخاصة التي ينبغي أن أستخدمها لنشرات Azure الهجينة؟
يمكنكم استخدام النطاقات الواردة في RFC 1918 (10.0.0.0/8 و172.16.0.0/12 و192.168.0.0/16). والمهم هو اختيار نطاقات لا تتعارض مع مكاتب شركتكم القائمة، أو مواقع فروعها، أو شبكات شركائها.