ربط شبكتين VPC باستخدام VPC Peering وتحديث جداول التوجيه

عندما تحتاج خدمتان منفصلتان تعملان في شبكتين VPC مختلفتين داخل نفس الحساب والمنطقة إلى التواصل عبر IPs خاصة، فإن أول ما يتبادر إلى الذهن هو VPC Peering — لكن المشكلة الحقيقية لا تكمن في إنشاء الاتصال، بل في نسيان تحديث جداول التوجيه على الجانبين، وهو الخطأ الذي يجعل الاتصال يبدو ناجحاً في Console بينما الـ ping لا يصل.

ملخص سريع (TL;DR) — ربط شبكتي VPC

الخطوة	الإجراء	ملاحظة
1	إنشاء طلب VPC Peering	من VPC-A إلى VPC-B
2	قبول طلب Peering	يدوياً أو عبر CLI
3	تحديث Route Table في VPC-A	توجيه CIDR الخاص بـ VPC-B عبر Peering Connection
4	تحديث Route Table في VPC-B	توجيه CIDR الخاص بـ VPC-A عبر Peering Connection
5	مراجعة Security Groups	السماح بالحركة من CIDR الطرف الآخر

كيف يعمل VPC Peering

VPC Peering هو اتصال شبكي بين شبكتين VPC يتيح توجيه الحركة بينهما باستخدام عناوين IPv4 أو IPv6 الخاصة. الاتصال لا يمر عبر الإنترنت العام، ولا يعتمد على VPN Gateway أو Transit Gateway — إنه مسار توجيه مباشر على مستوى البنية التحتية لـ AWS.

النقطة الجوهرية: Peering Connection وحده لا يكفي. AWS تنشئ المسار المنطقي، لكن جداول التوجيه في كل شبكة يجب أن تُحدَّث يدوياً لتعرف أن حركة الـ CIDR الخاص بالشبكة الأخرى يجب أن تمر عبر هذا الاتصال. بدون هذه الخطوة، الحزم تصل إلى حافة الشبكة ثم تُسقط.

فكر في Peering Connection كبناء جسر بين مدينتين — الجسر موجود، لكن خرائط الطرق في كل مدينة يجب أن تُحدَّث لتشير إليه، وإلا ستظل السيارات تدور في دوائر.

graph LR A["EC2 في VPC-A 10.0.0.0/16"] -->|"حركة نحو 10.1.x.x"| B["Route Table VPC-A Destination: 10.1.0.0/16 Target: pcx-0xxx"] B --> C["VPC Peering Connection pcx-0xxxxxxxxxxxxxxxx الحالة: active"] C --> D["Route Table VPC-B Destination: 10.0.0.0/16 Target: pcx-0xxx"] D --> E["EC2 في VPC-B 10.1.0.0/16"] E -->|"الرد يسلك المسار العكسي"| D

VPC-A (CIDR: 10.0.0.0/16) تحتوي على EC2 Instance يريد التواصل مع خدمة في VPC-B.
VPC Peering Connection يُنشأ بين الشبكتين ويُقبل من الطرف الآخر.
Route Table في VPC-A تُضاف إليها قاعدة: حركة 10.1.0.0/16 تذهب عبر Peering Connection.
Route Table في VPC-B تُضاف إليها قاعدة معاكسة: حركة 10.0.0.0/16 تذهب عبر نفس Peering Connection.
Security Groups على كلا الطرفين يجب أن تسمح بالحركة الواردة من CIDR الطرف الآخر.

المتطلبات الأساسية قبل البدء

قبل إنشاء اتصال VPC Peering، تحقق من هذه النقاط لتجنب أخطاء شائعة:

عدم تداخل CIDRs: يجب ألا يتداخل CIDR الخاص بـ VPC-A مع CIDR الخاص بـ VPC-B. إذا كان كلاهما يستخدم 10.0.0.0/16، لن يعمل Peering.
الحساب والمنطقة: في هذا السيناريو، كلا الشبكتين في نفس الحساب ونفس المنطقة — وهو أبسط حالات Peering.
صلاحيات IAM: المستخدم أو الـ Role يحتاج صلاحيات على EC2 (لأن VPC Peering يقع ضمن خدمة EC2 في IAM) وعلى Route Tables.

إعداد VPC Peering خطوة بخطوة

الخطوة 1: جمع معرّفات الشبكتين

قبل أي شيء، احصل على معرّفات الشبكتين وعناوين CIDR الخاصة بهما — ستحتاجها في كل خطوة لاحقة. هذا يبدو بديهياً، لكن تطبيق Route على الشبكة الخطأ هو مصدر نصف مشاكل Peering في الإنتاج.

# الحصول على قائمة الشبكات مع CIDRs
aws ec2 describe-vpcs \
  --query 'Vpcs[*].{VpcId:VpcId,CIDR:CidrBlock,Name:Tags[?Key==`Name`].Value|[0]}' \
  --output table \
  --region us-east-1

الخطوة 2: إنشاء طلب VPC Peering

ننشئ الطلب من VPC-A باتجاه VPC-B. بما أن كلا الشبكتين في نفس الحساب، يمكن قبول الطلب فوراً في الخطوة التالية.

aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-0abc123456789def0 \
  --peer-vpc-id vpc-0def987654321abc0 \
  --region us-east-1

احفظ قيمة VpcPeeringConnectionId من الناتج — ستبدو بالشكل pcx-0xxxxxxxxxxxxxxxx.

الخطوة 3: قبول طلب Peering

بما أن كلا الشبكتين في نفس الحساب، يمكن قبول الطلب مباشرة عبر CLI. في حالة الحسابات المختلفة، يجب تسجيل الدخول بحساب الطرف الآخر أولاً.

aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-0xxxxxxxxxxxxxxxx \
  --region us-east-1

تحقق من أن الحالة أصبحت active:

aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0xxxxxxxxxxxxxxxx \
  --query 'VpcPeeringConnections[0].Status.Code' \
  --output text \
  --region us-east-1

الخطوة 4: تحديث Route Table في VPC-A

هذه الخطوة هي التي يتجاهلها معظم المهندسين أو يطبقونها على جانب واحد فقط. VPC-A تحتاج أن تعرف أن الحركة المتجهة نحو CIDR الخاص بـ VPC-B يجب أن تمر عبر Peering Connection.

# أولاً: احصل على معرّف Route Table المرتبطة بـ Subnet في VPC-A
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc123456789def0" \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Associations:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1

# ثانياً: أضف المسار
aws ec2 create-route \
  --route-table-id rtb-0aaabbbccc111222 \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-0xxxxxxxxxxxxxxxx \
  --region us-east-1

الخطوة 5: تحديث Route Table في VPC-B

الجانب الآخر من المعادلة — بدون هذه الخطوة، الاتصال أحادي الاتجاه: VPC-A تستطيع إرسال حزم، لكن الردود لن تجد طريقها للعودة.

# احصل على Route Table في VPC-B
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0def987654321abc0" \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Associations:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1

# أضف المسار العكسي
aws ec2 create-route \
  --route-table-id rtb-0dddeeefff333444 \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id pcx-0xxxxxxxxxxxxxxxx \
  --region us-east-1

الخطوة 6: تحديث Security Groups

Route Tables تحدد أين تذهب الحزمة — Security Groups تحدد إذا كان مسموحاً لها بالوصول. كلاهما ضروري. الخطأ الشائع هنا هو السماح بـ CIDR الخاص بالشبكة الأخرى في Security Group بينما القاعدة مكتوبة بـ CIDR خاطئ أو مقيّدة بـ port غير صحيح.

# السماح بحركة واردة في VPC-B من CIDR الخاص بـ VPC-A
aws ec2 authorize-security-group-ingress \
  --group-id sg-0yyy111222333444 \
  --protocol tcp \
  --port 8080 \
  --cidr 10.0.0.0/16 \
  --region us-east-1

سياسة IAM المطلوبة لإعداد VPC Peering

إذا كنت تعمل بـ Role محدود الصلاحيات، ستحتاج على الأقل هذه الصلاحيات. VPC Peering يقع تحت namespace الخاص بـ EC2 في IAM.

🔽 اضغط لعرض سياسة IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VpcPeeringSetup",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVpcPeeringConnection",
        "ec2:AcceptVpcPeeringConnection",
        "ec2:DescribeVpcPeeringConnections",
        "ec2:DescribeVpcs",
        "ec2:DescribeRouteTables",
        "ec2:CreateRoute",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:DescribeSecurityGroups"
      ],
      "Resource": "*"
    }
  ]
}

ملاحظة: بعض عمليات Read/Describe تتطلب "Resource": "*" لأنها لا تدعم تقييد الموارد على مستوى ARN — تحقق من Service Authorization Reference للتفاصيل.

تشخيص المشاكل الشائعة في VPC Peering

graph TD Start["الاتصال لا يعمل"] --> Q1{"حالة Peering Connection؟"} Q1 -->|"غير active"| Fix1["قبول الطلب: accept-vpc-peering-connection"] Q1 -->|"active"| Q2{"مسارات في Route Table على كلا الجانبين؟"} Q2 -->|"ناقصة"| Fix2["إضافة المسار المفقود: create-route"] Q2 -->|"موجودة"| Q3{"Security Group يسمح بالحركة؟"} Q3 -->|"محجوب"| Fix3["تحديث Security Group: authorize-security-group-ingress"] Q3 -->|"مفتوح"| Q4{"Network ACL يحجب الحركة؟"} Q4 -->|"نعم"| Fix4["مراجعة قواعد ACL على مستوى Subnet"] Q4 -->|"لا"| Fix5["فحص تداخل CIDRs أو Transitive Routing"]

ابدأ بالتحقق من حالة Peering Connection — إذا لم تكن active، لا جدوى من باقي الخطوات.
تحقق من وجود المسارات في Route Tables على كلا الجانبين — الغياب على جانب واحد يعني اتصالاً أحادياً.
راجع Security Groups — قد تكون المسارات صحيحة لكن Security Group يحجب الحركة.
تحقق من Network ACLs — طبقة إضافية على مستوى الـ Subnet قد تحجب الحركة حتى لو كانت Security Groups مفتوحة.

التحقق من المسارات الموجودة

aws ec2 describe-route-tables \
  --route-table-ids rtb-0aaabbbccc111222 \
  --query 'RouteTables[0].Routes[*].{Dest:DestinationCidrBlock,Target:VpcPeeringConnectionId,State:State}' \
  --output table \
  --region us-east-1

التحقق من Network ACLs

aws ec2 describe-network-acls \
  --filters "Name=vpc-id,Values=vpc-0abc123456789def0" \
  --query 'NetworkAcls[*].{AclId:NetworkAclId,Entries:Entries[*].{Rule:RuleNumber,Action:RuleAction,CIDR:CidrBlock,Protocol:Protocol}}' \
  --output json \
  --region us-east-1

تجربة حقيقية: الاتصال يبدو ناجحاً لكن الـ ping لا يصل

في أحد بيئات الإنتاج، أُنشئ Peering Connection وقُبل، وظهر في Console بحالة active. المهندس أضاف المسار في Route Table الخاصة بـ VPC-A فقط، وافترض أن AWS تضيف المسار العكسي تلقائياً.

النتيجة: الحزم تخرج من VPC-A وتصل إلى VPC-B، لكن الردود لا تجد طريقها للعودة لأن Route Table في VPC-B لا تعرف كيف تصل إلى 10.0.0.0/16. الـ ping يبدو كأنه يتجمد، وتطبيق الـ health check يُبلَّغ عن timeout.

التشخيص الأولي كان يشير إلى Security Groups — وهو افتراض منطقي، لكنه خاطئ. الأمر الذي كشف المشكلة الحقيقية:

aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0def987654321abc0" \
  --query 'RouteTables[*].Routes[?VpcPeeringConnectionId!=`null`]' \
  --output json \
  --region us-east-1

الناتج كان فارغاً — لا يوجد أي مسار يشير إلى Peering Connection في VPC-B. إضافة المسار العكسي حلّت المشكلة فوراً.

Peering Connection لا يُنشئ مسارات تلقائياً على أي من الجانبين — هذا قرار تصميمي متعمد من AWS لإبقاء التحكم في التوجيه بيد المشغّل.

قيود VPC Peering يجب معرفتها

لا يدعم Transitive Routing: إذا كانت VPC-A متصلة بـ VPC-B، وVPC-B متصلة بـ VPC-C، فإن VPC-A لا تستطيع الوصول إلى VPC-C عبر VPC-B. كل اتصال يجب أن يكون مباشراً.
لا يدعم Edge-to-Edge Routing: لا يمكن استخدام Peering للوصول إلى موارد خارج الشبكة عبر VPN Gateway أو Internet Gateway الخاص بالطرف الآخر.
عدم تداخل CIDRs: شرط صارم — لا حل بديل إذا كانت CIDRs متداخلة.

إذا كنت تحتاج Transitive Routing أو ربط عدد كبير من الشبكات، فكر في AWS Transit Gateway بدلاً من Peering.

الخلاصة والخطوات التالية لـ VPC Peering

إعداد VPC Peering يتطلب ثلاثة مكونات تعمل معاً: اتصال Peering بحالة active، مسارات في Route Tables على كلا الجانبين، وقواعد Security Groups تسمح بالحركة. غياب أي منها يكسر الاتصال بصمت.

للمزيد، راجع:

AWS VPC Peering Guide
توثيق Route Tables لـ VPC Peering
AWS Transit Gateway — للحالات التي تتجاوز قيود Peering

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

المصطلح	التعريف
VPC Peering Connection	اتصال شبكي مباشر بين شبكتين VPC يتيح التوجيه عبر IPs خاصة دون المرور بالإنترنت
Route Table	مجموعة قواعد تحدد كيفية توجيه حركة الشبكة داخل VPC أو منها
CIDR Block	نطاق عناوين IP يُعرَّف بصيغة مثل 10.0.0.0/16 ويُستخدم لتحديد نطاق الشبكة
Security Group	جدار حماية افتراضي على مستوى الـ Instance يتحكم في الحركة الواردة والصادرة
Network ACL	طبقة تحكم في الحركة على مستوى الـ Subnet، تعمل بشكل مستقل عن Security Groups

بحث هذه المدونة الإلكترونية

SW BBANG A