الشبكات على الكلاود للمبرمجين: VPC وSubnet وCIDR من الصفر

الشبكات على الكلاود هي أول حاجة هتصطدم بيها أول ما تنزل من منصات النشر الجاهزة لسيرفر حقيقي في AWS أو Azure أو Google Cloud. السيرفر يتعمل بنجاح، وبعدين مش قادر تدخل عليه. أو الأسوأ: قاعدة بياناتك شغالة ومحدش بيشتكي، وهي مفتوحة لأي حد على الإنترنت.

المقال ده بيشرح الأساسيات اللي تخليك ترسم شبكتك بنفسك: CIDR وVPC وSubnet وSecurity Group، وبيربطهم بتصميم عملي لتطبيق ويب وقاعدة بيانات.

الخلاصة في أربع نقط:

• الـ VPC هي شبكتك الخاصة على الكلاود، والـ Subnet جزء منها، والـ CIDR هو اللي بيحدد حجمها.
• الـ Subnet بتبقى عامة (public) لو الـ route table بتاعتها فيها طريق لـ Internet Gateway، مش لأن حد سماها كده.
• الـ Security Group هو الـ firewall على مستوى السيرفر، والأفضل تسمح بالدخول من Security Group تاني مش من 0.0.0.0/0.
• قاعدة البيانات مكانها subnet خاصة، مش مفتوحة للإنترنت.

المحتويات

• أولاً: الشبكات على الكلاود: ليه لازم تفهمها
• ثانياً: الـ CIDR: إزاي تقرا 10.0.0.0/16
• ثالثاً: الـ VPC والـ Subnet: الكمبوند والشوارع
• رابعاً: Public وPrivate Subnet: الفرق في الـ route table
• خامساً: Security Group مقابل Network ACL
• سادساً: تصميم عملي لتطبيق ويب وقاعدة بيانات
• سابعاً: أوامر تشوف بيها شبكتك
• ثامناً: لما حاجة متتصلش: الأعراض والأسباب
• تاسعاً: أخطاء شائعة هتقابلك

أولاً: الشبكات على الكلاود: ليه لازم تفهمها

لما نشرت مشروعك على Vercel وRailway في مقال النشر، المنصة عملت كل حاجة شبكية نيابة عنك. أول ما تنزل على سيرفر حقيقي هتلاقي نفسك قدام أسئلة زي: السيرفر ده يوصله الإنترنت ولا لأ؟ وقاعدة البيانات تتفتح لمين؟

المفاهيم هي نفسها اللي شرحناها في مقال أساسيات الشبكات (الـ IP والـ Port والـ firewall)، بس المرة دي إنت اللي بترسم الشبكة. الأمثلة هنا على AWS لأنه غالبًا الأكتر انتشارًا، والمفاهيم موجودة في Azure وGoogle Cloud بأسماء مختلفة شوية.

ثانياً: الـ CIDR: إزاي تقرا 10.0.0.0/16

أي شبكة على الكلاود بتتحدد بمدى عناوين مكتوب بصيغة CIDR، زي 10.0.0.0/16. الجزء قبل الشرطة هو عنوان البداية، والرقم بعدها بيقولك كام بت من العنوان ثابتة (جزء الشبكة)، والباقي متاح للأجهزة.

عنوان IPv4 مكون من 32 بت. لو الرقم /16 يبقى أول 16 بت ثابتة، وفاضل 16 بت متغيرة، يعني 2 أس 16، وده 65,536 عنوان. القانون: عدد العناوين = 2 أس (32 ناقص الرقم).

• /16: حوالي 65 ألف عنوان.
• /24: 256 عنوان.
• /28: 16 عنوان.
• /32: عنوان واحد بس.

لاحظ إن كل ما الرقم يكبر الشبكة تصغر. وفي AWS فيه تفصيلة مهمة: بتحجز 5 عناوين من كل subnet لنفسها، فالـ /24 فيها 251 عنوان صالح مش 256. جرب الحساب بنفسك:

# كام عنوان في /24؟ (على Windows استخدم python بدل python3)
python3 -c "print(2 ** (32 - 24))"

# نفس الحساب بالمكتبة المدمجة في بايثون
python3 -c "import ipaddress; print(ipaddress.ip_network('10.0.0.0/16').num_addresses)"

اختار مدى من العناوين الخاصة اللي اتكلمنا عنها قبل كده (10.x.x.x أو 172.16 لحد 172.31 أو 192.168.x.x). والـ VPC الافتراضية في AWS بتستخدم 172.31.0.0/16. ولو عايز تشوف المدى مرسوم قدامك، فيه أداة بسيطة اسمها cidr.xyz.

ثالثاً: الـ VPC والـ Subnet: الكمبوند والشوارع

الـ VPC (Virtual Private Cloud) شبكة منطقية معزولة بتاخدها جوه الكلاود، وإنت اللي بتحدد مداها بـ CIDR. تخيلها كمبوند مسوّر: ليه عنوانه، وبواباته، ومحدش من برّه بيدخل إلا من البوابات اللي فتحتها. وللتفاصيل الرسمية فيه شرح AWS للـ VPC.

الـ Subnet هي جزء من الـ VPC، زي شارع جوه الكمبوند. وكل subnet في AWS بتتحط في Availability Zone واحدة، يعني مركز بيانات منفصل جوه نفس المنطقة. عشان تطبيقك يفضل شغال لو مركز وقع، بتوزع السيرفرات على subnets في أكتر من zone، وده نفس منطق الاعتمادية والتوسع اللي اتكلمنا عنه في مقال System Design.

رابعاً: Public وPrivate Subnet: الفرق في الـ route table

كلمة “عامة” و”خاصة” مش خاصية بتختارها بزرار. الفرق كله في جدول التوجيه (route table) بتاع الـ subnet، وهو جدول بيقول: الطلب رايح لعنوان كذا، ابعته من أنهي بوابة؟

• Public subnet: الـ route table فيها سطر 0.0.0.0/0 بيشاور على Internet Gateway. والسيرفر جواها محتاج كمان عنوان IP عام عشان الإنترنت يوصله.
• Private subnet: مفيهاش طريق مباشر للـ Internet Gateway، فمحدش من الإنترنت يقدر يبدأ اتصال بالسيرفرات اللي جواها.

والـ 0.0.0.0/0 معناه “كل العناوين”، يعني أي وجهة معندكش ليها قاعدة أدق. وطيب لو سيرفر في subnet خاصة محتاج يحمل تحديثات أو يكلم API خارجي؟ هنا بييجي دور الـ NAT Gateway.

الـ NAT Gateway بيتحط في subnet عامة، وبيخلي السيرفرات الخاصة تطلع للإنترنت وتاخد الرد، من غير ما حد من برّه يقدر يبدأ معاها اتصال. خد بالك إنه بيتحاسب (على الساعة وعلى البيانات اللي بتعدي)، فاحذفه بعد التجارب.

خامساً: Security Group مقابل Network ACL

فيه طبقتين للحماية على مستوى الشبكة، وبيتلخبطوا على ناس كتير. الجدول ده بيفرق بينهم.

كلمة stateful هنا معناها إن الـ Security Group فاكر الاتصال: لو سمحت بطلب داخل، الرد بيطلع تلقائيًا من غير قاعدة. أما الـ Network ACL فمبيفتكرش، فلو سمحت بالدخول لازم تكتب قاعدة للرد كمان (على ports مؤقتة، غالبًا من 1024 لـ 65535). عشان كده معظم الناس بيشتغلوا بالـ Security Group ويسيبوا الـ NACL على الإعداد الافتراضي.

وأقوى ميزة في الـ Security Group: تقدر تحدد المصدر بـ Security Group تاني بدل عنوان IP. يعني تقول “قاعدة البيانات تقبل الدخول من أي سيرفر تابع لمجموعة الويب بس”، ومهما اتغيرت عناوين السيرفرات القاعدة لسه شغالة:

# db-sg يقبل Port 27017 من web-sg بس (الأمر بصيغة Linux و Mac)
aws ec2 authorize-security-group-ingress \
  --group-id sg-0aa1234567890abcd \
  --protocol tcp \
  --port 27017 \
  --source-group sg-0bb1234567890abcd

على Windows اكتب الأمر في سطر واحد من غير علامات \، والـ IDs اللي في المثال وهمية.

سادساً: تصميم عملي لتطبيق ويب وقاعدة بيانات

خلينا نجمع اللي فات في تصميم بسيط: سيرفر ويب (Nginx قدام التطبيق زي ما شرحنا في مقال Nginx) وقاعدة بيانات، جوه VPC واحدة.

القواعد اللي ورا الرسم:

• web-sg: دخول على 443 و80 من أي مكان، ودخول على 22 (SSH) من عنوان IP بتاعك إنت بس.
• db-sg: دخول على 27017 من web-sg بس. مفيش أي قاعدة تانية.
• قاعدة البيانات في subnet خاصة، فحتى لو غلطت في قاعدة، مفيش طريق للإنترنت أصلاً.

ولو بتستخدم MongoDB Atlas زي مشروعنا في مقال Atlas، فقاعدة البيانات مش جوه الـ VPC بتاعتك، لكنها في شبكة Atlas نفسها. الحماية هنا بتيجي من الـ IP allowlist اللي ظبطناه هناك. وفيه خيارات اتصال خاص (peering أو private endpoints) بتتوفر غالبًا في الباقات المدفوعة، فراجع التوثيق حسب باقتك.

سابعاً: أوامر تشوف بيها شبكتك

لو عندك AWS CLI متظبط، الأوامر دي بتقرا الإعدادات بس ومبتغيرش حاجة:

# الـ VPCs اللي عندك
aws ec2 describe-vpcs

# الـ subnets: الـ ID والـ CIDR والـ Availability Zone
aws ec2 describe-subnets \
  --query "Subnets[].[SubnetId,CidrBlock,AvailabilityZone]" \
  --output table

# قواعد الـ security groups
aws ec2 describe-security-groups

ولو لسه بتتعلم، لوحة تحكم الكلاود فيها نفس المعلومات بشكل مرسوم، وده أحيانًا أسهل في الأول.

ثامناً: لما حاجة متتصلش: الأعراض والأسباب

نفس طريقة التفكير في مقال الشبكات: الرسالة بتقولك الخطوة اللي فشلت. وده الترتيب اللي أنصح تفحص بيه:

• مش قادر تعمل SSH على سيرفر جديد: راجع إن الـ security group فيه Port 22 مسموح من عنوانك، وإن السيرفر في subnet عامة وليه عنوان IP عام، وإن الـ route table فيها طريق للـ Internet Gateway، وإن ملف المفتاح صح.
• Connection timed out من التطبيق لقاعدة البيانات: غالبًا الـ security group بتاع القاعدة مش بيسمح بالمصدر ده، أو السيرفرين في مكانين غلط.
• سيرفر في subnet خاصة مش قادر يحمل تحديثات: مفيش route لـ NAT Gateway.
• Connection refused: الشبكة سليمة والطلب وصل، والمشكلة إن مفيش برنامج شغال على الـ Port ده.
• مش قادر تتصل بـ Atlas من جهازك: عنوانك مش في الـ IP allowlist.

تاسعاً: أخطاء شائعة هتقابلك

• فتح Port 22 أو Port قاعدة البيانات لـ 0.0.0.0/0 “مؤقتًا” وبعدين نسيانه. العناوين العامة بتتفحص باستمرار من أدوات آلية.
• وضع قاعدة البيانات في subnet عامة عشان “أسهل تتجرب”.
• الاعتماد على الـ VPC الافتراضية في الإنتاج من غير ما تفهم إعداداتها.
• اختيار CIDR بيتداخل مع شبكة تانية (VPC تانية أو شبكة الشركة)، وده بيمنع الربط بينهم بعدين.
• ترك الـ NAT Gateway شغال بعد التجربة، لأنه بيتحاسب طول ما هو موجود.
• كتابة قاعدة دخول في الـ Network ACL ونسيان قاعدة الرد، لأنه stateless.

قبل ما تعمل أي حاجة في لوحة التحكم، ارسم الشبكة على ورقة: الـ VPC والـ subnets وأنهي سيرفر في أنهي واحدة، ومين مسموح له يكلم مين. الرسم ده بيوفر عليك ساعات تصحيح. والأسعار والحدود بتتغير مع الوقت، فراجع توثيق مزود الكلاود قبل ما تبني حاجة فعلية. ولو عندك سؤال أو رسالة خطأ في شبكتك، ابعتها في التعليقات.