EC2 لا يصل إلى الإنترنت في VPC مخصص — ربط Internet Gateway وتحديث جدول التوجيه

أنشأت VPC مخصصًا، أطلقت EC2 في subnet عام، وحاولت تنفيذ ping google.com — لا شيء. هذا السيناريو يتكرر في كل مرة يبني فيها مهندس بنيته الشبكية من الصفر بدلًا من استخدام VPC الافتراضي، لأن AWS لا تربط Internet Gateway تلقائيًا بأي VPC مخصص.

ملخص سريع (TL;DR) — EC2 بلا إنترنت في VPC مخصص

المشكلة	السبب الجذري	الإصلاح
EC2 لا يصل إلى الإنترنت	لا يوجد Internet Gateway مرتبط بالـ VPC	إنشاء IGW وربطه بالـ VPC
IGW موجود لكن لا اتصال	جدول التوجيه لا يحتوي على مسار 0.0.0.0/0 نحو IGW	إضافة route إلى Route Table
Route موجود لكن لا اتصال	الـ subnet غير مرتبط بجدول التوجيه الصحيح	ربط الـ subnet بجدول التوجيه
كل شيء صحيح لكن لا اتصال	Security Group أو NACL يحجب الحركة	مراجعة القواعد الأمنية

كيف يعمل الوصول إلى الإنترنت في VPC — الآلية الداخلية

قبل الخوض في الخطوات، يجب فهم السلسلة الكاملة. الـ subnet لا يصبح 'عامًا' لمجرد أنك سميته public — هذا مجرد تسمية. ما يجعله عامًا فعليًا هو ثلاثة شروط يجب أن تتحقق جميعها في آنٍ واحد.

graph LR A["EC2 Instance"] --> B["Subnet"] B --> C["Route Table"] C -->|"0.0.0.0/0"| D["Internet Gateway (IGW)"] D --> E["الإنترنت"] F["IP عام مطلوب"] -.->|"شرط إضافي"| A G["Security Group"] -.->|"طبقة أمنية"| A H["NACL"] -.->|"طبقة أمنية"| B

1. Internet Gateway (IGW): مكوّن VPC يعمل كنقطة الدخول/الخروج بين الـ VPC والإنترنت. يجب إنشاؤه وربطه بالـ VPC صراحةً.
2. Route Table: يجب أن يحتوي جدول التوجيه المرتبط بالـ subnet على مسار 0.0.0.0/0 يشير إلى الـ IGW. بدون هذا المسار، الحزم لا تعرف أين تذهب.
3. Public IP أو Elastic IP: الـ EC2 يحتاج عنوان IP عام حتى يستطيع الإنترنت الرد عليه. إذا أطلقت الـ instance بدون تفعيل 'Auto-assign public IP'، لن يكون لديها عنوان قابل للتوجيه.

Security Groups و NACLs هي طبقة إضافية — حتى لو كانت الشبكة مضبوطة بشكل صحيح، قاعدة حجب واحدة تكفي لقطع الاتصال بصمت.

تشخيص المشكلة — EC2 بلا إنترنت في VPC مخصص

قبل البدء في الإصلاح، حدد أين تقف بالضبط. كثير من المهندسين يبدأون بإنشاء IGW جديد وهم يمتلكون واحدًا بالفعل — المشكلة كانت في الـ Route Table.

الخطوة 1: تحقق من وجود Internet Gateway وحالة ربطه بالـ VPC

الـ IGW قد يكون موجودًا لكن في حالة detached — وهذا يعني أنه لا يفعل شيئًا. الفرق بين attached و detached هو الفرق بين الاتصال وعدمه.

aws ec2 describe-internet-gateways \
  --filters 'Name=attachment.vpc-id,Values=vpc-0123456789abcdef0' \
  --query 'InternetGateways[*].{IGW_ID:InternetGatewayId,State:Attachments[0].State}' \
  --output table

إذا كانت النتيجة فارغة، لا يوجد IGW مرتبط بهذا الـ VPC. إذا ظهر detached، الـ IGW موجود لكن غير مفعّل.

الخطوة 2: تحقق من جدول التوجيه المرتبط بالـ subnet

هذه الخطوة تكشف ما يفوت معظم المهندسين — قد يكون لديك Route Table صحيح على مستوى الـ VPC، لكن الـ subnet مرتبط بجدول توجيه مختلف لا يحتوي على المسار الصحيح.

aws ec2 describe-route-tables \
  --filters 'Name=association.subnet-id,Values=subnet-0123456789abcdef0' \
  --query 'RouteTables[*].{RT_ID:RouteTableId,Routes:Routes[*].{Dest:DestinationCidrBlock,Target:GatewayId}}' \
  --output json

ابحث عن مسار 0.0.0.0/0 يشير إلى igw-xxxxxxxxx. إذا لم يكن موجودًا، هذا هو سبب المشكلة.

الخطوة 3: تحقق من وجود IP عام على الـ instance

حتى لو كانت الشبكة مضبوطة بشكل مثالي، instance بدون IP عام لن تستطيع الاتصال بالإنترنت — لأن الإنترنت لا يعرف كيف يرد عليها.

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,PublicIP:PublicIpAddress,State:State.Name}' \
  --output table

إذا كانت قيمة PublicIP فارغة أو None، ستحتاج إلى تخصيص Elastic IP أو إعادة تشغيل الـ instance مع تفعيل auto-assign.

الإصلاح خطوة بخطوة — ربط Internet Gateway وتحديث Route Table

graph TD Start(["EC2 لا يصل للإنترنت"]) --> Q1{"IGW موجود ومرتبط؟"} Q1 -->|"لا"| Fix1["إنشاء IGW وربطه بالـ VPC"] Q1 -->|"نعم"| Q2{"Route Table يحتوي
على 0.0.0.0/0 نحو IGW؟"} Fix1 --> Q2 Q2 -->|"لا"| Fix2["إضافة مسار 0.0.0.0/0 إلى Route Table"] Q2 -->|"نعم"| Q3{"Subnet مرتبط بجدول
التوجيه الصحيح؟"} Fix2 --> Q3 Q3 -->|"لا"| Fix3["ربط Subnet بجدول التوجيه الصحيح"] Q3 -->|"نعم"| Q4{"EC2 لديها IP عام؟"} Fix3 --> Q4 Q4 -->|"لا"| Fix4["تخصيص Elastic IP وربطه"] Q4 -->|"نعم"| Q5{"Security Group و NACL
يسمحان بالحركة؟"} Fix4 --> Q5 Q5 -->|"لا"| Fix5["تحديث قواعد SG و NACL"] Q5 -->|"نعم"| Done(["الاتصال يعمل ✓"]) Fix5 --> Done

الخطوة 1: إنشاء Internet Gateway وربطه بالـ VPC

إذا لم يكن لديك IGW، أنشئه وارتبطه بالـ VPC في خطوتين. لا يمكن ربط أكثر من IGW واحد بنفس الـ VPC.

# إنشاء Internet Gateway
aws ec2 create-internet-gateway \
  --query 'InternetGateway.InternetGatewayId' \
  --output text

# ربط IGW بالـ VPC (استبدل القيم بمعرفاتك الفعلية)
aws ec2 attach-internet-gateway \
  --internet-gateway-id igw-0123456789abcdef0 \
  --vpc-id vpc-0123456789abcdef0

لا يوجد output عند نجاح الأمر الثاني — الصمت هنا يعني النجاح.

الخطوة 2: إضافة مسار الإنترنت إلى جدول التوجيه

إذا كان الـ subnet مرتبطًا بجدول توجيه لا يحتوي على مسار للإنترنت، أضف المسار مباشرةً. هذا المسار يوجّه كل الحركة غير المحلية نحو الـ IGW.

aws ec2 create-route \
  --route-table-id rtb-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-0123456789abcdef0

إذا أردت دعم IPv6 أيضًا:

aws ec2 create-route \
  --route-table-id rtb-0123456789abcdef0 \
  --destination-ipv6-cidr-block ::/0 \
  --gateway-id igw-0123456789abcdef0

الخطوة 3: التأكد من ربط الـ subnet بجدول التوجيه الصحيح

إذا كان الـ subnet يستخدم جدول التوجيه الرئيسي للـ VPC ولا تريد تعديله، أنشئ جدول توجيه جديدًا وارتبطه بالـ subnet تحديدًا.

# إنشاء جدول توجيه جديد
aws ec2 create-route-table \
  --vpc-id vpc-0123456789abcdef0 \
  --query 'RouteTable.RouteTableId' \
  --output text

# ربط الـ subnet بجدول التوجيه الجديد
aws ec2 associate-route-table \
  --route-table-id rtb-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0

# إضافة مسار الإنترنت للجدول الجديد
aws ec2 create-route \
  --route-table-id rtb-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-0123456789abcdef0

الخطوة 4: تخصيص Elastic IP إذا لم يكن للـ instance IP عام

إذا أطلقت الـ instance بدون IP عام، الخيار الأفضل هو تخصيص Elastic IP وربطه بها — هذا لا يتطلب إعادة تشغيل الـ instance.

# تخصيص Elastic IP
aws ec2 allocate-address \
  --domain vpc \
  --query 'AllocationId' \
  --output text

# ربط Elastic IP بالـ instance
aws ec2 associate-address \
  --instance-id i-0123456789abcdef0 \
  --allocation-id eipalloc-0123456789abcdef0

مراجعة Security Group و NACL — الطبقة الأمنية

وصلت إلى هنا وما زال الـ ping لا يعمل؟ الشبكة مضبوطة، لكن القواعد الأمنية تحجب الحركة. Security Groups و NACLs يعملان بشكل مستقل — يجب أن يسمح كلاهما بالحركة.

Security Group يعمل على مستوى الـ instance وهو stateful — إذا سمحت بحركة خارجة، الرد يدخل تلقائيًا. NACL يعمل على مستوى الـ subnet وهو stateless — يجب تعريف قواعد الدخول والخروج بشكل منفصل.

التحقق من Security Group

aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[*].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
  --output json

للوصول إلى الإنترنت من الـ instance (outbound)، تأكد من وجود قاعدة تسمح بحركة TCP على المنافذ المطلوبة أو بكل الحركة الخارجة. القاعدة الافتراضية في Security Groups الجديدة تسمح بكل الحركة الخارجة.

التحقق من NACL

aws ec2 describe-network-acls \
  --filters 'Name=association.subnet-id,Values=subnet-0123456789abcdef0' \
  --query 'NetworkAcls[*].{NACL_ID:NetworkAclId,Entries:Entries}' \
  --output json

NACL الافتراضي يسمح بكل الحركة في الاتجاهين. إذا أنشأت NACL مخصصًا، تذكر أنه يرفض كل شيء افتراضيًا — يجب إضافة قواعد صريحة للسماح بالحركة الداخلة والخارجة، بما في ذلك نطاق المنافذ المؤقتة (ephemeral ports).

سيناريو حقيقي — التشخيص الخاطئ الشائع

المشكلة: EC2 في subnet يُسمى 'public-subnet-1'، الـ ping لا يعمل، لا أخطاء في الـ console. التشخيص الأول: 'Security Group يحجب ICMP' — أضفنا قاعدة للسماح بـ ICMP. لا تغيير. التشخيص الثاني: 'IGW غير موجود' — IGW موجود ومرتبط بالـ VPC. السبب الفعلي: الـ subnet كان مرتبطًا بجدول التوجيه الرئيسي للـ VPC الذي لا يحتوي على مسار 0.0.0.0/0. جدول التوجيه الصحيح الذي يحتوي على المسار كان موجودًا لكن لم يكن مرتبطًا بهذا الـ subnet تحديدًا.

الدرس: اسم الـ subnet لا يحدد سلوكه — جدول التوجيه المرتبط به هو ما يحدد ذلك.

graph LR subgraph VPC["VPC المخصص"] subgraph Sub1["public-subnet-1"] EC2["EC2 Instance"] end RT_Wrong["Route Table الرئيسي
بدون مسار 0.0.0.0/0"] RT_Right["Route Table الصحيح
مع مسار 0.0.0.0/0"] Sub1 -.->|"مرتبط بالخطأ"| RT_Wrong Sub1 -->|"يجب الربط بهذا"| RT_Right end IGW["Internet Gateway"] RT_Right -->|"0.0.0.0/0"| IGW IGW --> Internet["الإنترنت"] RT_Wrong -.-x Internet

التحقق النهائي — EC2 بلا إنترنت في VPC مخصص

بعد تطبيق جميع الإصلاحات، تحقق من الحالة الكاملة دفعة واحدة:

🔽 أوامر التحقق الشاملة (انقر للتوسيع)

# 1. تحقق من IGW وحالة الربط
aws ec2 describe-internet-gateways \
  --filters 'Name=attachment.vpc-id,Values=vpc-0123456789abcdef0' \
  --query 'InternetGateways[*].{IGW_ID:InternetGatewayId,State:Attachments[0].State}' \
  --output table

# 2. تحقق من مسارات جدول التوجيه
aws ec2 describe-route-tables \
  --filters 'Name=association.subnet-id,Values=subnet-0123456789abcdef0' \
  --query 'RouteTables[*].Routes[*].{Dest:DestinationCidrBlock,Target:GatewayId,State:State}' \
  --output table

# 3. تحقق من IP عام للـ instance
aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,PublicIP:PublicIpAddress,State:State.Name}' \
  --output table

الخلاصة والخطوات التالية — ربط Internet Gateway وتحديث Route Table

الوصول إلى الإنترنت من EC2 في VPC مخصص يتطلب أربعة عناصر تعمل معًا: IGW مرتبط بالـ VPC، مسار 0.0.0.0/0 في جدول التوجيه، ربط الـ subnet بجدول التوجيه الصحيح، وIP عام على الـ instance. غياب أي عنصر يقطع الاتصال بصمت دون رسالة خطأ واضحة.

للمزيد من التعمق، راجع:

• توثيق AWS — Internet Gateways
• توثيق AWS — Route Tables
• توثيق AWS — Network ACLs

مسرد المصطلحات

المصطلح	التعريف
Internet Gateway (IGW)	مكوّن VPC يتيح الاتصال بين موارد الـ VPC والإنترنت. يجب ربطه صراحةً بالـ VPC.
Route Table	مجموعة قواعد تحدد كيفية توجيه حركة الشبكة داخل الـ VPC وخارجه.
Public Subnet	subnet مرتبط بجدول توجيه يحتوي على مسار نحو IGW — التسمية وحدها لا تكفي.
Elastic IP	عنوان IPv4 عام ثابت يمكن ربطه بـ instance أو network interface داخل VPC.
NACL (Network ACL)	جدار حماية stateless على مستوى الـ subnet — يتطلب قواعد صريحة للحركة الداخلة والخارجة.