أساسيات الشبكات لـ DevOps

عناوين IP والشبكات الفرعية

18 دقيقة الدرس 2 من 30

عناوين IP والشبكات الفرعية

يحتاج كل حزمة بيانات على الإنترنت إلى شيئين: مصدر ووجهة. عناوين IPv4 هي تلك الوجهات — أعداد صحيحة من 32 بت تُكتب بصيغة النقط العشرية. فهمها على مستوى البتات ليس تمريناً أكاديمياً؛ بل هو ما يُمكّنك من تصميم تضاريس VPC التي لا تتعارض، وكتابة قواعد Security Group التي تعمل فعلاً، وتشخيص جداول التوجيه تحت ضغط الإنتاج.

تشريح عنوان IPv4

عنوان IPv4 مثل 192.168.10.45 يتكون من أربع بايتات (مجموعات من 8 بتات) تتراوح قيمة كل منها بين 0 و255. بالنظام الثنائي:

192      . 168      . 10       . 45
11000000 . 10101000 . 00001010 . 00101101

يضمّ كل عنوان جزأين منطقيين: بادئة الشبكة (تُعرّف الشبكة) وجزء المضيف (يُعرّف الجهاز المحدد). يُحدَّد الحد الفاصل بينهما بواسطة قناع الشبكة الفرعية.

صيغة CIDR

استبدل التوجيه عبر الفئات اللاصنفي (CIDR) نظام الفئات القديم A/B/C عام 1993. بدلاً من ترميز القناع في فئة العنوان، تُضاف طول البادئة بعد شرطة مائلة. 10.0.0.0/8 تعني أن أول 8 بتات هي بادئة الشبكة؛ أما الـ24 بتاً المتبقية فهي مساحة المضيف — كافية لاستيعاب 2²⁴ − 2 = 16,777,214 عنواناً صالحاً للاستخدام.

العنوانان اللذان تخسرهما دائماً من أي كتلة: عنوان الشبكة (جميع بتات المضيف صفر) وعنوان البث (جميع بتات المضيف واحد). كتلة /30 تمنحك عنوانَي IP فعليَّين فقط — مثالية للروابط النقطة بنقطة.

أطوال البادئات التي يحفظها كل مهندس DevOps عن ظهر قلب:

/32 — مضيف واحد (يُستخدم في قواعد Security Group وإدخالات جدول التوجيه لمضيفات محددة)
/31 — عنوانان، بلا بث؛ روابط نقطة بنقطة وفق RFC 3021
/30 — 4 عناوين، 2 صالحان؛ رابط موجّه كلاسيكي
/28 — 16 عنواناً، 14 صالحاً؛ أصغر شبكة فرعية مدعومة في AWS
/24 — 256 عنواناً، 254 صالحاً؛ الشبكة الفرعية اليومية المعتادة
/22 — 1,024 عنوان؛ شبكة فرعية مناسبة لمجمّع عقد Kubernetes
/16 — 65,536 عنوان؛ كتلة CIDR نموذجية للـVPC
/8 — 16.7 مليون عنوان؛ نطاق RFC 1918 الخاص بـ10.x.x.x بأكمله

نطاقات العناوين الخاصة (RFC 1918)

ثلاث كتل محجوزة للشبكات الخاصة — لا يتم توجيهها على الإنترنت العام:

10.0.0.0/8 — 16.7 مليون عنوان؛ مُفضَّل للسُّحب الكبيرة ومرافق مراكز البيانات
172.16.0.0/12 — مليون عنوان (من 172.16.x.x إلى 172.31.x.x)
192.168.0.0/16 — 65 ألف عنوان؛ شائع في الشبكات المنزلية والمكتبية

على نطاق الشركات الكبرى، ابنِ دائماً شبكات VPC من مساحة 10.0.0.0/8. تمنحك مساحة كافية لتخصيص كتل /16 غير متداخلة لكل منطقة، وكل بيئة (إنتاج/تجهيز/تطوير)، وكل فريق — دون الوقوع في نفاد RFC 1918. وثّق جدول التخصيص في قاعدة بيانات إدارة التكوين (CMDB) أو حتى في جدول بيانات مشترك منذ البداية؛ استرداد النطاقات المتداخلة لاحقاً أمر بالغ الصعوبة.

تقسيم شبكة VPC إلى شبكات فرعية

تُقسَّم كتلة CIDR الخاصة بالـVPC إلى شبكات فرعية. تقع كل شبكة فرعية في منطقة توفر (AZ) واحدة بالضبط وتحمل فئة حركة مرور واحدة (عامة، أو خاصة، أو معزولة/قواعد بيانات). هذا هو التخطيط المعياري ذو الثلاث طبقات المستخدم على نطاق الإنتاج:

تخطيط VPC ذو الثلاث طبقات: الشبكات الفرعية العامة تواجه الإنترنت، والخاصة تشغّل أعباء التطبيقات، والمعزولة تستضيف قواعد البيانات — كل طبقة مكررة عبر منطقتَي توفر لتحقيق التوفر العالي.

لاحظ اصطلاح العنونة: تستخدم الشبكات الفرعية العامة النطاق 10.0.1.x و10.0.2.x، والخاصة النطاق 10.0.11.x و10.0.12.x، والمعزولة النطاق 10.0.21.x و10.0.22.x. يُرمّز رقم العشرات للطبقة، ورقم الآحاد لمنطقة التوفر. هذا قاعدة تذكّرية بسيطة يمكن تطبيقها باتساق عبر كل البيئات.

حساب حدود الشبكات الفرعية

أداة ipcalc المتاحة على معظم توزيعات Linux لا غنى عنها للتحقق السريع:

$ ipcalc 10.0.11.0/24
Address:   10.0.11.0            00001010.00000000.00001011. 00000000
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Network:   10.0.11.0/24
HostMin:   10.0.11.1
HostMax:   10.0.11.254
Broadcast: 10.0.11.255
Hosts/Net: 254

في البنية التحتية المُدارة بـTerraform، تُجزّئ الدالة cidrsubnet() الشبكات الفرعية برمجياً — دون حاجة لحسابات يدوية:

locals {
  vpc_cidr = "10.0.0.0/16"
}

# cidrsubnet(prefix, newbits, netnum)
# newbits=8 extends /16 to /24; netnum selects which /24
resource "aws_subnet" "public_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(local.vpc_cidr, 8, 1)   # 10.0.1.0/24
  availability_zone = "us-east-1a"
  map_public_ip_on_launch = true
}

resource "aws_subnet" "private_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(local.vpc_cidr, 8, 11)  # 10.0.11.0/24
  availability_zone = "us-east-1a"
}

resource "aws_subnet" "isolated_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(local.vpc_cidr, 8, 21)  # 10.0.21.0/24
  availability_zone = "us-east-1a"
}

أنماط الفشل الشائعة في الإنتاج

تداخل كتل CIDR. تشترك شبكتا VPC أو شبكة محلية في نفس كتلة RFC 1918. يرفض VPC Peering وTransit Gateway الاتصال بينهما، وحتى إن تحايلت على ذلك، يصبح التوجيه غامضاً. امنع ذلك بسياسة مركزية لإدارة عناوين IP (IPAM) مُطبَّقة عند إنشاء الحساب.
استنفاد الشبكات الفرعية. كتلة /28 (14 عنوان صالح) مناسبة لبوابة NAT لكنها ستُعيق مجمّع ECS أثناء أحداث التوسع. تحتجز AWS أيضاً 5 عناوين لكل شبكة فرعية للاستخدام الداخلي، مما يقلّل /28 إلى 11 عنواناً فعلياً. حدّد الحجم دائماً للذروة مع هامش 50% إضافي.
تصادم كتلة CIDR لـPod في Kubernetes. إذا كانت VPC تستخدم 10.0.0.0/16 والمجمّع يستخدم 10.0.0.0/14 كـPod CIDR (افتراضي شائع لبعض CNI)، تتصادم عناوين Pod مع عناوين العقد. خطّط لكتل CIDR الخاصة بالـPod والخدمات بشكل صريح ووثّقها قبل الإعداد.

لا تُخصّص كتلة /16 أو أكبر لشبكة فرعية واحدة. جداول التوجيه تُعلن كل شبكة فرعية كبادئة متصلة مباشرة، والشبكات الفرعية المسطحة الكبيرة تُضعف تجزئة Security Group. الشبكة المسطحة الكبيرة أيضاً تزيد من نطاق الضرر عند سوء تكوين Security Group. اجعل الشبكات الفرعية صغيرة ومفصولة حسب الطبقة.

مرجع سريع: أوامر المضيف المفيدة

# عرض جميع الواجهات وعناوين CIDR المخصصة لها (Linux)
ip addr show

# التحقق من الشبكة التي ينتمي إليها عنوان IP لمضيف ما
ip route get 10.0.11.42

# عرض جدول التوجيه — ضروري لتشخيص "لا مسار للمضيف"
ip route show table main

# على macOS
ifconfig en0 | grep inet
netstat -rn -f inet

احفظ القاعدتين الأساسيتين: /24 = 254 مضيفاً و/16 = 65,534 مضيفاً؛ واشتق كل شيء آخر منهما بمضاعفة أو تنصيف عدد المضيفين مع كل تغيير بت في البادئة. كل مهندس أول يُطلب منه تحديد حجم شبكة فرعية على الفور يجري هذا الحساب الذهني — لا يستغرق أكثر من عشر ثوانٍ.

مع فهم راسخ لـCIDR وتصميم الشبكات الفرعية، يمكنك الآن التفكير في كل طبقة تُبنى فوقها: جداول التوجيه، وقواعد Security Group، وبوابات NAT، وVPC Peering — كلها تعمل على حدود الشبكات الفرعية. يمتد الدرس التالي هذا الأساس إلى DNS — كيف تُحلَّل الأسماء إلى عناوين IP هذه على نطاق السحابة.